Comments 60
Весьма оригинальный подход, но
Поисковые движки вряд ли проиндексируют тексты, записанные таким образом— весомый минус.
ну почему-же? может наоборот стоит таким способом скрывать меню и другие не важные для контента вещи от поисковиков? тогда и по основным словам в статье будет находиться лучше.
Достойно отдельной статьи «прячем меню от поисковика». Даже если поисковик захочет сканировать пустые теги ссылок, то, чтобы отобразить при выдаче краткий список разделов, ему придется хорошенько постараться.
Зачем только меню? Напишите «прячем ссылки от поисковиков» и тогда их грязные железные ножки не наследят в дебрях сайта, где не ступала нога браузера.
Боюсь, что это один из наиболее весомых минусов.
присковики и js не могли долгое время сканировать, и pdf не читали итп.
Если применять технику активно, поисковики первые, кто подтянется. Точнее первым будет гугл, а остальные тут же схавают технику.
Если применять технику активно, поисковики первые, кто подтянется. Точнее первым будет гугл, а остальные тут же схавают технику.
UFO just landed and posted this here
Только отбились от оформления в HTML, так теперь норовят сам контент в CSS засунуть. Вот скажите, зачем забивать гвозди микроскопом? content предназначен для автоматических счётчиков и всяких разных меток, для оформления наконец. Никакого основного контента там быть не должно!
Основной контент в него запихнуть и не получится. Хотя бы из-за разметки (болд, италик). А вот некоторые навигационные элементы… почему бы и нет? Если, например, названия классов сделать сокращенными, то вполне можно таким макаром сверстать какой-нибудь мобильный интерфейс в целях экономии траффика. Насколько мне известно, и мобильный Сафари, и мобильный Хром умеют кешировать CSS-файлы.
Италик не проблема. Проблема в том, что это неправильно. Точно так же, как и применение классов типа .bold .float-left и т.п.
Я предпочитаю оценивать правильность или неправильность конкретного решения исходя из условий поставленной задачи.
Довольно странно отдавать мобильному браузеру английский html и русский css вместо русского html. Какая-то неправильная экономия.
Что такое «русский хтмл»?
Русский текст в html.
А, я упустил из виду, что html-то пустой будет. Тогда да, трафик экономится. Но и проблемы с доступностью возникают. Наверняка не все мобильные браузеры поддерживают content.
И ещё возникает проблема поддержки. Редактировать html (визуально) может любой. Для редактирования css нужен уже более подготовленный человек.
А, я упустил из виду, что html-то пустой будет. Тогда да, трафик экономится. Но и проблемы с доступностью возникают. Наверняка не все мобильные браузеры поддерживают content.
И ещё возникает проблема поддержки. Редактировать html (визуально) может любой. Для редактирования css нужен уже более подготовленный человек.
Старые мобильные браузеры действительно могут не поддерживать content. Я это упомянул среди минусов. Мобильные Хром и Сафари точно поддерживают. Насчет браузера, встроенного в Мобильную Винду не знаю. Не было пока возможности проверить.
Что до редактирования, если бы я всерьез озаботился подобным методом, то сделал бы редактирование полей через админку, чтобы цсс-файлы генерировались по шаблону автоматически. Но в целом с замечанием согласен.
Что до редактирования, если бы я всерьез озаботился подобным методом, то сделал бы редактирование полей через админку, чтобы цсс-файлы генерировались по шаблону автоматически. Но в целом с замечанием согласен.
А почему вы считаете не правильным применение таких классов? Создав класс .red весьма удобно его применять везде, где надо сделать текст красным, и не плодя при этом дополнительные классы.
Во-первых, на все цвета и случаи классов не напасешься.
Во-вторых, за пять лет работы с большими проектами я убедился, что удобнее все-таки мыслить блоками, а не свойствами элемента. Удобнее с точки зрения дальнейшей поддержки кода.
Использование подобных классов будет относительно оправдано на небольших проектах с небольшим количеством блоков и сущностей. Как мне кажется, возможно, я ошибаюсь.
Во-вторых, за пять лет работы с большими проектами я убедился, что удобнее все-таки мыслить блоками, а не свойствами элемента. Удобнее с точки зрения дальнейшей поддержки кода.
Использование подобных классов будет относительно оправдано на небольших проектах с небольшим количеством блоков и сущностей. Как мне кажется, возможно, я ошибаюсь.
UFO just landed and posted this here
Зачем контент страницы хранить в CSS файлах 0_о
Есть ещё один весомый плюс — частичное кеширование контента на стороне браузера!
И ещё отвечу сразу многим выше написавшим, что не надо мешать контент и оформление:
А вы положите этот каскадник отдельно от оформления — и не смешивайте их. Положите его в каталог locales, назовите его russian.css, если это для русских, а оформление храните отдельно. Раз не надо мешать — так и не мешайте =)
А индексировать поисковикам навигацию, например, и так не надо — они и сами пытаются её фильтровать. А таким образом локализовывать, допустим, статьи целиком — конечно не самый лучший вариант.
И ещё отвечу сразу многим выше написавшим, что не надо мешать контент и оформление:
А вы положите этот каскадник отдельно от оформления — и не смешивайте их. Положите его в каталог locales, назовите его russian.css, если это для русских, а оформление храните отдельно. Раз не надо мешать — так и не мешайте =)
А индексировать поисковикам навигацию, например, и так не надо — они и сами пытаются её фильтровать. А таким образом локализовывать, допустим, статьи целиком — конечно не самый лучший вариант.
Можно еще чуть проще сделать и стопицот кроссбраузерно:
[style] .lang {display: none} body.ru lang.en, body.ru lang.ru {display: block} [/style]
[body class=«ru»]
[div class=«menuitem»]
[span class=«lang en»]Menu[/span][span class=«lang ru»]Меню[/span]
[div/]
зы: Но все-таки микроскоп надо беречь :)
[style] .lang {display: none} body.ru lang.en, body.ru lang.ru {display: block} [/style]
[body class=«ru»]
[div class=«menuitem»]
[span class=«lang en»]Menu[/span][span class=«lang ru»]Меню[/span]
[div/]
зы: Но все-таки микроскоп надо беречь :)
Милостивый Аполлон, сжалься и ослепи меня своими стрелами.
А как насчет локализации с помощью DTD?
Подход интересный, но имеет очень ограниченное применение. Локализация — это не только меню, но и все тексты на сайте. А они часто берутся из БД. В этом случае CSS для перевода не помощник.
Конечно. Данный способ с моей точки зрения подходит (если вообще подходит) лишь для локализации элементов дизайна. Меню, вспомогательные ссылки.
Локализовать таким макаром контент страницы во-первых, довольно неудобно по ряду причин, а во-вторых, не имеет смысла. Дело в том, что меню на сайте на всех страницах +– одинаковое. Именно поэтому его имеет некоторый смысл кешировать через CSS-файл. Содержимое же страниц у нормального сайта уникально.
Локализовать таким макаром контент страницы во-первых, довольно неудобно по ряду причин, а во-вторых, не имеет смысла. Дело в том, что меню на сайте на всех страницах +– одинаковое. Именно поэтому его имеет некоторый смысл кешировать через CSS-файл. Содержимое же страниц у нормального сайта уникально.
а мне кажется, это охуенно
Вы скорее всего перепутали XSLT (eXtensible Stylesheet Language Transformations), созданный для преобразования содержимого с CSS (Cascading Style Sheets), созданный для оформления содержимого.
С точки зрения оптимизации файлы css, которые нельзя склеить — зло. Хотя есть альтернативные link и прочее, лучше работать через класс для body и иметь классы в соответствующих «локалях»:
Но это все равно фигня, поскольку как уже сказали локализация меняется вместе с контентом и менюшки в нем — ничтожная доля и не стоят отдельной работы и поддержки.
body.lang_en .b-menu__item_name_main .b-menu__curr:after,
body.lang_en .b-menu__item_name_main .b-menu__link:after
{
content: 'Main Page';
}
body.lang_ru .b-menu__item_name_main .b-menu__curr:after,
body.lang_ru .b-menu__item_name_main .b-menu__link:after
{
content: 'На главную';
}
Но это все равно фигня, поскольку как уже сказали локализация меняется вместе с контентом и менюшки в нем — ничтожная доля и не стоят отдельной работы и поддержки.
Можно и склеивать оба файла в «main.css» по принципу: впереди идет язык по умолчанию, затем подклеивается кастомный язык. Тогда файл будет один (соответственно, будет и один запрос).
lol, и как это прокэшировать? :)
Учитывая, что на выходе получится обычный css-файл, суть вопроса мне не очень понятна.
Разные пользователи, разные установки, разные файлы.
Один main.css тут просто не получиться — его содержимое будет случайным :)
Я молчу что зависимость от последовательности склейки — самое то по-геморроиться.
Один main.css тут просто не получиться — его содержимое будет случайным :)
Я молчу что зависимость от последовательности склейки — самое то по-геморроиться.
Создаем несколько «склеек»: main.ru.css, main.en.css, main.ua.css. Способов это сделать автоматически — вагон.
Далее остается только получить из куки (ее все равно придется использовать) или из какого-либо иного источника две буковки, обозначающие язык. И соорудить с помощью используемого шаблонизатора конструкцию <link href="/css/main.{% lang %}.css"/>.
Тот файл, который получится, будет закеширован браузером пользователя.
Далее остается только получить из куки (ее все равно придется использовать) или из какого-либо иного источника две буковки, обозначающие язык. И соорудить с помощью используемого шаблонизатора конструкцию <link href="/css/main.{% lang %}.css"/>.
Тот файл, который получится, будет закеширован браузером пользователя.
Идея весьма интересная, но есть же принцип: «представление — html, оформление — css, поведение — javascript», который в данном случае нарушается.
Но за поиск нестандартных решений автор топика явно заслужил похвал :)
Но за поиск нестандартных решений автор топика явно заслужил похвал :)
Добавлю от себя по одному пункту к плюсам и минусам:
— плюс (на мой взгляд): созданный средствами css текст — не «выделябельный», удобно копирастам, беспокоящимся за лёгкое копирование текста, не нужно городить скрипты для запрета выделения текста
— минус: консольные браузера не понимают эти стилевые правила, отображается пустота.
— плюс (на мой взгляд): созданный средствами css текст — не «выделябельный», удобно копирастам, беспокоящимся за лёгкое копирование текста, не нужно городить скрипты для запрета выделения текста
— минус: консольные браузера не понимают эти стилевые правила, отображается пустота.
— плюс (на мой взгляд): созданный средствами css текст — не «выделябельный», удобно копирастам, беспокоящимся за лёгкое копирование текста, не нужно городить скрипты для запрета выделения текста
Он «выделябельный», если начинать выделять не с него, к тому же в IE и Opera он прекрасно копируется (в Opera к тому же это совсем обычный текст).
За оригинальность, несомненно, пятерка.
Для статичных страниц может быть и можно применить, особенно если это страница-визитка верстальшика.
Для динамических страниц малопригодно. Как, например, можно на css локализовать фразу «Осталось %d элементов» с учетом того, что на английском порядок слов будет другой? А если еще и параметр будет меняться скриптом на лету…
Ну и переводить css придется руками, удобных инструментов для облегчения жизни еще нет.
Для статичных страниц может быть и можно применить, особенно если это страница-визитка верстальшика.
Для динамических страниц малопригодно. Как, например, можно на css локализовать фразу «Осталось %d элементов» с учетом того, что на английском порядок слов будет другой? А если еще и параметр будет меняться скриптом на лету…
Ну и переводить css придется руками, удобных инструментов для облегчения жизни еще нет.
а я такое полгода назад даже хотел сделать (для профилей на exp.io), но мне вовремя дали по рукам.
основной профит от такого извращения в том, что некоторые страницы можно было вообще не рендерить, а отдавать готовый кеш из базы, который достается одним key-value запросом, если бы не чертова локализация менюшек.
основной профит от такого извращения в том, что некоторые страницы можно было вообще не рендерить, а отдавать готовый кеш из базы, который достается одним key-value запросом, если бы не чертова локализация менюшек.
коммент в тему
chikuyonok.ru/2010/01/css-content/#comment-2599
chikuyonok.ru/2010/01/css-content/#comment-2599
бессмыслица какая-то
уж лучше XSLT применять, в т.ч. на стороне клиента
уж лучше XSLT применять, в т.ч. на стороне клиента
Боролись, боролись с таблицами. И тут на тебе, весь html в css… :-)
Это бессмыслено, мы экономим каплю воды в океане, нежели думать о реальных экономиях. Ну и что мы тут съэкономим? Для вывода теста есть HTML, а для обрамления CSS другого не дано, и не надо.
Sign up to leave a comment.
Локализация html-страницы средствами CSS