Вопросы Теги

Как далеко необходимо разбить таблицы стилей?

eye_pos - это позиция в мировом пространстве.
o_pos - это позиция в пространстве просмотра, пространстве клипа и нормализованном пространстве устройства. Это все то же самое в вашем случае, потому что у вас нет матрицы проекции, и атрибут координаты вершины напрямую назначается позиции пространства клипа в вершинном шейдере: 

 gl_Position = vec4(aPos, 1.0);
[ 1114] В любом случае, не имеет смысла вычислять вектор из положения в мировом пространстве в положение в пространстве вида, как вы это делаете: 

 vec3 incident = normalize(o_pos - eye_pos);

Положение глаза в поле зрения есть (0, 0, 0). Таким образом, вектор вида инцидента в пространстве вида: 

vec3 incident = normalize(o_pos - vec3(0.0, 0.0, 0.0));

Этот вектор должен быть преобразован из пространства вида в мировое пространство, что может быть достигнуто с помощью матрицы ориентации вида (mat3(view_right, view_up, view_forward)), в так же, как вы делаете это в фрагментном шейдере скайбокса: 

vec3 incident = mat3(view_right, view_up, view_forward) * normalize(o_pos);

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

vec3 wordlNormal = mat3(view_right, view_up, view_forward) * normalize(o_normal);

Вместо преобразования вектора падения и вектора нормали можно преобразовать результирующий вектор после отражения.
Вы должны изменить шейдер фрагмента объекта, чтобы решить вашу проблему: 

#version 330 core

in vec3 o_pos;
in vec3 o_normal;

out vec4 fragColor;

uniform vec3 view_up;
uniform vec3 view_right;
uniform vec3 view_forward;
uniform samplerCube cubeTex;

void main()
{
    mat3 invNormalM      = mat3(view_right, view_up, view_forward);

    vec3 viewIncident    = normalize(o_pos);
    vec3 viewNormal      = normalize(o_normal);
    vec3 worldReflection = invNormalM * reflect(viewIncident, viewNormal);

    fragColor            = vec4(texture(cubeTex, worldReflection).rgb, 1.0);
}

Я передаю матрицу вида непосредственно в шейдер фрагмента.

mat3(view_right, view_up, view_forward) не является матрицей вида. Это матрица ориентации камеры. Так что это обратная (нормальная) матрица.

15
задан Chris J Allen 21 October 2008 в 14:44
поделиться

12 ответов

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

, С другой стороны, сохраняя все в одном файле CSS сохраняет запросы между браузером & сервер вниз. Компромисс мог бы быть должен разделить вещи для разработки, и объединяющийся для производства (как часть Вашего процесса сборки, естественно :p).

9
ответ дан 1 December 2019 в 02:20
поделиться

Я разбиваю мой почти точно тот же путь:

  • reset.ccs - стандартный сброс от MeyerWeb
  • typography.css - Шрифты, размеры, высоты строки, и т.д.
  • layout.css - Все расположение, плавания, выравнивание, и т.д.
  • colors.css (или более соответственно skin.css) - Все цвета, фоновые изображения, и т.д.

Они затем сопровождаются с определенными для IE файлами, включенными с помощью условных комментариев для соответствующей версии.

у меня не было потребности разделить их далее, хотя я действительно организую каждый файл в отдельных участках (основные элементы, названные элементами, классами, и т.д.)

ОБНОВЛЕНИЕ: Я изменил свою систему немного в последних нескольких проектах, которые я сделал.

  • base.css - Содержит CSS от , YUI сбрасывают и основа YUI файлы CSS (с атрибуцией)
  • , main.css - Содержит @import операторы для следующего:
    • typography.css - Шрифты, размеры, высоты строки, и т.д.
    • layout.css - Все расположение, плавания, выравнивание, и т.д.
    • theme.css - Все цвета, фоновые изображения, и т.д.
  • print.css - Переопределения для других файлов CSS для создания страниц благоприятными для печати.

я также затем использую условные комментарии для добавления любых определенных для IE файлов CSS в случае необходимости.

