SelenIT

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

Заметил странность Safari на iPhone: похоже, туда вшит какой-то примитивный ИИ, пытающийся найти на странице "главный текст" и увеличить шрифт в нем. Причем ладно бы уже увеличивал весь блок, так какое там: заголовки (даже с размерами, указанными в %!) оставляет как было по дизайну, а просто абзацы и списки раздувает раза в 4, получается безобразие. Алгоритм какой-то хитрый: содержимое дива с классом aside не раздувает, когда ставлю класс aside на основной блок, а у настоящего aside убираю — начинает раздувать бывший aside, но когда ставлю aside обоим — раскусывает, зараза, и основной див всё равно раздувает. Прямое указание размеров работает, но как относительное (т.е. чтоб сделать основной текст размером 15px, как по дизайну и как реально выходит для заголовков, для айфона приходится указывать размер 9px). Сталкивался ли кто-нибудь с такой бедой? Можно ли как-нибудь выключить эту "фичу" и отбить у порождения Джобса охоту к угадыванию мыслей без спросу, или хотя бы заставить увеличивать текст последовательно — вместе с заголовоками? Заранее спасибо!

Сорри, разобрался. Моя причина оказалась вообще дебильной — мой тестовый сервер, оказывается, был как-то так через XXX настроен, что SVG-файлы просто... не отдавал (выкидывал 404, хотя физически файлы на сервере есть). Локально всё работает. Буду разбираться со своим админом. А "белка", наверное, пусть разбирается со своим... и спасибо ей за классный сервис!

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

