SelenIT
-
Posts
4,327 -
Joined
-
Last visited
-
Days Won
140
Content Type
Profiles
Forums
Calendar
Store
Everything posted by SelenIT
-
Новые версии сказываются, например, при переходе к интертрепации заголовков по HTML5-ному (FF4+, Chr.7+ — размер заголовка не по номеру, а по вложенности секций). Плюс у совсем старья бывали свои спецэффекты (вышеупомянутый "нестандартный" маргин body у IE7-, больший дефолтный отступ между абзацами там же, ненулевой дефолтный padding у body у какой-то ископаемой Оперы типа 8.0 и т.п.). Насчет холивора ресет vs. нормалайз — лично я предпочитаю нормалайз, но не к "среднестатистическому браузеру", а к тому, как задизайнено в макете для основного контента
-
Такой прикольный рыжий чувак
-
Как варинат — BOM-метка в начале файла инклюда...
-
Нифига вы не поняли, простите. Ответ вам дали тремя постами выше. А большой косяк - это table height="100%" и подобные архаизмы в верстке.
-
Есть 2 класса доктайпов — правильные и неправильные. В вышеприведенном докладе советуют самый короткий из правильных доктайпов. При правильном доктайпе браузеры работают по стандарту (насколько умеют), при неправильном (или вообще без) — как придется. Нужно использовать правильный доктайп (любой, но проще всего — короткий) и стандартные инструменты. Стандартная замена 12 лет как вымершему height для table — height: 100% в CSS для нее же (ну и html, body { height: 100% }, чтоб цепочка наследования не рвалась). Саму table как основу каркаса обсуждать не будем Доктайпов, позволяющих избирательно включать/выключать поддержку стандартов для одной-двух фич, не бывает (кроме одного исключения).
-
Убрать <p align="justify"> перед доктайпом. Перед доктайпом не должно быть ничего (кроме пробелов, хотя и то нежелательно). Иначе IE сходит с ума и воображает себя 5-й версией.
-
Поздравляю!
-
<input type="number">?
-
Присоединяюсь к поздравлениям!
-
+ классика по той же теме.
-
Правда, через несколько лет после этого они успели забросить огромную долю XML (почти всё, над чем работала группа XHTML2) назад, в пользу HTML(5) Хотя следить действительно лучше (имхо) именно за WHATWG-шной спекой — обычно она актуальнее.
-
Да, со старыми IE я-таки был излишне оптимистичен: document.createElement('article'); и т.п. включает стилизацию только тех модных элементов, перед которыми был вывод чего-то знакомого (визуальных эл-тов HTML4 или просто текста) на экран. Иначе они всё-таки попадают в неявный <head>, а не body. Но тем не менее - это проблема старых IE (баг в лекарстве от их бага). А правильный html5shi(m|v) мог бы недостающий body и сам добавить
-
2. В браузерах IE6-8 для применения CSS к новым элементам требуется элемент <body> Я про это написал. Если просто написать <script> document.createElement('article'); document.createElement('footer'); // и т.д. </script> если ничего не путаю, всё фурычит и без явного <body>. Что lang для HTML полезен, спору нет, но вопрос был в "неприятных сюрпризах" от его отсутствия. Насчет "лучше перестраховаться" - в целом согласен, но панически бояться необязательных тегов там, где они действительно необязательны, имхо, тоже ни к чему. А баги стороннего софта при одном из вариантов стандартного синтаксиса нужно адресовать разработчикам этого софта Надо не слушать горлопанов, а посылать их ровными рядами в RTFM. Просто обидно за в целом неплохую технологию, что на нее постоянно клевещут, обвиняя в несуществующих грехах. И нет сил уже видеть столько мифов и домыслов вокруг нее, хотя эти мифы и домыслы на раз развеиваются прочтением одного абзаца спеки. Новичкам еще худо-бедно простительно, но от модераторов хочется более серьезного подхода...
-
AAARGH!!!! НУ ЧИТАЙТЕ ЖЕ! ЧЁРТОВЫ! СПЕЦИФИКАЦИИ! НАКОНЕЦ! Ни одна. Спецификация. SGML/HTML. Никогда. Не. Разрешала. Перекрытия. Тегов. И ни одна. Спецификация. X(HT)ML. Никогда. Не. Обвиняла. HTML. В этом. (Спека XHTML1.0 обвиняла браузеры в излишней терпимости к этой ошибке, но никто не читает текст черным по белому - только "красные" и "зеленые" примеры...) HTML и X(HT)ML различаются разрешенными вариантами сокращенного синтаксиса. Первый явно выделяет пустые элементы (те, которые заведомо не могут иметь никакого содержимого - br, hr, img...) тем, что запрещает для них закрывающий тег (end tag: forbidden), подчеркивая этим их особую роль. Второй разрешает "самозакрытие" тегов (основанное на т.н. "Null End Tag"-синтаксисе из того же SGML), причем - формально - любых, хоть пустых, хоть нет. И для SGML-парсера это "самозакрытие" - источник как минимум неоднозначности. Ну и правильные способы закрытия элементов различаются, хотя и там, и там их по два: в X(HT)ML - закрывающий тег и "самозакрытие" для всего, в HTML - явный закрывающий тег и контекст, в котором элемент однозначно обязан закрыться (для элементов с опциональным закрывающим тегом). X(HT)ML-ные правила, конечно, нагляднее, очевиднее и проще для понимания. С HTML-ными правилами приходится как минимум запоминать (или подсматривать в справочнике), какие элементы являются пустыми, для каких закрывающий тег необязателен и т.п. Но загвоздка в том, что X(HT)ML-ная простота и наглядность работают только с правильным Content-type, в остальных случаях HTML-ные особенности нужно всё равно как минимум учитывать. В двух словах: в HTML за структуру разметки отвечает кодер, а за структуру DOM - браузер. В XHTML - наоборот. Каждый сам выбирает, что ему важнее - но надо помнить, что браузер отображает и стилизует именно DOM... В остальном это и впрямь дело вкуса. Хотя пользоваться правилами того языка, на котором разметку будет читать браузер - имхо, немножко честнее А что с этим не так? Для быстрых проверочных примеров никогда не ставлю лишние теги, никаких проблем не наблюдаю (ни со скриптами, ни со стилизацией). То, что html5shi(v|m) когда-то требовал явно открытого body - проблема этого конкретного скрипта, а не разрешенного (более того, рекомендованного гуглом!) синтаксиса...
-
Положим, не маленькой, а большой, и не хитростью, а глупостью, ну да ладно... в 90% случаев, действительно, будет работать "почти как надо", чтобы "сдать и забыть" вполне сойдет...
-
Другими словами, задать правой колонке отдельный блочный контекст форматирования. Кроме overflow: hidden, для этого годятся display: table или display: table-cell. А чтобы колонка растягивалась на всю доступную ширину даже при нехватке контента, можно использовать такую добавку.
-
Поздравляю!!!
-
Потому что нечто.style.чтоТо — это что-то, заданное в атрибуте style для "нечта". А действующие стили видны в window.getComputedStyle(нечто).чтоТо или — только в старых IE — в нечто.currentStyle.чтоТо.
-
Имелось в виду что-то такое? Или что подразумевалось под выносящей мозг взаимоисключающими параграфами фразой "отцентрировать справа"?
-
Ну да. Ну а что делать-то? Написать открытым текстом тоже ведь не вариант...Может, придумаем какое-нибудь кодовое слово для таких ситуаций? Или вообще выработаем конвенцию вешать подобную антифункциональность на отдельный класс с говорящим именем типа .kgam (заодно потом в случае успеха просветительской работы с заказчиком этот класс можно будет просто убрать)?
-
Нет, скорее чтобы новичок, разбирающий этот код как пример и наткнувшийся на такую вещь, понял, что это нештатная ситуация/вынужденная недоделка, а не общепринятая норма ("все так делают"). Как и с нестандартными CSS-подобными костылями (как учит нас великая Лиа Веру ).
-
Верхний вариант эмулирует (но не до конца) инлайн-блок для изначально блочных элементов, для которых нижний вариант (прямой и бескостыльный) не работает.
-
Телепательная машинка подсказывает, что автору темы всё-таки надо разбить текст на абзацы (которые <p>...</p>).
-
Вчерашняя хабрастатья в тему: http://habrahabr.ru/post/146109/. Минимум 3 из упомянутых там ошибок здесь налицо. Забудьте все ужасы наподобие Объект Date в JS прекрасно умеет сам брать на себя всю мудреную календарную арифметику. Вот похожая тема была: http://forum.htmlbook.ru/index.php?showtopic=31133
-
Ну хотя бы поставить коммент а-ля "/* TODO: добавить :focus */"... чтобы было понятно, что вебмастер не ламер, а у него просто руки не дошли