Мой следующий шаг в улучшении это должно было бы добавить, что процесс сборки ступает для объединения всех файлов CSS в один файл для сокращения Запросов HTTP на сервере.

1
ответ дан 1 December 2019 в 02:20
поделиться

Pickledegg,

нет ничего неправильно с разбиванием таблиц стилей. На самом деле я нахожу очень полезным организовать правила CSS в различные файлы на основе их типа, или какие части сайта к ним относятся. Если Вы смешиваете правила в один большой файл, это может быстро стать путаницей и стать очень трудным справиться.

я рекомендовал бы придумать Вашу собственную схему того, чтобы разделить Ваши правила на файлы и палку с ним для всех Ваших проектов.

2
ответ дан 1 December 2019 в 02:20
поделиться

Я не склонен разделять типографию на отдельную таблицу стилей, хотя она походит на хорошую идею. Я сохранил бы цвета с типографией все же. Мой типичный путь состоит в том, чтобы иметь следующую структуру:

base.css

  • Глобальный стиль использовал всюду по сайту
  • Цели быть растяжимым, например так, чтобы он мог быть повторно очищен (но использование exisiting расположения) для микросайта.
  • Реализации/импорт reset.css

page.css

  • Реализации любые определенные для страницы изменения.

microsite_skin.css

  • См., что base.css указывает 2
5
ответ дан 1 December 2019 в 02:20
поделиться

Я разломал бы расположение на 2 + больше частей, Основного расположения, Взломов IE, Меню (один для каждой области меню. Это могло быть чем-то как главное меню и боковое меню), Если сайт, где изменить цвет в зависимости от области, я добавлю один для каждой цветной области также. Вы также могли использовать Yaml или подобный как основная платформа для Вашего расположения. Я сохранил бы различные таблицы стилей отдельными при разработке только слияния их в 2-4 в зависимости от сайта незадолго до загрузки/выпуска. всегда держание отдельно Взломов.

2
ответ дан 1 December 2019 в 02:20
поделиться

Разделите их на основе того, что Вы оцениваете, что Ваши потребности будут позже. Если Вы думаете типография, расположение, или цвета (глобально) собираются измениться, то, вероятно, мудро, по крайней мере, формировать рисунок стилей таким образом, таким образом, легче заменить одну таблицу стилей другим позже.

