SelenIT

еще более вероятно — не обнулен дефолтный у body

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

Девочке-секретарю, действительно, знать HTML не обязательно, она может воспользоваться чем-то типа визивига. Но если человек всё-таки хочет продвинуться из секретарей в контент-менеджеры и берется осваивать любой (x)HTML, то, имхо, первое, что он должен уяснить — то, что разметка является лишь "инструкцией" для браузера по построению DOM (на которую уже вешаются стили, скрипты и пр.), а вовсе не тем, что браузер реально отображает. Кстати, из этого знания интуитивное представление о последствиях (не)закрытия тега в правильном месте вытекают автоматом, обратное же неверно.

Обратные примеры, когда люди вынужденно тратили больше времени, ошибочно положившись на явное закрытие тегов, я тоже приводил . Имхо, глобально беда в обоих случаях одна и та же — незнание спецификации (увы, не освобождающее от ответственности за ее нарушение. И граница между "системами разработки", на мой взгляд, проходит не по линии "закрывать/не закрывать", а по линии "делать по спецификации/делать по интуиции, привычке etc.". Что сама спецификация (любая!) тоже несовершенна и содержит внутренние огрехи проектирования — это уже другой вопрос. Философский Идея рефакторинга разметки в абсолютно др. язык прямо в текста исходника, минуя логичную фазу десериализации в DOM/сериализации в нужное представление (тривиальными штатными средствами), по-прежнему кажется мне, гм... странноватой... ну да ладно. Для чего было - это уже история. А реальность в том, что этот парсер просто есть, именно такой (а в новых браузерах — еще и стандартизованный). И заставить его работать по другому алгоритму, увы, нельзя... Вот я и утверждаю, что людям тоже полезно оперировать ДОМом. Это сразу решит массу надуманных проблем и холиворов

Я воспринимаю опциональные закр. теги всего лишь как частный случай принципа TIMTOWDI. Структура как раз четкая донельзя (главный контейнер > блоки с блоками > блоки с текстом > текст > фрагменты текста, TABLE > TBODY > TR > TD), просто есть несколько вариантов ее правильного описания. Алгоритм парсинга, да, чуть сложнее (хотя нынешние мобилки поголовно справляются), но это плата за надежность и предсказуемость результата. В том же XHTML, на мой взгляд, четкости структуры и то меньше (tbody в table может быть, а может и не быть — наперед никак не угадаешь). Имхо, это если рассуждать в плоскости "тегов, слешей и кавычек". Если изначально оперировать понятиями DOM, то и структура сразу проясняется, и семантика становится нагляднее. Кстати, семантическая разница между div и span состоит как раз в их структурной роли: первый — абстрактный контейнер блоков, второй — абстрактный текстовый фрагмент. А поведение IE7- (игнорирующего закрывающие теги там, где они по факту бесполезны), хотя и идет вразрез со стандартом, но по-своему логично, имхо. Тем самым как раз страхуется целостность и предсказуемость структуры, исключается даже случайное появление DOM-мутантов типа UL ? LI ? LI ? LI ? ВНЕЗАПНО H2 ? LI Правда, такой подход плохо совместим с магическим царством CSS, где любой элемент может прикидываться любым другим. Но это уже другая история.

Ну я просто исходил из здравого смысла, что обрезанные краем полблока неэстетичны

Имхо, как раз не нужен. Насколько я понял, элементы именно должны переноситься на др. строку — и скрываться за границей overflow. А float или inline-block, да, можно выбрать по вкусу.

Если высота блоков одинакова, то float для блоков и height + overflow:hidden для контейнера. Если нет, то, похоже, только скриптами.

Сюрпризы с анонимными блочными боксами при кажущейся закрытости всех тегов случаются. А положение междутеговых текстовых нод с пробелами бывает критически важно при оформлении списков инлайн-блоками. Конечно, можно писать код как <ul> <li> ... много текста 1 ... </li><li> ... много текста 1 ... </li><li> ... ... </li><li> ... много текста n ... </li> </ul>но мне субъективно "приятнее", когда однотипные по смыслу строчки выглядят одинаково... Есть мнение, что XHTML полюбился разработчикам как раз тем, что его универсальные и единообразные формальные правила давали ощущение, что думать о функциональной разнице элементов (пустой/непустой, контейнер блоков/контейнер текста и т.д.) больше не нужно, что об этом уже "подумала" технология (хотя наличие приложения C в спеке и здравый смысл говорят об обратном). Т.е. к изначально невысокому порогу вхождения по факту добавилась еще большая халява. Но это тема другого холивора Аргумент, согласен. Правильную подсветку при неявном закрытии многие редакторы пока не осилили... p.s. подправил последствия глюка, заодно собственные мысли чуть причесал

Сугубо имхо - всё-таки хорошо, что нет. А то на одного человека, понимающего, зачем и для чего это ему нужно, нашлось бы под тысячу желающих отстрелить ногу себе и товарищам. А то и пользователям. Хотя на какой-то части хотя бы XBL есть...

Сорри, но по-моему как раз вот это - пример тяп-ляп-подхода. "До конца не уверен, но вроде всегда работало..." А если будет честный application/xhtml+xml, а в скрипте знак "<" затесался? По-моему, поначалу абзац, пункт списка и т.п. вообще рассматривались не как контейнеры, а как что-то типа пунктуации (вот как в ворде есть символ абзаца, который ^p, иногда еще как ¶ отображается - вот так и <P> рассматривался). Потом уже удачно SGML вспомнили и туда же привязали, оттуда закрывающие теги подтянулись, а с ними и восприятие элемента как контейнера, мысли о его семантике и, в конечном счете, идея XML . Но браузеры, в которых абзац воспринимался как "от ¶ до ¶" всё равно уже были... А английское paragraph - это наш абзац ("красная строка" по-школьному) и есть. Наш параграф по-ихнему section, в <section> блоки вкладывать можно Во-первых, 16 элементов закрывать запрещено. Почему - по спецификации . И чтобы подчеркнуть их особый статус, что у них ни при каких условиях не может быть контента (см. выше пример s0rr0w с <img>...</img>). Во-вторых, как ни забавно, конструкция на трех ножках в общем случае-таки устойчивее, чем на 4-х , и в ситуации "а-ля ворд" мы с CSS-движком всегда можем рассчитывать на два простых и надежных, как лопата, блочных бокса подряд, весь текст в надежной "упаковке" и легко управляем. В отличие от XML-образной радости типа где между этими блоками ВНЕЗАПНО111 появляется неведома зверушка без роду и племени, вокруг которой приходится спешно городить огород из анонимных боксов (с неуправляемыми дефолтными отступами и т.п.). Это, конечно, проблемы главным образом CSS-движка, но сам факт таких сюрпризов как-то не радует.Собственно, главная мысль, которую я хочу донести: закрытие всех тегов - не панацея и не гарантия отсутствия проблем. И при явно закрытых, и при неявно закрытых элементах всё равно нужно думать о структуре разметки и понимать ее. Но механическое закрытие тегов может создавать иллюзию контроля и безопасности, с которой будет больно расставаться. Особенно если автор думает, что пишет страницу на одном языке, а парсер "думает", что читает ее на совсем другом (как одно и то же слово Gift по-английски - "подарок", а по-немецки - "яд", а слово "глюк" по-немецки - "счастье", а по-нашему...) Я не "фанат незакрытия тегов везде, где можно", сам не закрываю только тогда, когда это приносит явное упрощение и удобство (те же инлайн-блоки). Но фанатизм в стиле "не надо думать, закрывать надо!" считаю как минимум не менее вредным. Поэтому и выступаю тут в роли "адвоката дьявола" (а на деле никакого не дьявола, а обычного, да, в неумелых руках - потенциально опасного, но в умелых руках и к месту полезного и удобного - инструмента)... Всё так и есть. Только этот алгоритм, со всеми исключениями, уже написан. И реализован в 2 с половиной браузерах из 5 основных (FF4+, Хром 7+, Опера 12+). И это - реальность. Кстати, XML - тоже реальность, причем гораздо более давняя. Но почему-то желающих работать только в этой симпатичной реальности немного, все больше норовят навязать чужие правила несчастному "старичку" HTML...

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

Что за неведома зверушка? Если речь о предполагаемой ("возможно, когда-нибудь в будущем...") миграции на XML-сериализацию, то отнюдь нифига. Нужно еще ручками дописать все недостающие неймспейсы (особенно корневой), завернуть все скрипты и стили в CDATA, поставить правильный атрибут для языка и т.п. Но такое преобразование (как и обратное) делается в два счета средствами DOM, стандартными средствами той же html5lib и даже библиотек попроще. Уже сейчас. Имхо, 12 лет бесплодных попыток W3C скрестить ежа с ужом (помехоустойчивость и простоту HTML для пользователя ценой сложности для парсера с простотой XML для парсера и кодера ценой выноса сложности в кучу добавочных соглашений "за скобками") - достаточный срок, чтобы признать: HTML и XML - разные вещи, требующие существенно разного подхода. И "совместимость" одного с другим и обратно - миф. И чем пытаться усидеть на двух стульях, тратя время и силы не "неукоснительное соблюдение взаимоисключающих параграфов", не лучше ли полнее использовать преимущества каждой из технологий в той сфере, где она сильнее всего (HTML - как твердой, надежной и стандартной основы представления инфы для конечного пользователя, XML - как гибкий, универсальный и стандартный связующий механизм для гетерогенных систем)? Одно из таких преимуществ HTML - возможность не закрывать определенные теги (без ущерба для дела), одно из преимуществ XML - возможность закрывать любые теги любым способом (хоть <img/>, хоть <img></img>)...

Умных насторожит явное несоответствие отображаемого чего-то задуманному. А дурака и "желтый экран смерти" не остановит - он до последнего будет винить браузер, коннект, фазы луны и т.п., только не свои руки и извилины... Вот не могу я согласиться, что закрытие всех тегов - показатель порядка. Напротив, привычка закрывать теги бездумно и на автомате скорее может породить того уродца с </img>. Имхо, в коде всё должно быть по делу, и все закрывающие теги должны действительно что-то закрывать (как </div>), а не "делать вид, что закрывают"...

Например, однозначность итоговой DOM (в частности, расположение пробельных текстовых нод - внутри элементов или между ними, что бывает критично при использовании inline-block) и независимость ее от форматирования кода. Гарантированная кроссбраузерность (IE7- всегда игнорируют закрывающие </li> внутри списков, при неявном закрытии DOM во всех браузерах одинакова). "Незначащие" закрывающие теги могут ввести в заблуждение, например, что "можно вставить блочный элемент в абзац" и привести к неприятным сюрпризам при отладке, без них о таких вещах приходится помнить, что в итоге ведет к лучшему пониманию логики кода. Да и экономия букв может быть значимой, например, в "спортивных" задачах-конкурсах типа "впихнуть что-то прикольное/полезное в 1/2/5 кБ", а также при получении больших фрагментов разметки через AJAH... Писать так нельзя , но парсер не умрет, встретив такую бяку. В DOM попадут картинка и текстовая нода, остальное будет отфильтровано как мусор. Вот как Опера внутри себя выкручивается с генерируемым контентом для <img>... впрочем, это ее личный выбор и трудности

http://cssing.org.ua/2010/04/26/overflow-hidden/

Насколько я в курсе, HTML5-парсер как раз разработан с запасом устойчивости к кривизне на входе и умеет строить вменяемую DOM из практически чего угодно, нормализуя прямо по ходу парсинга (все нужные "прихватки" там по сути захардкоданы). А неправильные страницы множатся и тупо путем копипасты. По-хорошему, конечно, качество выходного кода должны бы обеспечивать инструменты публикации (те же CMS), но кто ж их всех обяжет...

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

Программеры делают себе медвежью услугу сами, когда берут инструмент не по задаче. И для XML-парсера абсолютно пофиг, закрыт <p> явно или автоматически - ему достаточно, что это не XML. А более-менее нормальные инструменты умеют парсить и то, и другое по ситуации, и в случае HTML им опять же пофиг, как что закрыто (тот же DOMDocument в PHP умеет парсить и то, и то, и преобразоывать итоговую DOM в любой из вариантов). Если кто-то не освоил ножовку по металлу - это ж не повод не пользоваться металлом и делать всё из дерева, разве нет?

Насколько я понимаю, для него есть два пути обновления - радикальный (сразу на последнюю версию) и "security & stability", по капле (в основном предназначено для старых компов, которые новую версию "не потянут"). Видимо, осторожные/консервативные юзеры этим путем злоупотребляют. А начиная с 4-й версии обновиться можно только полностью, без полумер.

С этой точки зрения, пожалуй, HTML вообще не должен был появляться . Весь веб должен был бы быть изначально XMLным, веллформным, привычным к "драконовскому" контролю ошибок и т.п. Но всё же хотелось бы поговорить о суровой прозе жизни

Насколько я в курсе, по крайней мере до недавнего времени все ajax-загрузчики работали именно через него Еще есть вариант загрузки через Flash (с преимуществом в виде возможности узнать размер файла до отправки, ЕМНИП, так был сделан загрузчик вконтатике и аналоги). И новые модные API для работы с файлами etc., но их я, каюсь, пока глубоко не копал, т.к. кроссбраузерности им пока не хватает (имхо)...

Пардон, формальный номер версии у Хрома присутствует (у моего 15, клянется, что пока последняя стабильная. По-моему, на номер FF уже вполне можно начинать смотреть так же формально. Заказчикам, да, нужно время попривыкнуть - но выбора им, похоже, всё равно не оставили...

Часто приходится? Именно с конечной клиентской разметкой, а не промежуточными слоями? Так адекватному HTML-парсеру без разницы, а если нужно парсить чужой неизвестный код, всё равно приходится быть готовым к худшему. Та же html5lib, ЕМНИП, позволяет работать с любым сколь угодно кривым HTML (точнее, полученным из него DOM-деревом) как с XML-инфосетом, со всеми плюшками типа XPath/XSLT. А плохому инструменту всегда что-нибудь мешает ...что и требовалось доказать?

Ну, чужая страница - потемки на то и чужая, что контроля над ней у нас априори нет, поэтому приходится заранее озаботиться инструментом для ее парсинга, чтоб был как минимум не слабее tidy (типа чего-то такого или html5lib). Парсить любой HTML регулярками - тот еще гемо "челлендж", а XML-парсер может упасть и на вполне аккуратной HTML-разметке из-за пресловутых <br> вместо <br/>. Но с адекватным задаче инструментом, имхо, это не такая уж проблема. Меня же интересуют потенциальные траблы от использования легальных вольностей HTML в собственном коде. И грань, где использование переходит в злоупотребление