Куфон не годится. Дизайнерские шрифты используются для всего, включая основной текст. "Белкин" набор работает во всех актуальных браузерах (IE7-8, FF3.5+, Op. 9.5+, все живые вебкитные)... только вот айШтуки подвели. Но ведь поддержка SVG-шрифтов на них заявлена (в т.ч. на самой "Белке"). Может быть, кто-нибудь может подсказать сайт/сервис/пример, где @font-face заведомо фурычит под айШтуками? Попробую расковырять сравнительным методом хотя бы... UPD: а на соседнем fontspring.com — работает (напр., http://www.fontspring.com/fonts/typodermic/jesaya — вкладка @Font-Face Demo). В CSS та же запись от той же "Белки". SVG-файлы на первый взгляд полностью аналогичны. В заголовках, что ли, дело... или кодировках?...

По-моему, выводы Сагалаева куда больше применимы к жизни, чем бездумное повторение мантры "всё должно быть валидно точка": Что здесь "неприменимо к жизни"? Беда доктайпов в нынешнем вебе — браузеры используют их не по назначению, не для того, для чего валидаторы. Поэтому иногда поставить стрикт-доктайп необходимо именно ради отображения (напр., с транзишнл-доктайпами глючит inline-block в IE8 и Операх), при этом не всегда возможно отказаться от <iframe>, <ol start> и т.п. Моё мнение — пара-тройка таких отступлений от "неприменимого к жизни" стандарта допустима, если вебмастер может веско аргументировать каждое из них. Да, это исключение, которое только подчеркивает необходимость соблюдать стандарт во всём остальном (не только синтаксисе, но и семантике!).

Имхо, лучше на статью Сагалаева

Главный вопрос не "как", а "зачем"? Что должно измениться по сравнению с текущим поведением анимации? Если только скорость — там у ф-ции fadeOpacity есть опциональный третий параметр специально для этого...

Именно это я и имел в виду . Спецификация включает в себя и то, и другое. А валидатор проверяет только первое. Поэтому валидность кода не гарантирует его соответствия спецификации. А вот у человека, понимающего и уважающего спецификацию, код будет получаться валидным сам собой. Поэтому знание спецификации первично, валидатор вторичен... и никак иначе!

Пробую вставлять шрифты, пользуясь онлайн-генератором от fontsquirrel.com (AFAIK самый известный). Он дает на выходе пакет из 4-х форматов, один из которых — SVG — вроде как специательно предназначен для iPhone/iPad. На практике на этих девайсах шрифт не подхватывается (похоже, что вообще берется дефолтный системный — на айфоне у него даже размер другой, крупнее). Что характерно, онлайн-демо на самом сайте (вот, например) тоже не работают. Никто не сталкивался с такой проблемой? В какую сторону копать? В принципе-то ведь SVG-шрифты должны поддерживаться...

Крокфорд считает, что явный разделитель в виде точки с запятой читабельности, наоборот, способствует. Как закрывающий тег в HTML (кстати, с улучшением читабельности при обязательном закрытии тегов я бы скорее поспорил — во многих случаях она лишь иллюзия. Тем более нужно стараться, чтоб нечаянно не засорить их все

Не обязательно. Валидность — соответствие указанной схеме (что в чем может содержаться и т.п.). Код, в котором абзацы размечены <br/>-ками, заголовки — тегами <b> и <strong>, списки сделаны через <blockquote>, а все названия улиц обернуты в <address>, может быть полностью валиден в HTML4/XHTML1, однако он прямо противоречит букве и духу соотв. спецификаций. Есть старая, но не утратившая актуальности статья по теме, там есть веселый пример и познавательные подробности.

Имхо, проблемы с IE8 и т.п. чаще происходят со сложным CSS, натянутым на конструкции, подобранные "методом тыка", без понимания происходящего (схлопывание/несхлопывание маргинов при hasLayout'е, с которым пытаются тупо бороться добавочными отступами, и т.п.). Их возникновение от валидности кода зависит мало. Правда, положительная корреляция есть: разбирающемуся в сути человеку проще сделать код и работающим, и валидным. Но о5 же, всё зависит не от валидатора, а именно от человека.

Чаще всего это следствие изначального неверного выбора инструмента (о чем я и говорил выше). На порядок реже — недоработки самих стандартов (типа зазря выкинутого атрибута start для OL). Чем мне нравится HTML5, так это тем, что в нем таких граблей гораздо меньше (не зря разработчики спеки стремились "мостить проторенные тропы"). Я не про заказчика, а про внутреннюю документацию, для других разработчиков и тестеров.

Моё имхо — код должен быть адекватным а) той задаче, которую он призван решать, б) той среде, в которой он будет исполняться. Исходя из этих двух посылок, подбирается наиболее подходящий инструмент. Верстается научная статья с кучей формул и графиков — логично выбрать XHTML+MathML+SVG (и отдавать его как application/xhtml+xml, естественно). Верстается обычный сайт, важную часть аудитории которого занимает IE7-8 — логично выбрать HTML4.01 Transitional или HTML5 (но держа "в уме" незрелость его поддержки и не злоупотребляя новыми тегами и контролами форм). Верстается HTML-письмо (в том 0.01% случаев, когда это нужно не для спама — наш выбор HTML3.2 (тоже действующий стандарт, между прочим, как раз для случаев, "когда CSS недоступен"). А изначально выбирать инструмент, исходя не из практической надобности, а из соображений "моды" или "крутизны" (напр., XHTML 1.x, зная, что отдаваться он будет как text/html, или Strict-вариант для сайта с функционалом, построенным вокруг iframe), а потом плясать с бубном, пытаясь и свою задачу решить, и валидатора ублажить (извращаясь через динамическую вставку тегов и атрибутов скриптами и т.п.) — имхо, глупость. Вообще валидатор — программа очень тупая. Она не знает, зачем вы делаете тот или иной финт (напр., оборачиваете <div> в <ins> — чтобы выделить свежее добавление актуальной информации или всего лишь чтобы "незаметно для валидатора" впихнуть этот див в ссылку и не может сказать, адекватный ли вашей задаче код у вас получился. Абсолютно валидный по DTD код может быть абсолютной ересью с точки зрения семантики, здравого смысла и браузеров (особенно если отдается не с тем типом контента, который подразумевал валидатор — например, запись <div/> вполне валидна для пустого дива в XHTML, но при text/html для любого браузера это незакрытый тег!). Поэтому пользоваться валидатором, безусловно, надо — он прекрасно ловит случайные описки и т.п. и напоминает о неочевидных вещах (особенно в HTML с его неявным закрытием элементов, как в вышеприведенном — кстати, валидном в HTML! — примере с <tr><td></td><tr>). Но не надо приписывать ему всеведения, всемогущести и силы закона. Тем более, валидаторы, как и браузеры, пишутся людьми и тоже порой ошибаются. И если важен самый стандартный режим отображения в браузере (никаких "почти стандартных" и "limited quirks"), HTML5 по каким-то внешним причинам не подходит, но некоторые ссылки непременно должны открываться в новом окне — я не вижу катастрофы в том, чтобы поставить Strict-доктайп и оставить target у ссылок, не заменяя их неочевидными скриптовыми костылями (но обязательно указав эту единственную ошибку валидации как known issue в документации проекта). В общем, первым делом нужно понимать, что и зачем ты делаешь и как и почему оно работает там, где работает. А уже вторым делом — чтобы это было чисто. И при этом стараться учиться делать чисто с самого начала, чтобы раз от раза "вычищать" приходилось всё меньше и меньше. Для этого валидаторы тоже полезны, но они не заменят вдумчивого чтения спецификаций...

Вероятно, потому, что в JS глобальные переменные могут создаваться неявно (и неочевидно), и такие неявные засорения глобального объекта — однозначное зло (с этим Крокфорд не спорит). Вот что он сам пишет по поводу:

Насколько я понимаю, логика Крокфорда не то чтобы требует, но настоятельно рекомендует исправлять то, что разрешено при некоторых условиях, на то, что разрешено всегда. Чтобы не огрести проблем, например, при минификации того же скрипта в одну строку (тут могут аукнуться пропущенные ";") и т.п. Т.е. скорее не "не ешь кашу ложкой", а "не ешь мясо руками" (в принципе-то, ничего страшного, удобней даже, чем вилкой и ножом... но на приеме у англ. королевы может случиться конфуз.

Если я ничего не путаю, нынешняя спека ECMA (5-я редакция) во многом появилась благодаря тому самому чуваку (Крокфорду), который уже десяток лет ведет эту поделку. И да, с некоторыми вещами в прошлых редакциях он (о5 же если я ничего не путаю) был не совсем согласен... А еще этот чувак кое в чем соперничает с Чаком и Онотолеем...

Great Rash, еще раз спасибо. Про варианты с подменой кнопки рисунком и наложением поверх прозрачного "родного" контрола (включая скрипты, делающие это ненавязчиво) я в курсе, но в "стилизации по частям" мне померещились было альтернативные решения "малой кровью"... захотелось их изучить. Пожалуй, на досуге всё-таки покопаюсь в биндингах — вдруг... чем шут не чертит?

Great Rash, большущее спасибо за разъяснения! Теперь вижу, что толку особого нет, но по крайней мере приблизительно знаю, откуда что растёт

Да, замечание про !important дельное, но этим же не загадка не исчерпывается? Например, размеров многострадальной файловыбиралки я в том файле не нахожу, значит, они фиксируются где-то еще? Больше всего меня интересует, откуда вообще берутся эти "вложенные инпуты". Судя по тому, что в файлике часто упоминаются -moz-binding'и (в частности, platformHTMLBindings.xml), предполагаю, надо копать туда?

Практически. Точнее, относительно окна браузера. Если окно скукожить до очень маленького размера, картинка попадет в правый див и станет видна. Так работает во всех браузерах, кроме IE6.

В FF есть файл forms.css (под WinXP — в подпапке res папки установки), в котором написаны интересные вещи (спасибо мозилловскому форуму за наводку, а этому форуму — за наводку на мозилловский). В частности, упоминаются некие select > input[type="button"] input[type="file"] > input[type="text"] input[type="file"] > input[type="button"]а также их особые состояния, комбинации и т.п. Что это? Действительно ли для Мозиллы некоторые элементы форм являются составными и если да, можно ли стилизовать их по частям (я попробовал — "в лоб" не получилось, но, может, я что-то делал не так)? Или эти строчки — пережиток какой-то древней версии движка (версия навеяна комментом "Styles for old GFX form widgets" в начале файла, сразу после лицензии)? Или такая магия работает только в специфических условиях (под особой ОС, только для XUL-интерфейсов и т.п.)? Прошу поделиться тайной...

Всё-таки это был перформанс по уже существовавшему анекдоту, так что не считается

Да уж, ох и намудрил дизайнер, ох и намудрил А слоями порезать это дело (нижний слой - деревяшка с прижатием к низу, средний слой - цепи, верхний - колечки, которыми цепи оканчиваются, два верхних слоя — прозрачные PNG) никак не получится?