, Но если Вы заходите слишком далеко в этом, Вы закончите с дублирующимися правилами везде (например, #content, имеющий правило семейства шрифтов в typography.css, цветное правило в colors.css, и т.д.). Это не логический способ разделить вещи, если Вы не ожидаете, что ключ изменяется для происхождения там.

, Если с другой стороны, как большинство сайтов графический дизайн собирается остаться довольно статичным, но архитектура будет иметь некоторые внесенные изменения (например, новый тип контента) затем, Вы хотите сгруппировать свои стили на основе контекста сайта. Например, article.css, search.css, и т.д.

По существу, пытаются смотреть вперед в том, какие изменения будут необходимыми позже и затем пытаются ожидать те изменения в Вашей установке файла CSS.

2
ответ дан 1 December 2019 в 02:20
поделиться

Я поместил все стили, включая стили IE6-and-7-specific, в одном листе. IE6 и 7 стилей предназначены с помощью условно прокомментированных отделений, которые только появляются, если один из тех браузеров прибывает в сайт, например: 

<body>
<!--[if IE 7]><div class="IE IE7"><![endif]-->
<!--[if IE 6]><div class="IE IE6"><![endif]-->

... rest of markup ...

<!--[if IE]></div><![endif]-->
</body>

Не уверенный, какие люди думают об этом подходе, но дополнительная разметка незначительна, и способность включать стили IE6/7 рядом с основными стилями без использования взломов... просто предварительное ожидание селектора с ".IE" или ".IE6" и т.д., большое удобство.

Что касается нескольких таблиц стилей... сохраняют Ваши Запросы HTTP. Используйте спрайты изображения, одну таблицу стилей, один "application.js" JavaScript, и т.д.

я все еще включал бы отдельные листы для печати и карманных стилей, но это об этом...

2
ответ дан 1 December 2019 в 02:20
поделиться

Основная проблема IMO, дублирующаяся проблема определения свойства. Это делает таблицы стилей неуправляемыми. Чтобы обойти эту проблему, деление и завоевать подход используется. Если мы можем гарантировать управляемые таблицы стилей неконфликтующими правилами, то слияние листов или модульное исполнение их были бы легки.

Во время обзоров все, что я делаю, проверить на конфликты правила, classitis и divitis. Используя комбинацию Firebug/CSSTidy, выделяются проблемные области. Думая в этих строках, я даже не изучаю типографию и разделение шрифта.

цель состоит в том, чтобы иметь единственный основной файл CSS, и отдельный браузер взламывает файлы. Несколько основных файлов CSS были бы необходимы, если приложение имеет различные темы.

2
ответ дан 1 December 2019 в 02:20
поделиться

Не идите слишком много далее, чем это. Если Вы действительно имеете к, пытаетесь найти способ объединить их перед производством. Самая большая проблема - то, что Вы начинаете складывать Запросы HTTP. Это не так проблема для браузера, но суммы запросов, которые должны быть выполнены для каждой страницы. Я сказал бы, что Вы в положительной стороне, больше чем 4 шли бы несколько за борт. Помните, что можно всегда использовать хороший комментарий и форматирование для разбивания больших файлов CSS.

1
ответ дан 1 December 2019 в 02:20
поделиться

Каждый раз, когда я пытаюсь решить, как далеко разбить некоторые файлы (я обычно делаю это с модулями кода, но я применяю те же принципалы к своему css/js), я ломаю его в самые маленькие допускающие повторное использование файлы, которые имеют смысл вместе. Это не является лучшим для потока данных через провод, но это делает пригодность для обслуживания моего источника намного легче. Особенно, если Вы собираетесь быть наличием большого количества CSS, плавающей вокруг.

, Если Вы чувствуете себя комфортно, беря Ваш colors.css и с помощью всего этого в другом месте без модификации затем, Вы, вероятно, в порядке.

1
ответ дан 1 December 2019 в 02:20
поделиться

Смотрите на CSS проекта . Проект является платформой CSS, которая предоставляет множество стилей по умолчанию Вам (таких как код сброса браузера).

таблицы стилей в CSS проекта организованы следующим образом:

  • screen.css - стили по умолчанию для экранов
  • print.css - стилей по умолчанию для печати
  • ie.css - Internet Explorer определенные меры
  • application.css - содержит стили, которые Вы пишете. На самом деле Вы не должны изменять предыдущие три таблицы стилей вообще, потому что они сгенерированы CSS проекта. Можно перезаписать все стили CSS проекта в application.css файле.

Для получения дальнейшей информации относятся к репозиторию Мерзавца CSS проекта.

1
ответ дан 1 December 2019 в 02:20
поделиться

Все рекомендуют ломаться. Я буду адвокатом дьявола.

Как насчет того, чтобы НЕ ломать таблицы стилей. По крайней мере, для производственных целей лучше иметь один запрос вместо множества. Браузер может обрабатывать 2 одновременных HTTP-запроса. Это означает, что другие 2 запроса могут быть выполнены после завершения первых 2.

Комбинированные файлы - это способ уменьшить количество HTTP-запросов путем объединения всех сценариев в один сценарий и аналогичного объединения всего CSS в единую таблицу стилей. Комбинировать файлы сложнее, когда сценарии и таблицы стилей меняются от страницы к странице, но выполнение этой части процесса выпуска сокращает время отклика.

Yahoo и Google рекомендуют это.

Google рекомендует создать 2 файла. Один для всего необходимого при запуске и 1 для всего остального.

Я думаю, что даже дизайнеры должны думать об оптимизации, а не только заядлые разработчики.

1
ответ дан 1 December 2019 в 02:20
поделиться
Другие вопросы по тегам:

Похожие вопросы: