Ответ 1

Ну, я, конечно, не могу утверждать, что являюсь авторитетом в этом вопросе (я все еще сам изучаю правила кодирования), но я на самом деле склоняюсь к опции № 1 - единственной таблице стилей. Однако я думаю о конкретной реализации этого. Вместо того, чтобы иметь единственную точку разрыва для каждого случая размера экрана, вам нужны новые стили, я бы предложил несколько точек останова - один для стилей CSS каждого модуля, где нужно было бы разрешить несколько размеров экрана.

А... это могло быть слегка запутанным выражением. Пример в порядке...

Вместо того, чтобы что-то вроде:

/*default styles:*/
/*header styles*/
.header-link{  ...  }
.header-link:active{  ...  }
.header-image{  ...  }
.header-image-shown{  ...  }
.header-table-cell{  ...  }

/*content styles*/
.content-link{  ...  }
.content-link:active{  ...  }
.content-image{  ...  }
.content-image-shown{  ...  }
.content-table-cell{  ...  }

/*footer styles*/
.footer-link{  ...  }
.footer-link:active{  ...  }
.footer-image{  ...  }
.footer-image-shown{  ...  }
.footer-table-cell{  ...  }

/*alternate styles for smaller screens:*/
@media only screen and (max-width: 1000px){
    /*header styles*/
    .header-link{  ...  }
    .header-image{  ...  }
    .header-image-shown{  ...  }
    .header-table-cell{  ...  }

    /*content styles*/
    .content-link{  ...  }
    .content-image{  ...  }
    .content-image-shown{  ...  }
    .content-table-cell{  ...  }

    /*footer styles*/
    .footer-link{  ...  }
    .footer-image{  ...  }
    .footer-image-shown{  ...  }
    .footer-table-cell{  ...  }
}

Я предлагаю вариант # 1, только что реализованный как:

/*default header styles*/
.header-link{  ...  }
.header-link:active{  ...  }
.header-image{  ...  }
.header-image-shown{  ...  }
.header-table-cell{  ...  }

/*alternate header styles for smaller screens*/
@media only screen and (max-width: 1000px){
    .header-link{  ...  }
    .header-image{  ...  }
    .header-image-shown{  ...  }
    .header-table-cell{  ...  }
}

/*default content styles*/
.content-link{  ...  }
.content-link:active{  ...  }
.content-image{  ...  }
.content-image-shown{  ...  }
.content-table-cell{  ...  }

/*alternate content styles for smaller screens*/
@media only screen and (max-width: 1000px){
    .content-link{  ...  }
    .content-image{  ...  }
    .content-image-shown{  ...  }
    .content-table-cell{  ...  }
}

/*default footer styles*/
.footer-link{  ...  }
.footer-link:active{  ...  }
.footer-image{  ...  }
.footer-image-shown{  ...  }
.footer-table-cell{  ...  }

/*alternate footer styles for smaller screens*/
@media only screen and (max-width: 1000px){
    .footer-link{  ...  }
    .footer-image{  ...  }
    .footer-image-shown{  ...  }
    .footer-table-cell{  ...  }
}

(Все классы являются заполнителями. Я не очень креативен...)

Хотя это означает, что вы будете делать одно и то же объявление объявления мультимедиа несколько раз (что приведет к еще большему количеству кода), это намного удобнее для тестирования отдельных модулей, что в целом поможет поддерживать работоспособность вашего сайта по мере его получения больше. Попробуйте добавить несколько реальных стилей, больше тегов/классов/id в пример, который я дал, и, возможно, добавить к ним немного больше пробелов, и вы скоро увидите, насколько быстрее он будет сузить и изменить/добавить стили (через все размеры экрана) в реализации, показанной второй частью примера.

И я полностью согласен с этим ответом на информацию от Scalable и Modular Architecture для CSS от Джонатана Снука. (В конце концов, ни один из новичков, как я, не смог бы понять и объяснить такой ответ, как это все!) Как указано в одной из многих соответствующих частей этой книги,

"... вместо одной точки останова, либо в основном файле CSS, либо в отдельной таблице стилей мультимедийных запросов, размещайте медиа-запросы вокруг состояний модуля."

Хотя, если по личным предпочтениям или другим вам лучше не использовать этот подход, тогда вы можете пойти с любым из других вариантов, которые вы предложили - в конце концов, сам Снок говорит, что его книга "больше ориентирована на стиль" чем жесткая структура ", поэтому не чувствую, что это стандарт кодирования. (Хотя я считаю, что это должно быть. XD)

Ответ 2

Я верю в "ввод кода, где вы его ожидаете". Если стиль нуждается в перегрузке, я бы хотел, чтобы мой код превысил максимально возможный стиль по умолчанию, поэтому в том же документе. Таким образом, через год я все равно буду знать, что происходит, когда я смотрю на код. В другом подходе (отдельный файл css для каждой точки останова) мне нужно будет помнить, что goo ищет переполнение кода стилей в отдельном файле. Не проблема, если я не забуду, я сделал это таким образом через год. Предположим, что это личное предпочтение, и браузеру все равно.

Ответ 3

Если вы хотите использовать второй вариант, вы можете избежать "копирования и вставки" глобальных стилей, которые вам нужны как для мобильных, так и для настольных версий сайта, которые удобны для veeeeeery и помогут вам сохранить все более организованное в моем и использует SASS.

У вас может быть что-то вроде этого:

> CSS Folder
> Sass folder
 - _global.scss
 - _mobile_layout.scss
 - _desktop_layout.scss
 - main_mobile.scss
 - main_desktop.scss

который будет скомпилирован в

> CSS Folder
 - main_mobile.css
 - main_desktop.css

Надеюсь, вы сочтете это полезным ^^