Проблемы из-за незакрытых тегов

[s0rr0w]

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

Так это потому что в CSS до сих пор ( ) нет ни одного намека на поведение элемента. Если бы появилось, то я бы послал HTML к чертовой бабушке и забыл бы как страшный сон!

[SelenIT]

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

Хотя на какой-то части хотя бы XBL есть...

[s0rr0w]

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

Я тебя умоляю... Буратины везде найдут способ создать другим проблемы...

[Justnewone]

Пардон, не убедительно как-то. По моему ситуация из космоса, с параграфами.

Если бы сказали, дескать, "а вот надо еще и время терять, закрывать тег...." то я бы больше понял чем это.

Были ли у меня проблемы - отвечая на Ваш вопрос - да!

Были ли у меня проблемы с моим подходом - нет!

Я же писал вроде, что человеческий фактор он есть всегда.

Мне как-то пришло в голову, что они просто хотели порог входа понизить, "о, гляньте, никаких больше скушных обязательных процедур". все сказали "ООО!" и спросили правда, некоторые, "Пардон муа, а можно так же все все остальные теги парные не закрывать, по аналогии и так сказать для порядка и еще большего снижения порога?" на что разрабы стыдливо попрятали глаза.

[rus]

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

[SelenIT]

ситуация из космоса, с параграфами

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

<ul>
   <li>
      ... много текста 1 ...
   </li><li>
      ... много текста 1 ...
   </li><li>
      ...
      ...

   </li><li>
      ... много текста n ...
   </li>
</ul>

но мне субъективно "приятнее", когда однотипные по смыслу строчки выглядят одинаково...

они просто хотели порог входа понизить

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

с незакрытыми тегами в редакторе будет не удобно находить нужный блок

Аргумент, согласен. Правильную подсветку при неявном закрытии многие редакторы пока не осилили...

p.s. подправил последствия глюка, заодно собственные мысли чуть причесал

Edited November 10, 2011 by SelenIT

[Justnewone]

Все мерно благодарен, однако, к барьеру ))

Как раз, как следствия "возможного незакрывания тегов", а как по мне, так просто отсутствия четкой структуры, Симбиоз "семантика" + "отстутствие структуры" мне кажется в изначалии учербным и просто миной замедленного действия, как, сосбственно и происходит. Типичный пример: в P мы можем спокойно располагать не несущий семантики спан, но не можем так же не несущий семантики див.

Случай с ЛИ на фоне браузера ИЕ7 как раз показывает, какие последствия уже преподнес такой подход, а ведь вероятно еще и не это.

Редакторы, более чем 1 разработчик на проект, усложнение парсера... Грустно и не понятно ради чего.

[SelenIT]

Я воспринимаю опциональные закр. теги всего лишь как частный случай принципа TIMTOWDI. Структура как раз четкая донельзя (главный контейнер > блоки с блоками > блоки с текстом > текст > фрагменты текста, TABLE > TBODY > TR > TD), просто есть несколько вариантов ее правильного описания. Алгоритм парсинга, да, чуть сложнее (хотя нынешние мобилки поголовно справляются), но это плата за надежность и предсказуемость результата. В том же XHTML, на мой взгляд, четкости структуры и то меньше (tbody в table может быть, а может и не быть — наперед никак не угадаешь).

Симбиоз "семантика" + "отстутствие структуры" мне кажется в изначалии учербным и просто миной замедленного действия

Имхо, это если рассуждать в плоскости "тегов, слешей и кавычек". Если изначально оперировать понятиями DOM, то и структура сразу проясняется, и семантика становится нагляднее. Кстати, семантическая разница между div и span состоит как раз в их структурной роли: первый — абстрактный контейнер блоков, второй — абстрактный текстовый фрагмент.

А поведение IE7- (игнорирующего закрывающие теги там, где они по факту бесполезны), хотя и идет вразрез со стандартом, но по-своему логично, имхо. Тем самым как раз страхуется целостность и предсказуемость структуры, исключается даже случайное появление DOM-мутантов типа

UL
 ? LI
 ? LI
 ? LI
 ? ВНЕЗАПНО H2
 ? LI

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

[Justnewone]

Я сейчас не говорю про ДОМ, которым оперирует робот, парсер, компьютер, неодушевленное существо.

Я говорю о людях, которые вынуждены тратить тратить больше времени. И непонятно ради чего.

Примеры приводились. еще раз скученно представлю.

2 разных, по сути, метод разработки = отсутствие общей системы, в команде работать крайне проблематично.

Сложности с рефакторигнгом в тот же XML (да да, такое тоже не исключено).

Проблемы с семантикой, точнее, с ее структурированным логичным изложением (спан и див в Р).

Естественно, как только появляется взаимодействие двух различных систем, то сразу же появляется механизм, который приводит системы к третьей, но все равно общей системе. Но я понимаю вынужденное портирование, например, серверно-клиентское, но для чего было надо заставлять писать парсер под 2 клиентских системы разработки - у меня не укладывается.

Но это уже ооочень дремучийф холивар, наверно я успокоюсь. Постарался помочь и ответить на вопрос, как вышло так вышло

