В последнее время я видел много представлений о CSS-фреймворках. Несколько дней назад я сказал: «В моем ограниченном поле зрения я не видел ничего, что действительно можно было бы назвать CSS-фреймворком~». может быть, мое. Поле зрения слишком маленькое, или мир слишком большой. Я все еще чувствую, что есть много вещей, которые я не могу видеть.
Давайте сначала посмотрим на концепцию, с которой я согласен:
Фреймворк можно разделить на два типа: «белый ящик» и «черный ящик».
Платформы, основанные на наследовании, называются структурами белого ящика. Так называемый белый ящик имеет видимость, а детали внутренней реализации унаследованного родительского класса известны подклассу. Разработчики приложений, использующие структуры «белого ящика», разрабатывают системы путем создания подклассов или переопределения методов-членов родительских классов. Реализация подкласса сильно зависит от реализации родительского класса, и эта зависимость ограничивает гибкость и полноту повторного использования. Но способ решить это ограничение может состоять в том, чтобы наследовать только абстрактный родительский класс, поскольку абстрактные классы по сути не обеспечивают конкретной реализации. Структура «белого ящика» представляет собой скелет программы, а производные от пользователя подклассы являются аксессуарами этого скелета.
Фреймворк, основанный на сборке объектных компонентов, представляет собой фреймворк «черного ящика». Разработчики приложений получают реализацию системы путем сортировки и сборки объектов. Пользователям необходимо понимать только внешний интерфейс компонента и не нужно понимать конкретную внутреннюю реализацию. Кроме того, сборка более гибка, чем наследование, и ее можно изменять динамически. Наследование — это только статическая концепция времени компиляции.
В идеальной ситуации любую необходимую функциональность можно получить путем сборки существующих компонентов. На самом деле имеющиеся компоненты далеки от удовлетворения потребностей. Иногда проще получить новые компоненты путем наследования, чем собирать новые компоненты, используя существующие. Белый ящик и черный ящик будут использоваться при разработке системы одновременно. Однако структуры «белого ящика» имеют тенденцию развиваться в сторону структур «черного ящика», и структуры «черного ящика» также являются идеальными целями, которых надеется достичь при разработке системы.
Давайте посмотрим на множество CSS-фреймворков, представленных сегодня в Интернете (YUI называется «YUI Library CSS Tools», а не «YUI CSS Frameworks»), сколько из них на самом деле написано с использованием концепции фреймворка и сколько из них. просто определите базовые классы стилей. Конечно, понимание концепции у всех может быть разным, и вы можете не согласиться с тем, что я говорю.
Давайте еще раз поговорим о CSS-фреймворке. Дело не в том, что я не осознаю существование этой штуки. Я пробовал такие вещи год или два назад. Для крупных веб-сайтов фронтенд-разработка требует решения. Фреймворк, естественно, является первым выбором. Жаль, что это слишком далеко от меня и я слишком слаб Т_Т мне нужно только две вещи:
Что-то для управления контентом ниже
Класс/Компонент
Очевидно, что первый момент заключается в том, что CSS не может этого сделать, а второй момент в том, что он очень слаб по сравнению с другими языками.
Когда около года назад я работал над веб-сайтом среднего размера, чтобы быть ленивым, я подумал о том, чтобы модулировать контент и позволить программистам собирать страницы. Общее направление — инкапсулировать один функциональный блок за другим. Программистам нужно использовать соответствующий HTML и CSS только тогда, когда они хотят использовать ту часть контента, которая удобна для всех. Я не хочу писать страницу. Мне не нужно повторять код. Привет всем. Это действительно хорошо.
На одном и том же веб-сайте одинаковые блоки контента могут использоваться несколько раз. Это также делает возможной модульность, например список изображений, список аватаров пользователей или список значков групп. В настоящее время вы узнаете, как это сделать. написать это? Должны ли одни и те же слова писаться так?
.photoListUesr,.photoListGroup{ /*_*/ }
Это не значит, что это невозможно, но что, если вам вдруг захочется добавить аналогичный в этот момент, возможно, вам придется подкорректировать стиль? А что насчет меня? Я пробовал использовать это так:
<div class="photoList UesrCt" />
<div class="photoList GroupCt" />
В этом случае мы с самого начала выделяем общие выражения, используем .photoList в качестве прототипа и обрабатываем детали с помощью дополнительных классов. Несколько дней назад я написал об объектно-ориентированном программировании на XHTML и CSS. На самом деле я написал только половину. Другая половина представляла собой подробные примеры, но я не закончил ее, потому что мне пришлось написать слишком много примеров. ядро уже было написано ^^ Конечно, здесь тоже есть определенные проблемы, то есть определение первоначального прототипа должно быть очень осторожным и стараться гарантировать, что даже если он будет пересмотрен в будущем, возможно, в этом не возникнет необходимости. модифицированный. При использовании CSS фреймворк может вместить максимум один веб-сайт. Конечно, если веб-сайт достаточно большой, имеет смысл использовать его таким образом.
Чем более модульными становятся HTML и CSS, тем более фрагментированными становятся файлы и тем серьезнее становится эта проблема. HTML легко обрабатывать, поскольку приложение в конечном итоге объединит и выведет одну копию, но CSS обычно отбрасывается и используется напрямую. В приведенном примере способ импорта CSS на веб-страницу выглядит следующим образом:
@import URL(/xxx/photoList.css);
@import URL(/xxx/UserCt.css);
@import URL(/xxx/GroupCt.css);
Вы даже можете рассмотреть возможность использования программы для объединения страниц, но она проста в использовании и пропорциональна количеству запросов. Обычно каждый предпочитает объединять файлы вручную. Хотя человеческий мозг более интеллектуален, чем компьютер, во многих случаях вычислительная мощность человеческого мозга не так хороша, как у компьютера. Однажды у меня возникла идея использовать серверную программу для управления механизмом выпуска CSS. Общее направление — проанализировать использование различных страниц всего сайта с помощью журналов доступа к сайту и использовать программу для расчета того, какие из них используются публикой. необходимо объединить порядок (порядок CSS-файлов будет влиять на приоритет) и т. д. Различные вычисления и сжатый вывод.
К сожалению, такая сложная программа может подойти только для одной станции или группы станций одной серии. Хотя это немного хлопотно, я считаю, что этот метод необходимо использовать для веб-сайтов уровня портала. Конечно, предполагается, что вся команда должна использовать один и тот же шаблон проектирования.
PS: Вышеупомянутая программа публикации CSS — всего лишь моя фантазия. Я еще не пробовал ее. Заинтересованные друзья могут попробовать. В случае каких-либо происшествий я не несу ответственности.
Конечно, вышеперечисленное нельзя назвать CSS Frameworks, пожалуй, его можно назвать только решением системного уровня. Ведь CSS — это всего лишь описательный язык.
Когда вчера вечером я ужинал с Юэином жареной уткой, мы говорили об этом, и он спросил меня, есть ли у меня интегрированное интерфейсное решение. С той же проблемой придется столкнуться при компонентизации JS, и аналогичные механизмы публикации также должны быть применимы к JS. Но я еще не придумал полностью интегрированное решение. Может быть, Юин еще несколько раз угостит меня жареной уткой, и я во всем разберусь.