Именно как защита — сработает, но при этом IE оторвет bullets от последующих слов (включая, например, разрыв последовательности • test...) так как при break-word он делает разрывы где захочет, а не только по границам пробелов. За четкую диагностику причины его ошибки — спасибо.
Причем непонятно как это по-хорошему нужно лечить — даже float и display:table-cell; не помогают. Сейчас вижу решение только в том, чтобы фильтровать контент и заменять • на что-то другое. Иначе на самом казалось бы качественно сверстанном сайте при желании пользователи смогут порушить верстку ленты новостей или стены с комментами, выползая строками за пределы DIV-ов и залезая на соседнее содержимое. Как вариант сверху навесить другой DIV с overflow:hidden чтобы хотя бы не было видно этого переполнения.
То есть провайдеры проявляют большее усердие, чем даже депутаты? Предлагая блокировать по контенту. И уже видят возможность сделать деньги – ведь заявив, что развертывание такой фильтрации нерентабельно, можно следующим шагом попросить деньги из бюджета, вероятно.
Самое странное в этом стандарте это кодирование звука 22.2. Вместо какой-то гибкой или вообще инновационной звуковой системы предлагается просто развесить 24 динамика со всех сторон по фиксированной схеме. Но все равно стандартизация — это прогресс по сравнению с практически рандомным развешиванием большого количества speakers и использованием фиг знает каких матриц трансформации во многих реальных кинотеатрах, утверждающих, что у них якобы реалистичный объемный звук. :)
Пожалуй самый известный пример такой библиотеки, которая все контролы рисует сама, это QT. Вторая — это библиотека Swing в Java. Конечно есть много других, но менее известных.
Плагины глючат — поиск безглючного перед покупкой уже сам по себе работа, :) они нередко негативно интерферируют друг с другом или требуют изменений в разметке под них в коде документа. Когда плагинов много их загрузка или даже пустые запросы для валидации кэша (через ETag и If-Modified-Since) вносят большую latency, из-за которой страницы сайта грузятся медленно (даже если все они лежат на сервере в кэше в памяти). Все это делает интерфейс тормозным, с большой latency. Посмотрите на страницу какого-нибудь обычного сайта, сделанного на CMS типа Joomla или Drupal. Если сайт не совсем простенький – на нем как раз-таки поставлена куча платных плагинов. Они подключают десятки разных фреймворков и темплейтов. В результате страница тянет десятки файлов с сервера каждый из которых нужно каждый раз заново валидировать, так как на сайте могла поменяться версия плагина или CMS.
Этот вопрос можно решить и иначе — нужно так ясно описать правила обсчета layout, что разная имплементация в разных браузерах станет невозможной без грубого нарушения стандарта. Я считаю, что базовый язык описания разметки должен быть абсолютно детерминистичным и гарантировать bit exact воспроизводилось картинки на любом устройстве — естественно при использовании одного и того же шрифта и при одинаковых размерах окна. Такой детерминизм нужен для того, чтобы разработчикам сайта не приходилось вообще задаваться мыслью «а как это будет показано у клиента?». У клиента всегда будет показано точно так же, как у них самих. Браузеры должны конкурировать между собой соревнуясь в скорости отрисовки, закачки и наборе своих собственных встроенных фич. А не в том, как именно они рисуют страницу.
Вот например просто-напросто меню. Далеко даже не блокнот. И я отлично понимаю, почему их покупают — далеко не в любой web-студии найдутся программисты, которые пропишут так качественно работу с меню сами. Поэтому не супер-требовательному сайту намного удобнее купить готовый контрол.
Да и где оно там есть — в разработках комитета в виде модулей CSS4, которые еще даже самим комитетом не приняты? Пройдет еще 5 лет прежде чем это будет поддержано большинством браузеров.
Дело в том, что сама архитектура слишком комплексна и в то же время мутно описана, поэтому в полной мере реализовать ее крайне тяжело даже самым лучшим инженерам в командах разработки браузеров.
Поэтому imho утопия ожидать, что на этой архитектуре когда-нибудь движки стабилизируются настолько, чтобы одинаково отрисовать одну и ту же страницу.
Я считаю, что стандарт должен быть определен так четко и ясно, чтобы любая его имплементация давала бы bit exact изображение на экране при условии использования одинаковых шрифтов.
Потому, что сайт должен выглядеть так, как задумал дизайнер компании-разработчика, а не так, как его вздумалось нарисовать какому-то терминальному софту.
Если бы это было так, то на порядок бы упростилась разработка современных веб-два-нольных сайтов, которые предъявляют побольше требований к качеству UI, чем просто сайты-визитки.
В теории — да, но на практике в web-е в 99.9% вообще нет никаких тезаурусов, выносок и сносок с авто нумерацией, потому, что тогда верстка каждой статьи будет стоить слишком дорого для издателя (собственников сайта), ведь для этого придется нанимать супер-классного знатока CSS и выделять ему много времени. Поэтому если хотят выложить именно классно сверстанный материал такого уровня – то просто аттачат PDF в подавляющем большинстве случаев. :)
Если бы язык разметки был по-настоящему современным, сделанным from the scratch именно под полноценную верстку, а не исторически наслоенным и изначально заточенным под показ табличек хоть как-нибудь, то и верстать на нем было бы на порядок проще.
Но главное к нему бы быстро сделали мощные визуальные средства создания контента. Сейчас же если даже ты сделаешь полноценный издательский пакет, то выгрузить из него содержимое в HTML/CSS, а не в PDF — это сверхсложная задача.
Даже Word, над которым работают годами супер-классные инженеры и юзабелисты Microsoft, не умеет даже свою разметку, более слабую чем в специализированных издательских пакетах, выгружать в сеть так, чтобы затем ничего ни на что не наползало и все features верстки поддерживались бы. Потому, что не хватает выразительности и гибкости в CSS для выгрузки нормально сверстанного даже в word-е документа.
Если в нем будет, например, round box как стандартное средство, то на современной карте их можно будет рисовать 900 тысяч штук в секунду, наверное (примерно). Потому, что не потребуется тянуть с сервера PNG и рисовать квадрат декодируя пожатую растровую графику его по мере ее подкачки. А это в свою очередь сейчас, чтобы страничка отображалась в IE 8 хотя бы, а не только в FF и Chrome. Допустим, пройдет еще 3 года и вопрос конкретно с round box закроется, так как минимальной версией IE будет девятая. А что со всем остальным? Как нормально сверстать хотя бы такой блокнотик с закладками на CSS/HTML без извращений и большого количества JS кода вовсе не ради динамики, а прямо для самой отрисовки и позиционирования? Макетирование на JS — это бред сивой кобылы. Представьте себе, что верстку газет и журналов приходилось бы делать через написание скриптов на JS под каждый номер заново.
Есть не только twitter и pinterest. :) Посмотрите на реальные приложения для профессионального использования. В приложениях для работы еще и не такие интерфейсы требуются и реально используются на практике. И когда их реализуют в web, то из-за несовершенства языков разметки получается полный отстой – интерфейс глючит, он не pixel perfect, не эргономичен — так как удобные контролы сложны в реализации (хотя для пользователя просты).
Вообще же интерфейс не должен быть “простым” или “сложным”, это не та шкала оценки.
Интерфейс должен экономить нервную энергию и как важнейший из критериев – реально ускорять работу человека. Позволяя ему или сэкономить минуты, или же повысить свою производительность труда, производя больше полезных действий за единицу времени – при равной или меньшей нервной нагрузке.
Да, интерфейс должен быть с минимальным порогом вхождения, по возможности. Но простота – не самоцель. Потому, что всегда за какой-то границей простота вместо ускорения работы пользователя начинает замедлять ее – ему требуется больше кликов, возникает хождение по разным частям интерфейса для сбора всех нужных данных, а что-то просто нельзя сделать в простом интерфейсе и это начинают делать вручную.
Просто из принципа работать в современном браузере без JS это что-то сродни мазохизму. На любителя. :) Этак ведь можно на JS не останавливаться и пойти дальше. Можете отключить CSS, сайты будут загружаться еще быстрее. Потом куки выключить — ничего, что каждый раз заново пароль вводить. В том числе и сессионные — для полной секьюрности. Затем можно убрать все картинки — через них кстати тоже бывают эксплойты. После этого развивая тему можно выключить встроенные в браузер стили и везде поставить одинаковый фонт courier 12 кегля. И вернуться, таким образом, на 42 года назад в прошлое. Зато какая скорость загрузки страниц-то будет! :) И баннеры все снесет.
Например, есть большая «простыня» профайла пользователя. Когда включен JS она разбита на табы и имеет расползающиеся, по умолчанию свернутые секции. Когда JS нет, это будет ужасающей длины форма. Или же придется вообще разносить ее секции на разные страницы. Теряется до нуля вся usability в любом случае. И спрашивается — ради чего все это? Ради того, что некоторые пользователи ходят по порно-сайтам выключив JS, а затем ленятся включить его обратно?
Какая именно практическая потребность у Вас лично работать с сайтом без JS? Ну да, есть начальное может быть недоверие. Хотя обычно люди не ходят на какие попало URL-ы. Но дальше-то какой смысл себя мучить лишая современного динамического интерфейса? Я понимаю, что для сайтов-визиток можно с помощью jQuery решить проблему. Но для мало-мальски серьезного web 2.0 сайта на 100% избавится от JS это целый отдельный мини-проект.
Сейчас в HTML нужно вставлять div-ы просто для того, чтобы затем можно было бы правильно все сверстать. Я уж не говорю о эмиссии лишних элементов ради разных теней и круглых углов у квадратов не поддерживаемых в IE.
По второму пункту в CSS по стандарту нет ни наследования, ни шаблонов, ни макросов. Нет возможности четко ссылаться на свойства других элементов или иначе связывать их друг с другом. Попробуйте, например, сделать верстку в три колонки, при которой правая и левая колонки имеют одинаковую высоту в зависимости от их содержимого. Для этого придется лезть в HTML и плодить там бессмысленные семантически div-ы.
Нет, там нет глюков, все pixel-perfect – посмотрите под увеличением. :) Закладки до текущей активной специально привешивались именно к основанию блокнота, а не каждая к своей странице — потому, что так блокнот лучше воспринимался пользователем. Большинство людей смущало два ряда спадающих закладок – это путает и мешает быстро “схватывать” глазами текущую активную закладку.
Дело в том, что сама архитектура слишком комплексна и в то же время мутно описана, поэтому в полной мере реализовать ее крайне тяжело даже самым лучшим инженерам в командах разработки браузеров.
Поэтому imho утопия ожидать, что на этой архитектуре когда-нибудь движки стабилизируются настолько, чтобы одинаково отрисовать одну и ту же страницу.
Я считаю, что стандарт должен быть определен так четко и ясно, чтобы любая его имплементация давала бы bit exact изображение на экране при условии использования одинаковых шрифтов.
Потому, что сайт должен выглядеть так, как задумал дизайнер компании-разработчика, а не так, как его вздумалось нарисовать какому-то терминальному софту.
Если бы это было так, то на порядок бы упростилась разработка современных веб-два-нольных сайтов, которые предъявляют побольше требований к качеству UI, чем просто сайты-визитки.
Если бы язык разметки был по-настоящему современным, сделанным from the scratch именно под полноценную верстку, а не исторически наслоенным и изначально заточенным под показ табличек хоть как-нибудь, то и верстать на нем было бы на порядок проще.
Но главное к нему бы быстро сделали мощные визуальные средства создания контента. Сейчас же если даже ты сделаешь полноценный издательский пакет, то выгрузить из него содержимое в HTML/CSS, а не в PDF — это сверхсложная задача.
Даже Word, над которым работают годами супер-классные инженеры и юзабелисты Microsoft, не умеет даже свою разметку, более слабую чем в специализированных издательских пакетах, выгружать в сеть так, чтобы затем ничего ни на что не наползало и все features верстки поддерживались бы. Потому, что не хватает выразительности и гибкости в CSS для выгрузки нормально сверстанного даже в word-е документа.
Вообще же интерфейс не должен быть “простым” или “сложным”, это не та шкала оценки.
Интерфейс должен экономить нервную энергию и как важнейший из критериев – реально ускорять работу человека. Позволяя ему или сэкономить минуты, или же повысить свою производительность труда, производя больше полезных действий за единицу времени – при равной или меньшей нервной нагрузке.
Да, интерфейс должен быть с минимальным порогом вхождения, по возможности. Но простота – не самоцель. Потому, что всегда за какой-то границей простота вместо ускорения работы пользователя начинает замедлять ее – ему требуется больше кликов, возникает хождение по разным частям интерфейса для сбора всех нужных данных, а что-то просто нельзя сделать в простом интерфейсе и это начинают делать вручную.
Какая именно практическая потребность у Вас лично работать с сайтом без JS? Ну да, есть начальное может быть недоверие. Хотя обычно люди не ходят на какие попало URL-ы. Но дальше-то какой смысл себя мучить лишая современного динамического интерфейса? Я понимаю, что для сайтов-визиток можно с помощью jQuery решить проблему. Но для мало-мальски серьезного web 2.0 сайта на 100% избавится от JS это целый отдельный мини-проект.