[SelenIT]

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

Идея рефакторинга разметки в абсолютно др. язык прямо в текста исходника, минуя логичную фазу десериализации в DOM/сериализации в нужное представление (тривиальными штатными средствами), по-прежнему кажется мне, гм... странноватой... ну да ладно.

для чего было надо заставлять писать парсер под 2 клиентских системы разработки

Для чего было - это уже история. А реальность в том, что этот парсер просто есть, именно такой (а в новых браузерах — еще и стандартизованный). И заставить его работать по другому алгоритму, увы, нельзя...

Я сейчас не говорю про ДОМ, которым оперирует робот, парсер, компьютер, неодушевленное существо.

Я говорю о людях...

Вот я и утверждаю, что людям тоже полезно оперировать ДОМом. Это сразу решит массу надуманных проблем и холиворов

[Justnewone]

Вот я и утверждаю, что людям тоже полезно оперировать ДОМом. Это сразу решит массу надуманных проблем и холиворов

Вот тут немного не соглашусь. Девочке-секретарю совсем не обязательно знать что такое дом, чтобы добавить на сайт пару новостей или статей. Ей вообще не надо знать что такое html, ей достаточно будет знать несколько тегов и условие, что некоторые из них могут не закрываться будет иметь катастрофические последствия. Это конечно утрированно, но надеюсь, мысль передал.

[SelenIT]

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

Edited November 10, 2011 by SelenIT

[Justnewone]

Но если человек всё-таки хочет продвинуться из секретарей в контент-менеджеры

Да Вы идеалист!

[s0rr0w]

что разметка является лишь инструкцией для браузера по построению DOM

Не являются теги инструкциями. Это именованные хранилища структур данных.

[SelenIT]

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

[Int]

.in {color:red;}
.p .in {color:blue;}

<p class="p">Этот текст чёрный
<span class="in">А этот текст у нас красный, потому что тэг p можно и не закрывать, он же сам закроется когда браузеру это взбредёт в голову.</span>

[sigma77]

Int,

Синий

http://jsfiddle.net/pcHwa/

[ceil100]

зеленый

http://jsfiddle.net/...

[SelenIT]

Последний пример не в кассу, у последнего правила тупо специфичность выше . А первый, имхо, как раз иллюстрирует мой главный тезис — лень заглянуть в спеку (посмотреть, при каких, очень четко обозначенных, условиях закрывается P) и оправдание этой лени "вредностью" и "плохим настроением" браузера ведут к проблемам и непоняткам независимо от того, закрыты теги явно или нет . Такова жизнь. А кто говорил, что будет легко? Каким бы низким порог ни был, без чтения спеки его не преодолеть, сколько слешей в <br> ни пихай...

[ceil100]

ааа, значит я не понял правил игры

вот что значит читать только конец

[Int]

Int,

Синий

http://jsfiddle.net/pcHwa/

Кэп

Чтобы прочитать что-то на w3.org, нужно чтобы они сперва сделали меню не для марсиан, а для логически мыслящих людей.

[SelenIT]

Итак,

миф о "якобы неприлично низком пороге вхождения в HTML" опровергнут

Правда, я не знаю, что архисложного, например, в этой таблице... и что мешает логически мыслящему человеку, увидев в ней пометку "End tag: Optional", элементарно полюбопытствовать "раз элемент закрывается не только закр. тегом, то чем еще он может закрываться?" и кликнуть по ссылке, чтобы найти ответ. Но это тема для отдельного холиво исследования...

[sigma77]

Чтобы прочитать что-то на w3.org, нужно чтобы они сперва сделали меню не для марсиан, а для логически мыслящих людей.

Да ладно, через Site map вполне вменяемо

п.с. Хотя к чему тогда был тот пост, я не поняла..

[SelenIT]

В общем, попробую подвести промежуточные итоги беседы. Риски от опускания закрывающих тегов сводятся к следующим:

для верстальщика:

• Трудность определения границ блока в редакторе с подсветкой;
  
• Возможные трудности при ручном преобразовании кода в XML-формат (без автоматизации);
  

для программиста:

• Необходимость использовать более сложные/медленные инструменты для автоматического разбора.
  

Вторая проблема кажется мне малоактуальной при серьезном подходе к разработке, с учетом падения популярности XHTML на фоне роста HTML5. Учитывая, что при парсинге чужих страниц этого всё равно трудно избежать, а собственные нечасто приходится парсить после вывода, последняя проблема тоже кажется мне чуть преувеличенной. Но надо смотреть по ситуации.

А проблем с отображением ("верстка разлезется") от осознанного использования неявного закрытия тегов нет. Если проблемы возникают, то не из-за тегов, а из-за "человеческого фактора" (некомпететность др. разработчиков и т.п.), и точно так же возможны и при явном, но бездумном закрытии.

Мораль же в этой басне такова: (не)обязательность закрытия тегов не избавляет от обязанности читать спецификации!

[Int]

Правда, я не знаю, что архисложного, например, в этой таблице...

А слабо дойти до неё с главной страницы?