Корректно ли в <p> вкладывать <div>, а в <td> вкладывать <p>?

Пример кода:

открываем стандарт, смотрим для div: (%flow;)*, т.е. ноль или больше %flow;. Ходим по ссылкам и смотрим, что может быть в div. Аналогично с td

честно говоря, даже мне не понятно куда там ходим и чего ищем

попутно ещё придётся выяснить, чего в их случае обозначают всякие значки

Нет


Да

Только начинать нужно с того, какой DOCTYPE? И если смотреть в сторону валидности, тогда нужно вспомнить что к depricated относятся <font>, и атрибут align у <p>, и атрибут bgcolor у <table>, а тега <noindex> в спецификации вообще не существует (поэтому придётся забивать или на SEO или на валидность).

ИМХО, div внутри p вообще не нужен. Последовательность <p><div></div></p> можно без проблем заменить на 
<p><span style="display: block;"><span>Some text goes here</span></span></p>

пошагово:
1) увидели, что в div может быть какой-то %flow;
2) смотрим, что такое %flow; (на ссылку щелкаем)
3) %flow - это %block; или %inline;
4) щелкаем на %block;
5) %block - это P | %heading; | %list; | %preformatted; | DL | DIV | NOSCRIPT |
      BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS
...
изначальная ссылка на HTML 4.01 Strict DTD, если нужен другой - ищем на том же сайте

Это сообщение отредактировал(а) youri - 9.10.2009, 16:16

знаешь, даже из этой пошаговой инструкции не ясно:

Симантически это не правильно   

да, я перепутал, что во что нужно вкладывать. Надо начинать с p и следуя аналогичным инструкциям видно, что в p не может быть div'а

 
теоретически не может, но практически всегда найдется   

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

делай ajax-запрос на валидатор   


это dtd ;) а откуда такая задача?

Надо написать небольшой парсер HTML. Собственно проблема в следующем:
При построении дерева нужно точно знать где какой элемент заканчивается. В случае с необязательными закрывающими тэгами (на сколько я понимаю) имеются следующие признаки закрытия элемента:

• Закрывающий тэг таки присутствует(здесь всё просто).
• Закрывается родительский элемент, стало быть открытых вложенных элементов быть не может и они тоже должны закрыться(тут тоже существенных проблем нет)
• Если в документе после открытого элемента с необязательным закрывающим тэгом встречается элемент, который не может быть его непосредственным потомком, то элемент надо закрыть, а следующий за ним интерпретировать как nextSibling

Вот для реализации последнего пункта мне это и понадобилось.

а кто его знает? а если так

что имел в виду автор? Боюсь что проблемы с закрытием тэгов решаются разными браузерами по-разному и вряд ли они спецификацией руководствовались. Например, ie 6 (а может и не только), если не закрыть p, засовывает в него следующую таблицу

p.s. чем существующие парсеры не устраивают?



Это сообщение отредактировал(а) youri - 17.10.2009, 08:36

Это вполне можно подвести под второй пункт, сопсно так и планирую сделать.

Поверхностное изучение вопроса привело меня к тому, что вовсе даже не руководствовались. Для некоторых элементов в спецификации указано, что закрывающий тэг необязателен, а в мсдн - наоборот. И тут опять-таки возникает вопрос "как быть?".Да сопсно разные причины. Скажем для  Web Data Extractor'а нужно иметь возможность разбора отдельных фрагментов документа. То есть для программной работы с документами сети такая штучка не повредит. А существующие работают по правилам, определённым не мной, да и...иногда не справляются даже с поисковой страницей гугла.

корректно в теме не писать p и div и, тем более, td - в виде тегов, чтобы почтовая рассылка не корежилась нах...



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

В остальном код будет отображаться как есть. В принципе, и див можно воткнуть в параграф. Только неправильно это. Учитесь верстать в соответствии со стандартами. Через годик-другой все как перейдут на новую версию HTML или XHTML - и все дизайны "поплывууут". Вот тогда вспомните...

ИМХО, ненавижу обрабатывать таблицы с сайтов, верстальщики которых вставляют в td всякие div, p и остальные левые теги без необходимости, вместо того, чтобы один раз прописать стили CSS. И когда не используют th.

Это сообщение отредактировал(а) HARDMID - 21.10.2009, 14:56

а не слишком ли вы раскатали губу, сэр? воруете, так ещё и качеством недовольны?

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


Только в XML-режиме (как application/xhtml+xml etc.). А вот таблицу в абзац — да, в некоторых случаях можно и в text/html (в IE7 и ниже — всегда, в IE8 и FF — только в Quirks mode).

SelenIT, за ссылку спасибо,  порылся в спеке вроде есть то, что надо. 
Валидатор не понадобится, мне не для того, чтобы корректные документы составлять, а для того, чтобы извлекать информацию с вебстраниц, при этом игнорируя максимум ошибок и чтобы всё работало под .Net Framework да ещё и по моим правилам  
А на счёт гуголя я написал потому, что как-то разбирал его поисковую страницу припомощи sgmlreader'а, он всё парсит в XML, а раньше в этой странице отсутствовал корневой элемент(HTML) а в XML это низзя и он разбирал элемент head, а всё остальное игнорировал. Из-за этого я и упомянул про гуголь. Сейчас у них там корневой элемент присутствует.

Там парсер вроде можно и отдельно от валидатора использовать, сам по себе он к ошибкам лоялен, просто валидатор эти ошибки еще и логирует. Плюс есть демо-реализация парсера на JS (вроде даже довольно шустрая;).

Еще нередко для таких задач юзают Tidy, но там, имхо, результат может сильнее отличаться от браузерного (сужу по поведению FF-овского HTML Validator-а, который в режиме Tidy тупо выбрасывает, например, пустые span-ы, часто важные для оформления).

Мне нужен инструмент написаный и работающий под .Net Framework. Если бы речь шла о каком угодно парсере, то думаю, что проблемы не было бы.

Понятно. Вот нагуглилась попытка реализации той спеки на .NET (правда, пока с припиской "код нерабочий", но, может, хотя бы Constants.cs пригодятся;)...

Да вроде в спеке описано то, что надо. А из этого модуля ограничений можно только список элементов получить, но не описание признаков закрытия.
Вот сопсно, то что надо
http://dev.w3.org/html5/spec/Overview.html#optional-tags

bars80080, 



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

есть готовое решение. находится по сочетанию xml+rss
договариваетесь с редакцией, они выделяют вам канал новостей, вы пишете парсящий скрипт за полчаса и не испытываете абсолютно никаких проблем с чуждой вёрсткой, ибо она отсутствует как таковая