Обработчики в js

Destrifer · January 13, 2009

Как я понял:

1.Если просто переназначить обработчики через JS, то они не срабатывают, если-же поместить их в функцию, срабатывающую, скажем, по onload, объявленный через атрибут, то мы возвращаемся к тому, с чего начали.

2.Если на таком обработчике висит функция, то передать значение в неё не предсталяется возможным, кроме как, повесив отдельную функцию, через которую вызывается искомая. И так для каждой функции в которую мы передаем значения?

Что-то не совсем понятны плюсы такого подхода.

Destrifer · January 16, 2009

function My (inp) {
	this.value = inp; // уникальное свойство для нового сконструированного объекта
}
My.prototype = {
	someAction: function () {},
	defaultValues: [1,2] // свойства общие для всех объектов сконструированных My 
}
примерно также можно представить объект html как объект JS, но это грозит серьезными проблемами в IE (более подробно смотрите "утечки памяти IE", "замыкания"). Вот один из вариантов:
var el = document.getElementById('myElement');
el.myaction = function (val) {alert(val)};
el.myvalue = true;
el.myaction  (el.myvalue);
так же смотрите метод [Element].getAttribute("[attributeName]"); Если надо непосредственно через html-код задать какой-либо параметр, а потом его получить в JS. Но. В таком случае html-код уже не будет валидным, если использованы имена атрибутов отличных от указанных в спецификации.
но, имхо, удобнее представлять объекты html, как значение свойств (параметров) объектов JS

Спасибо, буду переваривать

Yarik Voronov · January 16, 2009

s0rr0w, видимо надо начать с основ

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

XHTML по сути своей не является XML приложением, он является xml расширением HTML W3C FAQ

А я и не говорил что нельзя создавать свои теги и атрибуты. "Если нельзя, но очень хочется, то - можно". Только такой документ уже не будет XHTML или HTML. И мы не имеем права написать в заголовке <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">, например. это уже будет документ XML по своей сути (если мы выполнили все предписания для xml-документа), а не XHTML 1.0 Transitional. Естественно при таком раскладе как написано в том же FAQ: "HTML browsers accept any input, correct or incorrect, and try to make something sensible of it". Русскими словами, браузер в лучшем случае просто игнорирует теги и атрибуты не описанные в стандарте, ибо не понимает как их обрабатывать, в первую очередь - визуализировать.

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

Если рассматривать DOM, как еще один из стандартов, то он не запрещает создавать в дереве кастом атрибуты.

Давайте не мешать мух и котлеты. "The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents." (DOM) Ключевые слова здесь "платформо-языко-независимый", "интерфейс". Т.е. это набор методов посредством, которых можно получить доступ к програмно-визуальной модели документа сформированной браузером, на основе синтаксиса (кода) полученного документа html.

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

Обобщая, кодом:

var el = document.getElementById('myElement');
el.myaction = function (val) {alert(val)};

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

С другой стороны, вернемся к "своим" тегам и атрибутам. Если их синтаксис верен (как синтаксис html/xtml/xml) то они могут не присутствовать в том, что мы видим, но обязательно присутствуют в програмной модели. Тут "обязательно" следует понимать с поправкой на конкретных разработчиков браузера/программны

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Untitled Document</title>
</head>

<body onload="alert([document.getElementById('test'), document.getElementById('test').getAttribute('name')]);">
<test id="test"></test>
<script language="javascript" type="text/javascript">
	document.getElementById('test').setAttribute("name","z");
</script>
</body>
</html>

FF3 выдал "object HTMLUnknownElement". Следовательно мы можем применить к нему почти все методы (удалить из дерева, присвоить атрибут и т.д.), задекларированные разработчиками FF для HTML-элемента, кроме одного - не сможем отобразить элемент <test> как, например <div>. Потому мы не можем "повесить" обработчик событий на такой элемент. Вернее можем, но тогда мы должны сами программно вызывать такие события (initEvent())

Итак, XML/XHTML/HTML - это то что "понятно" любому поддерживающему стандарты програмному продукту (браузер, приложение). DOM - это набор методов доступа к программно - визуальной модели документа, сфомированной этим програмным продуктом. (ИМХО)

Еще один из приколов конфликта стандартов на примере CSS
  <style>
	  div { display: inline }
	  a { display: block }
  </style>
  <div><a>link</a></div>
  <div><a>link</a><span>span</span></div>
С точки зрения механической валидности код валиден на 100%.
С точки зрения рендеринга это невалидный код.

А при чем здесь CSS? Никакого "конфликта стандартов" я здесь не усматриваю. Выдержка из аннотации к спецификации CSS2: "CSS2 позволяет сделать стиль представления документов независимым от их содержания, что существенно упрощает разработку Web-страниц и поддержку сайтов." Вообще, я не нашел ни в одной из перечисленных спецификаций, что <div> обязан всегда быть блочным, а <а> - встроенным. Да в HTML < 4.0, если я не ошибаюсь, <div> должен быть блочным. Но тогда не было СSS. Теперь каскадные таблицы стилей существуют, что во многом упрощает жизнь разработчикам сайтов. Новые времена - новые технологии - новые стандарты.

Более того, в спецификации СSS четко написано как програмный продукт должен обрабатывать стили. Я соглашусь лишь с тем, что с точки зрения синтаксиса (CSS, HTML) приведенный код написан правильно (кавычки, скобочки, точки, имена свойств). И с точки зрения рендеринга все в этом коде верно: в пределах встроенного элемента <div>, элемент <a> отображается блочным (как того и хотел программист/верстальщик). Ну а если он хотел не того, чтож - ему надо "рендерить спецификацию"

s0rr0w · January 17, 2009

s0rr0w, видимо надо начать с основ
XHTML по сути своей не является XML приложением, он является xml расширением HTML W3C FAQ

http://www.w3.org/TR/xhtml1/#diffs

Due to the fact that XHTML is an XML application, certain practices that were perfectly legal in SGML-based HTML 4 [html4] must be changed.

Только такой документ уже не будет XHTML или HTML.

Понимаете какая штука интересная, HTML является подмножество SGML, и поэтому, если расширить DTD, то можно создавать любые теги и атрибуты. Это не запрещается спецификацией.

Другое дело, что браузеры игнорируют DTD как класс. А не должны.

И советую почитать

http://www.w3.org/TR/xhtml1/#well-formed

Давайте не мешать мух и котлеты. "The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents." (DOM) Ключевые слова здесь "платформо-языко-независимый", "интерфейс". Т.е. это набор методов посредством, которых можно получить доступ к програмно-визуальной модели документа сформированной браузером, на основе синтаксиса (кода) полученного документа html.

Однако он НЕ ЗАПРЕЩАЕТ модификацию DOM-дерева как угодно разработчику, хоть это может идти вразрез со спецификацией языка.

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

А что есть код HTML как таковой с точки зрения браузера? Текстовый файл на входе в парсер. Но для того, чтобы он обрел визуальный рахактер, нужно обязательно превратить его в DOM-структуру.

FF3 выдал "object HTMLUnknownElement".

Правильно. Это неизвестный HTML элемент. Но выводы ниже - ошибочны.

Следовательно мы можем применить к нему почти все методы (удалить из дерева, присвоить атрибут и т.д.), задекларированные разработчиками FF для HTML-элемента, кроме одного - не сможем отобразить элемент <test> как, например <div>. Потому мы не можем "повесить" обработчик событий на такой элемент. Вернее можем, но тогда мы должны сами программно вызывать такие события (initEvent())

Вообще, я не нашел ни в одной из перечисленных спецификаций, что <div> обязан всегда быть блочным, а <а> - встроенным. Да в HTML < 4.0, если я не ошибаюсь, <div> должен быть блочным.

Такого нигде и не прочитаете, потому что действуют множество стандартов одновременно. В базовом DTD написано, что <div> - блочный, <a> - строчный. CSS может это изменить.

Но тогда не было СSS. Теперь каскадные таблицы стилей существуют, что во многом упрощает жизнь разработчикам сайтов. Новые времена - новые технологии - новые стандарты.
Более того, в спецификации СSS четко написано как програмный продукт должен обрабатывать стили. Я соглашусь лишь с тем, что с точки зрения синтаксиса (CSS, HTML) приведенный код написан правильно (кавычки, скобочки, точки, имена свойств). И с точки зрения рендеринга все в этом коде верно: в пределах встроенного элемента <div>, элемент <a> отображается блочным (как того и хотел программист/верстальщик). Ну а если он хотел не того, чтож - ему надо "рендерить спецификацию"

Но с точки зрения той же HTML спецификации блочные элементы не могут находиться внутри строчных. Кто главнее? По идее браузер должнен изменить DOM-структуру документа, вытащив A за пределы DIV.

Yarik Voronov · January 17, 2009

http://www.w3.org/TR/xhtml1/#diffs
Due to the fact that XHTML is an XML application, certain practices that were perfectly legal in SGML-based HTML 4 [html4] must be changed.

Offtopic

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

(О! великий и богатый русский язык!). так как общаемся на русском, - давайте использовать семантику русских слов.

/Offtopic

Понимаете какая штука интересная, HTML является подмножество SGML, и поэтому, если расширить DTD, то можно создавать любые теги и атрибуты. Это не запрещается спецификацией.
Другое дело, что браузеры игнорируют DTD как класс. А не должны.

Правильно - "если расширить". Но это уже будет НЕ "DTD XHTML 1.0 Transitional" от W3C. Это будет DTD от s0rr0w.

Потому, валидатор от W3C выдаст ошибку.

Теперь задумаемся: "По умолчания, каким стандартам так или иначе следуют (пытаются следовать/игнорировать) разработчики ПО?"

И советую почитать
http://www.w3.org/TR/xhtml1/#well-formed

s0rr0w, пардон, Вы о чем? Это синтаксис языка, а я Вам втолковываю о семантике (понимание, интерпретация)

Однако он НЕ ЗАПРЕЩАЕТ модификацию DOM-дерева как угодно разработчику, хоть это может идти вразрез со спецификацией языка.

Еще раз повторяюсь XHTML - это одно. DOM - это другое. У FF - своя объектная модель и IE - своя, у Opera - третья. Тривиально, выражаясь - объектная модель документа это порядок следования ноликов и единичек в оперативной памяти компьютера. Одна объектная модель позволяет делать к-л операцию, а другая нет. Одна позволяет себя расширятьновыми свойствами объектов, другая "машет лапкой и нервно курит". В одной модели существует 3 свойства объекта, в другой - 100 того же объекта (сильно упрощая).

DOM от W3C - это набор рекомендаций по организации интерфейса доступа к объектам и их свойствам из программы и(или) скрипта. Теперь попробуйте выполнить вышеприведенный код с новым элементом <test> в IE6 - получите совершенно другой результат.

А что есть код HTML как таковой с точки зрения браузера? Текстовый файл на входе в парсер. Но для того, чтобы он обрел визуальный характер, нужно обязательно превратить его в DOM-структуру.

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

Правильно. Это неизвестный HTML элемент. Но выводы ниже - ошибочны.
>>Следовательно мы можем применить к нему почти все методы (удалить из дерева, присвоить атрибут и т.д.), задекларированные разработчиками FF для HTML-элемента, кроме одного - не сможем отобразить элемент <test> как, например <div>. Потому мы не можем "повесить" обработчик событий на такой элемент. Вернее можем, но тогда мы должны сами программно вызывать такие события (initEvent())

Да? Серьезно? s0rr0w, назначьте onclick элементу <test>. Кроме того, FF написал "неизвестный HTML элемент" потому что я сам задекларировал стиль и набор команд как XHTML в DOCTYPE, если бы я написал что тип документа SVG - FF выдал бы что это неизвестный элемент SVG

Такого нигде и не прочитаете, потому что действуют множество стандартов одновременно. В базовом DTD написано, что <div> - блочный, <a> - строчный. CSS может это изменить.

"В базовом DTD написано" - конечно, там еще много написано. Но суть в том, что DTD (Document Type Definition определение типа документа) - это "значение свойств по умолчанию", то есть как браузер должен понимать элемент, если ничего другого нет. Но CSS и предназначен для того, чтобы менять эти "умолчательные" значения.

Но с точки зрения той же HTML спецификации блочные элементы не могут находиться внутри строчных. Кто главнее? По идее браузер должнен изменить DOM-структуру документа, вытащив A за пределы DIV.

HTML какой версии? 1, 3 или 4? Что касается версий 1-3 то точно не может. Потому что в них CSS не определен как расширение HTML. Когда декларировались эти версии, CSS вообще не существовало как такового. Потому в этих стандартах нет даже тега <style>. C точки зрения более поздних стандартов, блочный элемент позиционируется относительно того места и условый где он находиться и приобретает наследуемые свойства своего родителя. С другой стороны, загоните свой код в валидатор W3C и все увидите сами.

Браузер не должен менять структуру DOM и не будет в таком случае. Потому что отрисовкой занимается другая часть кода-браузера. С точки зрения DOM, "ему" абсолютно начхать как должен (или может) отображаться тот или иной элемент. DOM - это объекты и их свойства, методы, т.е. структурированный набор ноликов и единичек в оперативной памяти, а не игра света и тени на дисплее.

Дополнительно

Понимаете какая штука интересная, HTML является подмножество SGML, и поэтому, если расширить DTD, то можно создавать любые теги и атрибуты. Это не запрещается спецификацией.
Другое дело, что браузеры игнорируют DTD как класс. А не должны.

Правильно - "если расширить". Но это уже будет НЕ "DTD XHTML 1.0 Transitional" от W3C. Это будет DTD от s0rr0w.

Потому, валидатор от W3C выдаст ошибку. И все будет верно, потому что код не соотвествует задекларированному типу в первой строчке документа. Следовательно код не верен - не валидный

s0rr0w · January 17, 2009

Offtopic
s0rr0w, загляните пож-та в перевод слова
(О! великий и богатый русский язык!). так как общаемся на русском, - давайте использовать семантику русских слов.
/Offtopic

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

> Правильно - "если расширить". Но это уже будет НЕ "DTD XHTML 1.0 Transitional" от W3C. Это будет DTD от s0rr0w.

Будет мой собственный клон XHTML, и что? Это не запрещено. Причем не запрещено совершенно другими стандартами, частным случаем которого является XHTML.

> Потому, валидатор от W3C выдаст ошибку.

Какой именно валидатор? На строгое соответствие XHTML 1.0 Transitional или на строгое соответствие моему DTD? XML валидатор не выдаст ошибку.

> Теперь задумаемся: "По умолчания, каким стандартам так или иначе следуют (пытаются следовать/игнорировать) разработчики ПО?"

Документы на w3c по большей части носят рекомендательный характер.

> s0rr0w, пардон, Вы о чем? Это синтаксис языка, а я Вам втолковываю о семантике (понимание, интерпретация)

Понимание и интерпретация - это вторично. Кто как хочет, так и понимает, а вот правильность понимания - это второй вопрос.

> Еще раз повторяюсь XHTML - это одно. DOM - это другое. У FF - своя объектная модель и IE - своя, у Opera - третья. Тривиально, выражаясь - объектная модель документа это порядок следования ноликов и единичек в оперативной памяти компьютера. Одна объектная модель позволяет делать к-л операцию, а другая нет. Одна позволяет себя расширятьновыми свойствами объектов, другая "машет лапкой и нервно курит". В одной модели существует 3 свойства объекта, в другой - 100 того же объекта (сильно упрощая).

Вы мне Америку тут решили открыть?

Что есть DOM? Это объектная модель документа подмножества SGML. Что есть тег для браузера? Текстовая строка? Нет, это DOM-объект со строго заданными свойствами, которые как раз и описывает спецификация DOM. Спецификация DOM не запрещает создание custom-атрибутов, и не может. Спецификация SGML не запрещает создавать собственные DTD, поэтому можно спокойно создавать свои версии HTML, и браузер обязан их воспринимать как должное. Другой вопрос, что сейчас все разработчики идут по самому простому пути, т.е. стараются реализовать фиксированную структуру документа по спецификации w3c, хотя по-хорошему, это нарушает ряд других спецификаций.

> DOM от W3C - это набор рекомендаций по организации интерфейса доступа к объектам и их свойствам из программы и(или) скрипта. Теперь попробуйте выполнить вышеприведенный код с новым элементом <test> в IE6 - получите совершенно другой результат.

Это проблемы реализации данным браузером данного кода.

> Да? Серьезно? s0rr0w, назначьте onclick элементу <test>. Кроме того, FF написал "неизвестный HTML элемент" потому что я сам задекларировал стиль и набор команд как XHTML в DOCTYPE, если бы я написал что тип документа SVG - FF выдал бы что это неизвестный элемент SVG


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:mynamespace="http://www.htmlbook.ru">
	<head>
		<title>XML Namespace Test</title>
		<style type="text/css">
			#myTag { display: block; background: #ccc; }
		</style>

	</head>
	<body>
		<h1>XML Namespace Test</h1>
		<mynamespace:my_tag id="myTag" onclick="alert('b')">
			Contents of myTag
		</mynamespace:my_tag>
		<script type="text/javascript">
				var x = document.getElementById("myTag");
				x.addEventListener( "click", function(){ alert('a') }, false );
		</script>

	</body>
</html>

> "В базовом DTD написано" - конечно, там еще много написано. Но суть в том, что DTD (Document Type Definition определение типа документа) - это "значение свойств по умолчанию", то есть как браузер должен понимать элемент, если ничего другого нет. Но CSS и предназначен для того, чтобы менять эти "умолчательные" значения.

DTD описывает структуру документа, какие теги можно использовать, допустимые вложения, сущности и т.д. Понимание как отображать возложено на CSS, за исключением форм, но это скоро тоже переложат на CSS.

> HTML какой версии? 1, 3 или 4? Что касается версий 1-3 то точно не может. Потому что в них CSS не определен как расширение HTML. Когда декларировались эти версии, CSS вообще не существовало как такового. Потому в этих стандартах нет даже тега <style>. C точки зрения более поздних стандартов, блочный элемент позиционируется относительно того места и условый где он находиться и приобретает наследуемые свойства своего родителя. С другой стороны, загоните свой код в валидатор W3C и все увидите сами.

http://www.w3.org/TR/REC-html32

http://www.ietf.org/rfc/rfc1866.txt

И напоследок

http://www.w3.org/TR/CSS1/#appendix-a

Валидатор w3c валидирует БЕЗ учета содержимого DTD, выбирая только из готового набора. Поэтому он абсолютно валидный документ может спокойно назвать невалидным.

> Браузер не должен менять структуру DOM и не будет в таком случае. Потому что отрисовкой занимается другая часть кода-браузера. С точки зрения DOM, "ему" абсолютно начхать как должен (или может) отображаться тот или иной элемент. DOM - это объекты и их свойства, методы, т.е. структурированный набор ноликов и единичек в оперативной памяти, а не игра света и тени на дисплее.

Да что вы говорите! Правда? А засуньте-ка вы между <TR> <div> и посмотрите на получившуюся структуру в firebug-e. По всем правилам, данный кусок кода должен быть вообще удален из дерева нод.

> Правильно - "если расширить". Но это уже будет НЕ "DTD XHTML 1.0 Transitional" от W3C. Это будет DTD от s0rr0w.

Потому, валидатор от W3C выдаст ошибку. И все будет верно, потому что код не соотвествует задекларированному типу в первой строчке документа. Следовательно код не верен - не валидный

Валиден на все 100% будет. Если валидатор научится понимать содеожимое DTD. А он этого не умеет делать.

Edited January 17, 2009 by s0rr0w

Yarik Voronov · January 17, 2009

s0rr0w, если Вы расширяете первоначалбный DTD XHTML 1.0 Transitional от W3C, то это уже не первоначальный стандарт XHTML 1.0 Transitional, как выбранный для примера. В этом вроде бы мы сошлись во мнениях. Теперь покажите мне пожалуйста в XHTML 1.0-спецификации тот раздел, который позволяет Вам расширять исходную декларацию типа документа своими тегами и атрибутами, своим простанством имен. Потому что мои поиски в этом направлении не увенчались успехом. То что вы мне показывали ранее есть не что иное как использование простанства имен XHTML как расширение XML-документа, но не наоборот.

> Потому, валидатор от W3C выдаст ошибку
>> Какой именно валидатор? На строгое соответствие XHTML 1.0 Transitional или на строгое соответствие моему DTD? XML валидатор не выдаст ошибку.

На строгое соответствие XHTML 1.0 Transitional. Только про это я и говорил, когда выражался "код ошибочен", "невалидный код". И по-моему, достаточно четко на то указал. Если сразу было непонятно,- пардон, что не писал крупными буквами.

Вы мне Америку тут решили открыть?

Зачем ее открывать? Её пора закрывать....

Что есть DOM? Это объектная модель документа подмножества SGML.

Согласен. Но DOM - это не есть документ SGML. И потому не надо пытаться смешивать две различные вещи, два разных стандарта, две различные области: модели переноса информации (SGML) и модели ее програмного представления в конкретном продукте (DOM).

http://ru.wikipedia.org/wiki/DOM
DOM (от англ. Document Object Model — «объектная модель документа») — это не зависящий от платформы и языка программный интерфейс, позволяющий программам и скриптам получить доступ к содержимому документов, а также изменять содержимое, структуру и оформление документов.
...
Изначально различные браузеры имели собственные модели документов (DOM), не совместимые с остальными. Для того, чтобы обеспечить взаимную и обратную совместимость, специалисты международного консорциума W3C классифицировали эту модель по уровням, для каждого из которых была создана своя спецификация. Все эти спецификации объединены в общую группу, носящую название W3C DOM.

Что есть тег для браузера? Текстовая строка? Нет, это DOM-объект со строго заданными свойствами, которые как раз и описывает спецификация DOM.

"Неверю и еще раз неверю" (с). Тег - это есть команда в тестовом виде программе-браузеру в некоторой области машинной памяти организовать DOM-объект. Назначить этому объекту своиства и стандартные методы и "дополнительные" свойства и методы, которые определили разработчики браузера. (Хотя это очень упрощенно, потому что сам документ SGML преобразуется в объекты языка программирования браузера (например С++) или становиться свойством к-л объекта). Поэтому пользовательские объекты (теги, созданные программно; скрипты), атрибуты и методы - это имена свойств объектов того языка программирования на котором написан браузер. А не расширение как таковой спецификации HTML/XHTML.

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

Не расстраивайтесь, s0rr0w, к разрешению этого браузерно-стандартного конфликта и направлена работа W3C. Всегда есть момент инерции при принятии нового.

DTD описывает структуру документа, какие теги можно использовать, допустимые вложения, сущности и т.д. Понимание как отображать возложено на CSS, за исключением форм, но это скоро тоже переложат на CSS.

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

Валидатор w3c валидирует БЕЗ учета содержимого DTD, выбирая только из готового набора. Поэтому он абсолютно валидный документ может спокойно назвать невалидным.

Валидатор валидирует :rolleyes: с учетом содержания того DTD, который Вы объявили в заголовке типа документа. А если Вы используете валидатор W3C то ессно дело, что хотите проверить на соответсвие W3C-стандартам и типу документа, а не своим. И тут не надо говорить что валидатор, с..., глупый :unsure: и не понимает что мой клон HTML самый правильный

Да что вы говорите! Правда? А засуньте-ка вы между <TR> <div> и посмотрите на получившуюся структуру в firebug-e. По всем правилам, данный кусок кода должен быть вообще удален из дерева нод.

Мы с Вами рассуждали о валидном с точки зрения HTML/XTML коде, и якобы не валидном действии СSS по отношению к отображению этого кода в браузере. То что Вы предлагаете сделать сейчас это из раздела того как "браузеры пытаются переварить во что-то удобо варимое ошибочный код HTML/XHTML". Потому не вижу смысла как-либо иначе Ваш тезис коментировать.

s0rr0w · January 18, 2009

s0rr0w, если Вы расширяете первоначалбный DTD XHTML 1.0 Transitional от W3C, то это уже не первоначальный стандарт XHTML 1.0 Transitional, как выбранный для примера. В этом вроде бы мы сошлись во мнениях. Теперь покажите мне пожалуйста в XHTML 1.0-спецификации тот раздел, который позволяет Вам расширять исходную декларацию типа документа своими тегами и атрибутами, своим простанством имен. Потому что мои поиски в этом направлении не увенчались успехом. То что вы мне показывали ранее есть не что иное как использование простанства имен XHTML как расширение XML-документа, но не наоборот.

Охо-хо... Вы немного путаете теплое и мягкое. Стандарт XHTML описывает HTML-структуру, которую можно использовать в XML. Естественно, вы не найдете в спецификации XHTML упоминание о том, что можно создавать custom-теги, потому что это описано в XML-спецификации.

> Согласен. Но DOM - это не есть документ SGML. И потому не надо пытаться смешивать две различные вещи, два разных стандарта, две различные области: модели переноса информации (SGML) и модели ее програмного представления в конкретном продукте (DOM).

Почему смешивать? Они неразрывны. И SGML - это не модель переноса информации. Это модель структурирования данных.

"Неверю и еще раз неверю" (с). Тег - это есть команда в тестовом виде программе-браузеру в некоторой области машинной памяти организовать DOM-объект.

Какая-такая команда? :rolleyes:

Программа-браузер может вообще ничего не делать, если она не в курсе, что с этим делать. Попробуйте загрузить XML документ, у которого будут знакомые теги DIV, B, и посмотрите, что получится. Тег - это контейнер.

> Назначить этому объекту своиства и стандартные методы и "дополнительные" свойства и методы, которые определили разработчики браузера. (Хотя это очень упрощенно, потому что сам документ SGML преобразуется в объекты языка программирования браузера (например С++) или становиться свойством к-л объекта). Поэтому пользовательские объекты (теги, созданные программно; скрипты), атрибуты и методы - это имена свойств объектов того языка программирования на котором написан браузер. А не расширение как таковой спецификации HTML/XHTML.

:unsure: И нафиг тогда был создан DOM? От нефиг делать?

>Не расстраивайтесь, s0rr0w, к разрешению этого браузерно-стандартного конфликта и направлена работа W3C. Всегда есть момент инерции при принятии нового.

А я то думал, что они просто создают спецификации. А производители браузеров могут или поддержать его, или проигнорировать.

Посмотрите список технологий, которые описаны на w3c, половина из них имеет к браузерам весьма посредственное отношение.

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

Внимательно читайте. Я не говорил, что CSS противоречит стандартам. Я показал пример, когда два стандарта могут создавать ситуации, когда они начинают противоречить друг другу. На момент обработки их браузером или любой другой программой.

> Валидатор валидирует с учетом содержания того DTD, который Вы объявили в заголовке типа документа. А если Вы используете валидатор W3C то ессно дело, что хотите проверить на соответсвие W3C-стандартам и типу документа, а не своим. И тут не надо говорить что валидатор, с..., глупый и не понимает что мой клон HTML самый правильный

Вы специально проигнорировали что я написал три раза? Валидатор валидирует БЕЗ учета DTD, выбирая модель поведения из заголовка. Валидатор не глупый, он ограниченный. Создайте DTD к XML документу и создайте невалидный XML с точки зрения DTD. Валидатор покажет, что ваш документ валидный.

Мы с Вами рассуждали о валидном с точки зрения HTML/XTML коде, и якобы не валидном действии СSS по отношению к отображению этого кода в браузере. То что Вы предлагаете сделать сейчас это из раздела того как "браузеры пытаются переварить во что-то удобо варимое ошибочный код HTML/XHTML". Потому не вижу смысла как-либо иначе Ваш тезис коментировать.

Что мы только с вами не обсуждали. Но вы так и не поняли, про что речь, зациклившись на одном стандарте (рекомендации).

Yarik Voronov · January 18, 2009

s0rr0w, извините, но я не зациклен на одном стандарте-рекомендации. Я просто пытаюсь объяснить некоторую тонкость вопроса. Все что вы пишете справедливо, если вы используете XML в широком смысле, а не узкую его подмодель HTML/XHTML от W3C. Но как разработчик Вы должны корректно по меньшей мере указывать тип документа.

Если вы используете в коде XML/XHTML собственные теги и атрибуты Вы не можете указывать тип документа как, например

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Вы должны написать что-то такое:

<!DOCTYPE html PUBLIC "-//S0rr0w//DTD XHTML 1.0 Transitional//EN" "http://s0rr0w.org/xhtml1/DTD/sorrow-xhtml1-transitional.dtd">

И в этом доктайпе все описать. И согласно Вашему типу все на 100% будет валидно. А потом проверить на соответствие XML и тоже все будет валидно. Но никак не может быть валидно отностительно XHTML 1.0 Transitional от W3C. И Вы сами об этом говорите:

Стандарт XHTML описывает HTML-структуру, которую можно использовать в XML. Естественно, вы не найдете в спецификации XHTML упоминание о том, что можно создавать custom-теги, потому что это описано в XML-спецификации.

И спарведливо для XML-документа, но не для закрытой подмодели XHTML от W3C.

То что браузеры не понимают типы документов XML/SGML других разработчиков вопрос времени. Вообще сейчас идет тенденция отказаться от DTD в пользу более гибкого инструмента W3C XML Schema (DTD)

>>Тег - это есть команда в тестовом виде программе-браузеру в некоторой области машинной памяти организовать DOM-объект.

>Какая-такая команда?

Текстовая, sorrow. Текстовая. кнопочка западает :rolleyes:

>>Тег - это есть команда в текстовом виде программе-браузеру в некоторой области машинной памяти организовать DOM-объект. Назначить этому объекту своиства и стандартные методы и "дополнительные" свойства и методы, которые определили разработчики браузера. (Хотя это очень упрощенно, потому что сам документ SGML преобразуется в объекты языка программирования браузера (например С++) или становиться свойством к-л объекта). Поэтому пользовательские объекты (теги, созданные программно; скрипты), атрибуты и методы - это имена свойств объектов того языка программирования на котором написан браузер. А не расширение как таковой спецификации HTML/XHTML.

>И нафиг тогда был создан DOM? От нефиг делать?

Что ж так грубо? Внимательнее прочтите определение DOM

DOM (от англ. Document Object Model — «объектная модель документа») — это не зависящий от платформы и языка программный интерфейс, позволяющий программам и скриптам получить доступ к содержимому документов, а также изменять содержимое, структуру и оформление документов.

Как следует, это тот программный интерфейс (например С++) который позволяет Вам на языке JS (тоже например) изменять

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

Другой не менее справедливый тезис: "DOM - это то что будет создано на основе файла-исходника XML. И как эта модель может быть организована рекомендовано в стандарте DOM. А рекомендовано с целью унификации и упрощения разработки веб-страниц, в частности" Надеюсь Вы еще помните: document.all для IE5, document.getElementById для Netscape.

>Внимательно читайте. Я не говорил, что CSS противоречит стандартам. Я показал пример, когда два стандарта могут создавать ситуации, когда они начинают противоречить друг другу. На момент обработки их браузером или любой другой программой.

А я Вам обосновал (надеюсь убедительно), что никакого противоречия нет, если вы используете технологию XML + CSS (HTML > 4.0 и XHTML в эту связку я тоже отнес как подмодель XML). Если Вы хотите показать такой пример противоречия стандартов, то Ваш изначальный пример был не удачен, приведите другой, если хотите.

>>Валидатор валидирует с учетом содержания того DTD, который Вы объявили в заголовке типа документа. А если Вы используете валидатор W3C то ессно дело, что хотите проверить на соответсвие W3C-стандартам и типу документа, а не своим. И тут не надо говорить что валидатор, с..., глупый и не понимает что мой клон HTML самый правильный

>Вы специально проигнорировали что я написал три раза? Валидатор валидирует БЕЗ учета DTD, выбирая модель поведения из заголовка. Валидатор не глупый, он ограниченный. Создайте DTD к XML документу и создайте невалидный XML с точки зрения DTD. Валидатор покажет, что ваш документ валидный.

Пример в студию. Но не надо говорить об XML в широком смысле, потому что наши разногласия относятся к узкой его подмодели XHTML. И то что я Вам говорил, это как раз тот момент ограниченности валидатора. И эта ограниченность на мой взгляд справедлива. Потому что Вы пытаетесь проверить свой документ на соответствие стандарту XHTML от W3C. А в XHTML от W3C четко сказано что есть, а чего быть не должно.

З.Ы.: по поводу событий и определения SGML отпишусь позже

SelenIT · January 18, 2009

Ух как от темы-то отошли...

Прокомментирую, пожалуй, только это:

В базовом DTD написано, что <div> - блочный, <a> - строчный. CSS может это изменить.

Не может он изменить это. Он может лишь перекрыть стили по умолчанию, захардкоденные в браузере. DTD определяет базовую семантику элементов, с визуализацией он никак не связан. К парсингу разметки CSS никакого отношения не имеет, CSS (хоть авторский, хоть браузерный дефолтный) применяется позже, к уже отпарсенной и построенной DOM. "Блочность" и "строчность" элементов в DTD и в CSS — разные вещи, совпадающие лишь в том дефолтном CSS (и то не всегда — в IE табличные элементы имеют дефолтный display:block, а не table и т.п., хотя их поведение разительно отличается от обычных блочных элементов, особенно в Quirks mode).

Ну а XHTML — действительно, приложение XML. Приложение весьма конкретное — реализующее ту же семантику, что и SGML-приложение под названием HTML 4.01 (XHTML1.0 — один-в-один, не зря оно называется "A Reformulation of HTML 4 in XML 1.0". Не считая синтаксиса, DTD у этих языков идентичны. И возможности "расширения" (точнее, создания новых производных языков разметки на их базе) — тоже. В XHTML1.1 это несколько проще — благодаря модульности соотв. DTD — но практической нужды в этом, имхо, немного. Умеет ли валидатор проверять такие нестандартные DTD, сходу не скажу, проверять надо (гибридные языки типа "XHTML1.1 c внедренным MathML" точно умеет, но это частные случаи)...

Yarik Voronov · January 18, 2009

Да SelenIT прав - пора закругляться. А то можем и договриться до того, что все разработчики браузеров строчат все, что в голову придет. А W3C только засоряет сеть никому не нужными мегабайтами информации.

По поводу определения SGML. Согласен - это не модель переноса данных. Что это за модель я для себя уяснил. Кому интересно надо обратиться к первоисточнику или можно прочитать в Википедии

По поводу событий на собственных тегах

FF3 выдал "object HTMLUnknownElement". Следовательно мы можем применить к нему почти все методы (удалить из дерева, присвоить атрибут и т.д.), задекларированные разработчиками FF для HTML-элемента, кроме одного - не сможем отобразить элемент <test> как, например <div>. Потому мы не можем "повесить" обработчик событий на такой элемент. Вернее можем, но тогда мы должны сами программно вызывать такие события (initEvent())

Утверждение во второй части действительно неверно. Все зависит от конкретной программы: FF3 позволяет назначать обработчики событий, а вот Konqueror 3.5.7 нет. И можно отобразить собственный тег, как например блочный, в рамках XML-модели.

s0rr0w · January 18, 2009

s0rr0w, извините, но я не зациклен на одном стандарте-рекомендации. Я просто пытаюсь объяснить некоторую тонкость вопроса. Все что вы пишете справедливо, если вы используете XML в широком смысле, а не узкую его подмодель HTML/XHTML от W3C. Но как разработчик Вы должны корректно по меньшей мере указывать тип документа.
Если вы используете в коде XML/XHTML собственные теги и атрибуты Вы не можете указывать тип документа как, например
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Вы должны написать что-то такое:
<!DOCTYPE html PUBLIC "-//S0rr0w//DTD XHTML 1.0 Transitional//EN" "http://s0rr0w.org/xhtml1/DTD/sorrow-xhtml1-transitional.dtd">
И в этом доктайпе все описать. И согласно Вашему типу все на 100% будет валидно. А потом проверить на соответствие XML и тоже все будет валидно. Но никак не может быть валидно отностительно XHTML 1.0 Transitional от W3C. И Вы сами об этом говорите:

Знаете какое самое большое западло? Спецификации противоречат одна одной, и именно поэтому выходят более свежие спецификации. Спецификация XHTML 1.1 избавлена от недочетов, которые присущи предыдущей версии.

http://www.w3.org/TR/xhtml1/#well-formed

Типичный пример ошибок. Стандарт XML допускает использование различных name spaces в XHTML, хотя это и не строго соответствует стандарту XHTML 1.0. Это написано прямо в спецификации.

> То что браузеры не понимают типы документов XML/SGML других разработчиков вопрос времени. Вообще сейчас идет тенденция отказаться от DTD в пользу более гибкого инструмента W3C XML Schema (DTD)

Та это понятно. DTD машинно крайне неудобен.

>Текстовая, sorrow. Текстовая. кнопочка западает :unsure:

Еще раз повторю, если бы это была КОМАНДА, то в XML тег <b> имел аналогичное представление что и в HTML. Но, это не команда, к нашему всеобщему счастью.

Как следует, это тот программный интерфейс (например С++) который позволяет Вам на языке JS (тоже например) изменять

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

Я что-то про текстовый исходник говорил? :rolleyes:

Все изменения в объектной модели должны отразиться на данном документе. Так вот, вернемся снова к тезису, что DOM не запрещает создавать новые теги и новые атрибуты. Наоборот, это интерфейс как раз для таких действий. Но, тег "TEST" может не присутствовать в спецификации HTML, а создать его можно

> А я Вам обосновал (надеюсь убедительно), что никакого противоречия нет, если вы используете технологию XML + CSS (HTML > 4.0 и XHTML в эту связку я тоже отнес как подмодель XML). Если Вы хотите показать такой пример противоречия стандартов, то Ваш изначальный пример был не удачен, приведите другой, если хотите.

Как правильно отображать блочные элементы внутри строчных? Если вы мне поясните, то я соглашусь, что спецификации не могут противоречить друг другу.

Пример в студию. Но не надо говорить об XML в широком смысле, потому что наши разногласия относятся к узкой его подмодели XHTML. И то что я Вам говорил, это как раз тот момент ограниченности валидатора. И эта ограниченность на мой взгляд справедлива. Потому что Вы пытаетесь проверить свой документ на соответствие стандарту XHTML от W3C. А в XHTML от W3C четко сказано что есть, а чего быть не должно.

Для меня любой документ, что HTML, что XML, что XHTML - это всего лишь один из подмножества SGML. И правила SGML не отменяли для этих языков. Вы же сужаете все разговоры строго до описанных на w3c. Найдите мне хоть один документ, которые запрещает мне создавать свои DTD для HTML.

s0rr0w · January 18, 2009

Ух как от темы-то отошли...
Прокомментирую, пожалуй, только это:
Не может он изменить это. Он может лишь перекрыть стили по умолчанию, захардкоденные в браузере. DTD определяет базовую семантику элементов, с визуализацией он никак не связан. К парсингу разметки CSS никакого отношения не имеет, CSS (хоть авторский, хоть браузерный дефолтный) применяется позже, к уже отпарсенной и построенной DOM. "Блочность" и "строчность" элементов в DTD и в CSS — разные вещи, совпадающие лишь в том дефолтном CSS (и то не всегда — в IE табличные элементы имеют дефолтный display:block, а не table и т.п., хотя их поведение разительно отличается от обычных блочных элементов, особенно в Quirks mode).

Деление на строчные и блочные элементы было задолго до CSS. Логика построения HTML базировалась на данном принципе. Логика CSS базировалась на этих же принципах, но со временем была расширена. Если раньше DIV был блочным, то он автоматически отображался как блок, а A - как строчный элемент, то с приходом CSS это перестало быть константой. Так как объектом применения CSS является только единичный тег без учета дерева документа, то инвертирование свойств display по сути является нарушением базисных принципов представления данных.

Жаль не найду отличную ветку в ньюсах мозиллы, где обсуждался данный вопрос :rolleyes:

Elendor · January 19, 2009

Дааа, от темы вы ушли, скажу одно, кто как хочет так и делает, т.к. спецификация это не указание того как надо делать это то как рекомендуют делать, а вообще (я точно не помню как там Булгаков написал): "Любой закон является насилием для человека"!!!

Yarik Voronov · January 20, 2009

>Деление на строчные и блочные элементы было задолго до CSS. Логика построения HTML базировалась на данном принципе. Логика CSS базировалась на этих же принципах, но со временем была расширена. Если раньше DIV был блочным, то он автоматически отображался как блок, а A - как строчный элемент, то с приходом CSS это перестало быть константой. Так как объектом применения CSS является только единичный тег без учета дерева документа, то инвертирование свойств display по сути является нарушением базисных принципов представления данных.

s0rr0w, если бы DIV изначально должен был бы быть синим, то мы бы с Вами наверно пытались бы поспорить, что он не может быть красным.

>Как правильно отображать блочные элементы внутри строчных? Если вы мне поясните, то я соглашусь, что спецификации не могут противоречить друг другу.

Спросите у разработчиков браузеров и видеокарт. как рекомендовано W3C я уже говорил :rolleyes:

>Текстовая, sorrow. Текстовая. кнопочка западает

>>Еще раз повторю, если бы это была КОМАНДА, то в XML тег <b> имел аналогичное представление что и в HTML. Но, это не команда, к нашему всеобщему счастью.

Контейнер, блок, строчный элемент - это понятия абстрактные, применимые к результату форматирования XML/HTML. Это то, что Вы видите на дисплее и называете это контейнером, блоком, строчным элементом. Тег - это тоже понятие абстрактное, лексема (наименьшая имеющая смысл единица). Имеющая смысл... s0rr0w, если вы покажете код XML человеку далекому от веб-технологий, он увидит там набор букв, цифр и символов, а не контейнеров, блоков, строчных элементов.

Команда, s0rr0w, это не только "бежать! стоять! сидеть! бухать!", это так же инструкция, указание. Относительно XML - указание/команда/инструкция браузеру, точнее парсеру в браузере сделать из тега (набора имеющего смысл символов) объект и отобразить его как блок, контейнер, строчный элемент. Я лично в коде XML/HTML/SVG ни разу не видел скомпилированного, уже отпарсеного, объектного кода/модуля (сразу без "посредников" понятного процессору/видеокарте)

Давайте проведем маленький эсперимент. Возьмем следующий набол символов

<?xml version="1.0" encoding="utf-8"?>
<html>
  <body>
	<h1>Что это?
	  <h2>Контейнер?</h2>
	</h1>
	<div>
	  <p>От чего зависит
		<b>отображение</b>?
	  </p>
	</div>
	<div>
	  <i>Может все-таки от от конкретнй программы?</i>
	</div>
	<h1>И плевать им всем на заголовок xml?</h1>
	<h2>Потому, что расширение html...</h2>
  </body>
</html>

И сохраним этот набор как 1.xml и тот же набот символов как 2.html. откроем поочередно эти файлы в браузере. Я использовал FF 3.0.5, IE6SP2, Opera 9.63, Konqueror 3.5.7.

Принтскрин для 1.xml http://forum.htmlbook.ru/index.php?act=att...=post&id=27

Принтскрин для 2.html http://forum.htmlbook.ru/index.php?act=att...=post&id=28

Что же такое? Я же по Вашей логике должен получить одинаковый результат. Ан нет. Все дело в расширении. И расширение диктует стиль и оформление, в данном случае. Я как линуксоид могу крупно повозмущаться. но не буду. Потому что расширения файлов были придуманы как раз для того чтобы отличать один тип файла от другого. применять к каждому типу свой набор команд, инструкций, понимать где заканчивается одна лексема и начинается другая. Может расширение файла с современной точки зрения и рудимент, но достаточно удобный и даже необходимый.

Давайте вернемся в прошлый век. К началу Интернета, когда это слово писалось с большой буквы. К тому уровню технологий. HTML был придуман для того чтобы иметь однозначное, однотипное представление данных на разных машинах. Что бы жирный текст был жирным, а таблица таблицей. И тот язык-HTML ограничен, типизирован и закрыт по набору тегов, атрибутов и порядку их отображению. Он и остается таким по сей день и более того будет таким (принцип совместимости и преемственности), пока не расствориться. Его нельзя расширить, потому что он построен на логике и уровне прошлого века, для старых браузеров и машин. То что в HTML>4 начали вставлять костыли в виде CSS - то это этап переходного периода. Потому что на смену HTML просится XML+CSS+XSL как более гибкий, удобный и не помещенный в узкие рамки сети.

Потому создавая новые теги и атрибуты и говоря программе так или иначе, что это документ HTML у Вас всегда буден невалидный HTML код (именно так я и написал в самом первом посте с которого обозначился спор). И не важно используете ли Вы стандартное пространство имен HTML или модифицированное для XML - XHTML.

По поводу XHTML SelenIT правильно заметил:

http://www.w3.org/TR/xhtml1/
This specification defines the Second Edition of XHTML 1.0, a reformulation of HTML 4 as an XML 1.0 application, and three DTDs corresponding to the ones defined by HTML 4. The semantics of the elements and their attributes are defined in the W3C Recommendation for HTML 4. These semantics provide the foundation for future extensibility of XHTML. Compatibility with existing HTML user agents is possible by following a small set of guidelines

Но заметьте это не стало HTML 5.0.... :unsure:

Возможно в ближайшем будущем смениться и смысл того, что понимается под расширением .html. И это будет как раз документ xml c оформлением по умолчанию как в HTML. Хотя что я говорю, смысл уже меняется.

>>Для меня любой документ, что HTML, что XML, что XHTML - это всего лишь один из подмножества SGML. И правила SGML не отменяли для этих языков. Вы же сужаете все разговоры строго до описанных на w3c. Найдите мне хоть один документ, которые запрещает мне создавать свои DTD для HTML.

s0rr0w, по-моему Вы не можете/не хотите понять простой вещи: что в битком набитый спичечный коробок нельзя засунуть еще несколько спичек, не повредив коробка. надо взять коробок побольше.

Проведем другой эсперемент.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html [
	<!ENTITY % html
		 PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
		 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
	<!ENTITY euro "Привет! Я евро! Я росту!">
	<!ENTITY baks "Че учтавился? Я бакс. Я сдуваюсь...">
	%html;
]>
<html>
  <body xmlns="http://www.w3.org/1999/xhtml">
	<h1>Заголовок H1
	  <h2>Заголовок H2 внутри Н1</h2>
	</h1>
	<h1>Как отображается заголовок H1</h1>
	<h2>Как отображается заголовок H2</h2>
	<div>
	  <p>От чего зависит
		<b>отображение</b>?
	  </p>
	</div>
	<div>
	  <b><>&©®</b>
	</div>
	<table width="300" border="1">
		<tr>
			<td>Это ячейка</td>
			<div>Это DIV</div>
			<td>Это ячейка</td>
		</tr>
	</table>
	<h3>€</h3>
	<h3>&baks;</h3>
  </body>
  <h2>Как отображается заголовок H2</h2>
</html>

Принскрин http://forum.htmlbook.ru/index.php?act=att...=post&id=29

Чтож ослик подкачал.... Но 3 из 4 это хороший результат. Не все хотят быть ослами....

Так вот s0rr0w, я буду первым кто плюнет в лицо тому, кто скажет что мой код-xml неверен. Он еще как верен. Но вот какая штука - я указал браузеру отобразить все элементы внутри body как того требует html по умолчанию. естественно он мне их так нарисовал, как и сказано в HTML. но вот незадача, там не сказано как рисовать DIV между <TR></TR>, а H2 между <H1></H1>. Потому что по логике HTML такого быть не может. Если взять первоначальный смысл первой пары, то получается следующая глупость: вот ячеки таблицы и вдруг новый раздел с большой буквы, а потом опять ячеки. (например, вы смотрите добрый детский мультик про кота Леопольда и вдруг посередине начинается жесткое порно на пять секунд, а потом опять мультик. вы в шоке. мультик тоже).

s0rr0w · January 20, 2009

> :rolleyes: Спросите у разработчиков браузеров и видеокарт. как рекомендовано W3C я уже говорил

Повторите еще раз, не нашел я конкретной ссылки на спецификацию.

Имеющая смысл... s0rr0w, если вы покажете код XML человеку далекому от веб-технологий, он увидит там набор букв, цифр и символов, а не контейнеров, блоков, строчных элементов.

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

Однако научить понимать XML можно по-разному. В одной вещи можно найти разные смыслы, все зависит от уровня восприятия. Именно поэтому для одних XML - это команды, а для других - это просто текст. Для меня тег не является командой.

> Что же такое? Я же по Вашей логике должен получить одинаковый результат.

По моей логике? По моей логике как раз все наоборот. Исходя из того, что тег является идентификатором блока информации, а не командой, то различные устройтва сами выбирают способ интерпретации.

Ан нет. Все дело в расширении.

А я всю жизнь думал, что дело в mime-type. :unsure:

HTML был придуман для того чтобы иметь однозначное, однотипное представление данных на разных машинах.

Где вы такого начитались?

Его нельзя расширить, потому что он построен на логике и уровне прошлого века, для старых браузеров и машин. То что в HTML>4 начали вставлять костыли в виде CSS - то это этап переходного периода. Потому что на смену HTML просится XML+CSS+XSL как более гибкий, удобный и не помещенный в узкие рамки сети.

Ага, пока не поздно, расскажите это консорциуму w3c, а то они бедняги не в курсе, что HTML нельзя расширить...

Потому создавая новые теги и атрибуты и говоря программе так или иначе, что это документ HTML у Вас всегда буден невалидный HTML код (именно так я и написал в самом первом посте с которого обозначился спор). И не важно используете ли Вы стандартное пространство имен HTML или модифицированное для XML - XHTML.

Что есть валидный код? Вот вопрос в лоб.

>s0rr0w, по-моему Вы не можете/не хотите понять простой вещи: что в битком набитый спичечный коробок нельзя засунуть еще несколько спичек, не повредив коробка. надо взять коробок побольше.

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

Так вот s0rr0w, я буду первым кто плюнет в лицо тому, кто скажет что мой код-xml неверен. Он еще как верен. Но вот какая штука - я указал браузеру отобразить все элементы внутри body как того требует html по умолчанию. естественно он мне их так нарисовал, как и сказано в HTML. но вот незадача, там не сказано как рисовать DIV между <TR></TR>, а H2 между <H1></H1>. Потому что по логике HTML такого быть не может. Если взять первоначальный смысл первой пары, то получается следующая глупость: вот ячеки таблицы и вдруг новый раздел с большой буквы, а потом опять ячеки. (например, вы смотрите добрый детский мультик про кота Леопольда и вдруг посередине начинается жесткое порно на пять секунд, а потом опять мультик. вы в шоке. мультик тоже).

Ваш код неверен. Я не нарушал спецификаций, указав свою область имен, а вы - нарушаете.

Yarik Voronov · January 20, 2009

>Спросите у разработчиков браузеров и видеокарт. как рекомендовано W3C я уже говорил
Повторите еще раз, не нашел я конкретной ссылки на спецификацию.

http://www.w3.org/TR/CSS21/visuren.html

http://www.w3.org/TR/CSS21/box.html

По моей логике? По моей логике как раз все наоборот. Исходя из того, что тег является идентификатором блока информации, а не командой, то различные устройтва сами выбирают способ интерпретации.

Не понял. Поясните. Я вам достаточно подробно объяснил процесс того, что происходит, когда браузер получает документ. Расскажите как это выглядит с вашей точки зрения. А то я вижу только голословное отрицание того что написано. Расскажите, например как происходит процесс интерпритации, по-вашему.

>>Ан нет. Все дело в расширении
А я всю жизнь думал, что дело в mime-type.

/etc/mime.types (выдержка)

# MIME type			Extension (через пробел)
application/docbook+xml docbook
application/flash-video flv
application/illustrator ai
application/javascript js
application/mac-binhex40
application/mathematica nb
application/x-asmx asmx
application/x-asp asp
application/x-awk
application/x-axd axd
application/x-bzip bz2 bz
application/xhtml+xml xhtml
text/html html htm
text/htmlh
text/mathml mml
text/plain txt asc
text/rdf rdf
text/rfc822-headers
text/richtext rtx
text/rss rss
text/xml xml

Вы не утрудили себя понять, смысл написанного после "Все дело в расширении".

Что есть валидный код? Вот вопрос в лоб.

Первый закон Ньютона помните? В житейской итерпритации звучит просто: Все в мире относительно. Я Вам уже говорил что относительно HTML/XHTML спецификаций от W3C.

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

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

Ваш код неверен. Я не нарушал спецификаций, указав свою область имен, а вы - нарушаете.

3.1.2. Using XHTML with other namespaces

s0rr0w · January 20, 2009

http://www.w3.org/TR/CSS21/visuren.html
http://www.w3.org/TR/CSS21/box.html
Точнее можно? Я просил указать место в спецификации, где разрешается внутри инлайн бокса создавать блок.
Не понял. Поясните. Я вам достаточно подробно объяснил процесс того, что происходит, когда браузер получает документ. Расскажите как это выглядит с вашей точки зрения. А то я вижу только голословное отрицание того что написано. Расскажите, например как происходит процесс интерпритации, по-вашему.
Одна проблема - все браузеры делают это по-разному.
Итак, приходит нам текстовый документ. Первое, что нужно сделать - распарсить и построить DOM-структуру. Добавить элементы, которые должны присутствовать всегда (например HEAD). Потом добавляем к дереву базовый CSS, пользовательский CSS. Выполняем JS. После этого скармливаем дерево рендерингу. Этому модулю пофиг как называются теги, как они наследуются, его задача - отобразить некое дерево с неким CSS. Если есть уникальные случаи, которые повторяют баги различных браузеров в зависимости от доктайпа, то обработать и их.
Как видим, никаких комманд, директив и прочего. Есть структура данных, есть описание принципов отображения структуры, берем и показываем. Или не показываем.
Вы не утрудили себя понять, смысл написанного после "Все дело в расширении".
Простите, но расширение может быть разным. А контент - типизированным. Если gif картинку назвать как jpeg, то контент автоматически не изменится. Это будет картинка gif с расширением jpeg. Скормите браузеру контент HTML с mime-type'ом text/html под видом jpeg файла, и, о чудо, вы увидите не картинку, а HTML.
Я свой тезис про коробок пояснил аж примером с картинкой. Поясните свой. Будте любезны
Зачем? Ваше мышление не выходит за рамки браузера, HTML, XHTML, XML. А мое мышление не ограничивается сугубо визуальным представлением данных. Что я вам показывать буду?
> 3.1.2. Using XHTML with other namespaces
Зачем вы мне приводите мою же ссылку? Что я там должен прочитать?

SelenIT · January 21, 2009

Насчет строчного и блочного. Как я понимаю, в доцээсэсные времена соответствие между нынешними content models и visual formatting model было однозначным, и соблюдение требований первого автоматически гарантировало штатный режим для рендеринга (т.е. отсутствие подобного). А теперь, когда структура/семантика сама по себе, а визуализация сама по себе, вебмастеру приходится самому думать и про второе, и, на всякий случай - для невизуальных ПА, к примеру - про первое. Потому что валидности разметки и даже корректности DOM уже мало для нормального отображения, нужна еще логичность стилей.

расширение может быть разным. А контент - типизированным.

Насколько я понял, Yarik Voronov имел в виду частный случай - открытие документа с локального диска. Тогда порядочные браузеры, действительно, определяют Content-type по расширению файла.

Я не нарушал спецификаций, указав свою область имен, а вы - нарушаете.

Примеры Yarikа Voronovа не нарушают спецификации XML 1.0 (указанного в XML-прологе), это действительно веллформный XML. О валидности первого примера речь идти не может, т.к. нет схемы. Второй пример валиден (насколько я успел заметить) относительно своего оригинального доктайпа, формально он - не XHTML1.x (тем более не HTML4.x), поэтому "валидировать" его по этим спецификациям тоже нет смысла. Но поскольку он остается веллформным XML1.0 и указывает на стандартное XHTML-ное пространство имен, невалидирующие парсеры браузеров могут интерпретировать его как фактически XHTML5 с простительными ошибками (что и делают...

Эх, но до чего же познавательный оффтопик получается! По-моему, стоит перенести соотв. часть темы в раздел "HTML" или "Теория", да по-хорошему закрепить...

s0rr0w · January 21, 2009

Потому что валидности разметки и даже корректности DOM уже мало для нормального отображения, нужна еще логичность стилей.

В точку!

> Насколько я понял, Yarik Voronov имел в виду частный случай - открытие документа с локального диска. Тогда порядочные браузеры, действительно, определяют Content-type по расширению файла.

Надо посмотреть в исходниках мозиллы, иначе можно только предполагать.

> Примеры Yarikа Voronovа не нарушают спецификации XML 1.0 (указанного в XML-прологе), это действительно веллформный XML.

Первый не берем в рассчет вообще.

Второй пример валиден (насколько я успел заметить) относительно своего оригинального доктайпа,

Well-formed, но невалиден. Доктайп действительно указывает на XML, но не забываем про DTD. В DTD указано, что это документ с локальным DTD, но элемент html имеет структуру XHTML. А так как структура приведенного документа не является HTML структурой, то этот документ невалиден.

В моем же примере указано пространство имен с указанием источника структуры. Это не нарушает спецификацию XML, но является спорным с точки зрения HTML моментом, на что и было указано в спецификации по XHTML 1.0, с чем и "боролись" в XHTML 1.1

> Эх, но до чего же познавательный оффтопик получается! По-моему, стоит перенести соотв. часть темы в раздел "HTML" или "Теория", да по-хорошему закрепить... :unsure:

:rolleyes: Хорошо, что есть хоть немного людей, которые считают тему познавательной.

Yarik Voronov · January 21, 2009

>>>>Как правильно отображать блочные элементы внутри строчных? Если вы мне поясните, то я соглашусь, что спецификации не могут противоречить друг другу.

>>>Спросите у разработчиков браузеров и видеокарт. как рекомендовано W3C я уже говорил

>>http://www.w3.org/TR/CSS21/visuren.html http://www.w3.org/TR/CSS21/box.html

>Точнее можно? Я просил указать место в спецификации, где разрешается внутри инлайн бокса создавать блок.

http://forum.htmlbook.ru/index.php?showtop...ost&p=83918

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

>Well-formed, но невалиден. (прмеч. автора топика: пример 2 из топика 40) Доктайп действительно указывает на XML, но не забываем про DTD. В DTD указано, что это документ с локальным DTD, но элемент html имеет структуру XHTML. А так как структура приведенного документа не является HTML структурой, то этот документ невалиден.

В моем коде не сказано, что DTD указывает на структуру документа HTML. В этом коде сказано, что в данном документе XML будут применены сущности соответствующие типу и именам указанным в публичном стандарте //W3C//DTD XHTML 1.0 Transitional//EN. Указано из какого источника браузер должен загрузить эти имена сущностей. Так же указано, что сущность € следует понимать как описано локально. А так же добавить новую сущность &baks; В первой директиве DOCTYPE сказано чтобы все это было применено начиная с корневого элемента html. А XML мне не запрещает использовать такие же буковки в именах тегов как в XHTML... (так же см топик 44)

>Надо посмотреть в исходниках мозиллы, иначе можно только предполагать.

s0rr0w, надо посмотреть в таком случае не только исходники Мозиллы. Но и Оперы, Конкурера и Ослика. Я специально использовал 4 браузера для чистоты эксперемента. Так же следует посмотреть исходники Apache 2.2.11. Именно с него я получал документы.

>Есть структура данных, есть описание принципов отображения структуры, берем и показываем. Или не показываем.

s0rr0w, поробуйте написать свой парсер. тогда Вам наверно станет понятна и моя точка зрения. Парсер - сам лично не имеет мозгов. Программист-человек в него вкладывает алгоритм как "действовать" в той или иной ситуации, как "понимать" тот или иной набор символов. Потому парсер как собака понимает только команды и инструкции. Но я принимаю вашу точку зрения. Ибо она достаточно широка, но не конкретна.

Yarik Voronov 2 s0rr0w Вы не утрудили себя понять, смысл написанного после "Все дело в расширении". (см топик 40)

s0rr0w 2 Yarik Voronov Простите, но расширение может быть разным. А контент - типизированным. Если gif картинку назвать как jpeg, то контент автоматически не изменится. Это будет картинка gif с расширением jpeg. Скормите браузеру контент HTML с mime-type'ом text/html под видом jpeg файла, и, о чудо, вы увидите не картинку, а HTML.

SelenIT 2 s0rr0w Насколько я понял, Yarik Voronov имел в виду частный случай - открытие документа с локального диска. Тогда порядочные браузеры, действительно, определяют Content-type по расширению файла.

s0rr0w Надо посмотреть в исходниках мозиллы, иначе можно только предполагать.

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

как-то мне захотелось переписать на диск (CD-R) песни одной своей любимой группы. ессно дело хочу цифровой диск. и вот досада - песни оцифрованы и лежат с расширением WAV. ну ессно. дело не хитрое, надо перекодировать в MP3. скачал простой, но мощный перекодировщик на perl. только запустил перекодировку - ошибка: "Неизвестный формат данных". что за ерундень? наверно, кодировщик "старый", а новой версии на официальном репозитарии нет. лан, думаю, фигня, соберу из сырца. собрал - таже ерундень: "Неизвестный формат данных". Я думаю что еще за неизвестный формат - на компе проигрываются. значит известный. в скрипте перекодировщике можно выбрать столько форматов, что глаза разбегаются. Мучился наверно часа три (я ж ленивый, не хочу записывать 10 аудио болванок - класть некуда). уже полез в сам скрипт-перекодировщика с "напильником". и тут совершенно ненавязчиво мой взгляд останавливается на поле "описание" в проводнике KDE. А там черным по белому напротив каждого файла WAV написано: "аудио файл формата MPEG".... матерился мало, смеялся долго. Так вот тот источник песен альбомов группы видимо так боялся за свои права, что файлы MP3 тупо переименовал в WAV (WAV - формат записи звука без сжатия, кто не знает). я все естественно переименовал обратно, и с тех пор наслаждаюсь музыкой любимой группы даже в машине. После переименования и перекодировщик заработал как надо. Такой "оригинальный" способ защиты информации может быть и сработал бы лет 5 назад. но...

Пора делать выводы.

KDE хорошая штука - в ней есть прога которая анализирует типы mime по первым нескольким байтам файла.

Но давайте не будем забывать что сеть - это не только сервера, а жизнь не только сеть. Встречается очень много других устройств (аппаратные-файрволы, контроллеры высокого и низкого уровня, просто устройста маршрутизации, модемы и т.п.). Я не говорю сколько разных типов клиентских устройств существует. Но не всякое из них может отправить корректно mime-type и не каждое может правильно его обработать. (Сервер в заголовке отправляет "Content-Type text/html; charset=windows-1251", давая четкое указание клиенту что сейчас он получит инфу в формате text синтаксиса html кодировки win). Но вернемся к устройствам. Допустим, нам надо запрограммировать очень маленький контроллер и написать к нему веб-интерфейс. к сожалению мы не можем в него втиснуть все функции сервера Apache, например, без ущерба для основного программного обеспечения, как бы того и ни хотели (у него ни мозгов ни памяти, более того надобности). А так же нам надо написать маленкий браузер (для компактного устройства), с которого и будет происходить управление контроллером в экстренных ситуациях. Вот здесь-то как раз нам и пригодятся дефолтные расширения файлов mime-типов и дефолтный синтаксис html (зачем нам изобретать велосипед - у нас же в котроллере нет столько мозгов, а в устройстве столько места). ок запрограммировали. теперь через год - выходит новая модификация устройства доступа например поддерживащее семантику xml для новых контроллеров. Но старый-то контроллер работает, его не сняли с производства. Потому как программисты мы должны оставить совместимость со старым форматом. Более того мы можем управлять и старым и новым контроллером например с КПК, ноутбука или компьютера. И каждому из этих клиентов будет ясно и понятно что они получают (даже без заголовка mime типа)

Тем файлом /etc/mime.types на моей машине пользуются не только пользовательские программы. но и сервера (MySQL, Apache, Samba). И серверу Apache предельно ясно какой заголовок типа он должен отправить увидив файл с расширением jpeg/xml/pdf/html/... а мне нет надобности что-то там перекраивать. Apache "знает" что увидив .html он должен отдать его как текст, а увидив php (application/x-php) вызвать интерпретатор РНР и отдать клиенту результат. Разработчики Apache не тратят машинное и процессорное время на анализ первых нескольких байт кода. Как и не тратят времени машины на проверку того что там в результате программист-РНР "нашкодер".

Итак, я до сих пор придерживаюст мнения, что создавая новые теги и атрибуты и пространства имен там где это не предусмотрено (HTML/XHTML) вы тем самым не только нарушаете спецификации, но и вставляете палки в колеса другим разработчикам ПО и устройств. Если конечно, s0rr0w, вы хотите придерживаться такой философии, присоединяйтесь к Мелкософту.

Я лично благодарен W3C. Эти ребята делают нужную работу по унификации и стандартизации. Когда каждый пишет как хочет, возникает слишком много абсурда.

Про DOM отпишусь в другой теме. Я не забыл.

[Offtopic]

>>Я свой тезис про коробок пояснил аж примером с картинкой. Поясните свой. Будте любезны.

>Зачем? Ваше мышление не выходит за рамки браузера, HTML, XHTML, XML. А мое мышление не ограничивается сугубо визуальным представлением данных. Что я вам показывать буду?

Все понятно, Вы просто не можете пояснить. Легко сказать - трудно сделать. Ну что ж Вы видимо еще молоды, Вам простительно.

Так вот, s0rr0w. "Сидя в плотном железном ящике вы не можете точно сказать, каких он размеров снаружи, пока не покинете пределы этого самого ящика". От чего же смогу. Давайте, только конкретизируем, что понимать под точно сказать. Без соответсвующего инструмента и действий я и снаружу не смогу точно сказать какого он размера.

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

[/Offtopic]

>> 3.1.2. Using XHTML with other namespaces

>Зачем вы мне приводите мою же ссылку? Что я там должен прочитать?

SelenIT ответил за меня (топик 44)

ЗЫ: Сегодня мне аська (программа Kopete из KDE 3) выдала: "Наш сервер не поддерживает вашу версию клиента. Скачайте новую версию клиента с нашего сайта". И что? Мне из-за этого ставить Windows? (вопрос риторический)

Yarik Voronov · January 21, 2009

Продолжу тему контроллеров.

С другой стороны давайте выйдем за рамки "железного ящика" одного контроллера. И представим себе, что мы продвинутые программисты и перед нами стоит задача сделать модуль управления большим производством, со множеством датчиков, контроллеров, контуров регулировая. Но чтоб сладкой фантазия не казалась внесем м-а-а-а-люсенький нюанс: все наши устройства высокого уровня (датчики оставим в стороне) говорят с нами разными языками (посылают информацию структурированную различными правилами. как бог подсказал разработчикам). Нам надо все это собрать и вывести на один компьютер (главный-управляющий). Сколько мы должны написать парсеров? столько сколько устройств. Пипец, подкрался незаметно. Каждый парсер тормозит компьютер. раз тормозит значит информация поступает несвоевременная, значит снижается скорость принятия решения. Значит снижается качество.

Теперь подойдем с третьей стороны. Мы написали код (все тот же контроллер) но запрограммировали его на отдачу нестандртной информации. (то что другие простые устройства этот контроллер понимать скорее всего не будут - это факт) А потом нас перевели в другой отдел. повысили или еще что. На наше место придет другой программист. Он полезет в наш код и будет разбираться с нуля. Да еще звонить и просить объяснить что тут к чему, потому что звонит раздраженный покупатель и требует чтоб его "Трактор от ТРС" мог понять этот контроллер. Пожалейте себя, в конце концов.

s0rr0w · January 21, 2009

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

Я просил ссылку на спецификацию, а не на ваше резюме. Первоисточник я читал, и в нем я не нашел ни одного упоминания что делать, если в инлайн блоке вдруг кто-то захочет поместить блочный элемент.

Вариантов интерпретации масса. Сделать два инлайн блока и один обычный в середине. Проигнорировать блочный элемент вообще. Переместить блочный элемент за пределы строчного элемента.

Но никогда блочный элемент не будет помещен внутрь строчного.

> В моем коде не сказано, что DTD указывает на структуру документа HTML. В этом коде сказано, что в данном документе XML будут применены сущности соответствующие типу и именам указанным в публичном стандарте //W3C//DTD XHTML 1.0 Transitional//EN. Указано из какого источника браузер должен загрузить эти имена сущностей.

Как не сказано?

<!ENTITY % html
		 PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
		 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" < это что такое? Это описание структуры контента html элемента.

> s0rr0w, поробуйте написать свой парсер. тогда Вам наверно станет понятна и моя точка зрения. Парсер - сам лично не имеет мозгов. Программист-человек в него вкладывает алгоритм как "действовать" в той или иной ситуации, как "понимать" тот или иной набор символов. Потому парсер как собака понимает только команды и инструкции. Но я принимаю вашу точку зрения. Ибо она достаточно широка, но не конкретна.

Понимание алгоритма визуализации может быть и без написания собственного парсера. Еще раз повторю, если бы теги были командами, то "собака"-браузер выделял бы текст в тегах <B> жирным даже в XML документах. Парсер занимается обработкой потока. Ему все равно, какие теги, сколько их, какой у них уровень вложенности. Задача парсера - построить DOM дерево. Безликое дерево.

> Итак, я до сих пор придерживаюст мнения, что создавая новые теги и атрибуты и пространства имен там где это не предусмотрено (HTML/XHTML) вы тем самым не только нарушаете спецификации, но и вставляете палки в колеса другим разработчикам ПО и устройств. Если конечно, s0rr0w, вы хотите придерживаться такой философии, присоединяйтесь к Мелкософту.

Я лично благодарен W3C. Эти ребята делают нужную работу по унификации и стандартизации. Когда каждый пишет как хочет, возникает слишком много абсурда.

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

> Все понятно, Вы просто не можете пояснить. Легко сказать - трудно сделать. Ну что ж Вы видимо еще молоды, Вам простительно.

Я поясняю на протяжении многих постов, но вот пояснения ничего не дают. Может потому что вы молоды? Максимализм и все такое...

Продолжу тему контроллеров.
...

К чему все это? Пофилософствовать и я могу... Давайте ближе к теме.

Yarik Voronov · January 22, 2009

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

Да ладно... "Не будет"... Вы сами несколько постов назад приводили такой пример. А в спецификации достаточно ясно описана модель блочного форматирования и визуального предствления. И там (9 Visual formatting model) достаточно ясно дается понимание того что display относится к положению самого элемента, и его потомков.

9.2.4 The 'display' property
block This value causes an element to generate a block box.
inline This value causes an element to generate one or more inline boxes.
9.4.1 Block formatting contexts
In a block formatting context, boxes are laid out one after the other, vertically, beginning at the top of a containing block. The vertical distance between two sibling boxes is determined by the 'margin' properties. Vertical margins between adjacent block boxes in a block formatting context collapse.
9.4.2 Inline formatting context
In an inline formatting context, boxes are laid out horizontally, one after the other, beginning at the top of a containing block. Horizontal margins, borders, and padding are respected between these boxes. The boxes may be aligned vertically in different ways: their bottoms or tops may be aligned, or the baselines of text within them may be aligned. The rectangular area that contains the boxes that form a line is called a line box.

Но там нигде не сказано, что низя (ну никак низя) поместить в inline box block box. В спецификации ясно написано, как элементы внутри этих блоков могут размещаться. Обратимся к разъяснениям того что такое inline box и block box

Inline-level elements are those elements of the source document that do not form new blocks of content; the content is distributed in lines

Это элементы которые не формируют вокруг себя нового блока (переноса строки, грубо выражаясь)

Block-level elements are those elements of the source document that are formatted visually as blocks (e.g., paragraphs).

Это те элементы которые наоборот генерируют вокруг себя блок, т.е перенос строки. Они (такие элементы, но не их потомки) визуализируюся как блок. Заметьте с пецификации не указано через запятую какие теги строчные а какие блочные.

Итак, определяя inline box Вы задаете положение самого этого блока и его потомков, относительно родителя этого inline box. block box внутри inline box будет генерировать перенос строки. Но будет отображаться inline относительно родителя inline box'а и не будет выходить за его пределы. Никакого противоречия не вижу. Заодно посмотрите раздел 9.2.1.1 Anonymous block boxes, там есть хороший пример.

Еще раз повторюсь, что то что вы говорите по поводу точно строчных и точно блочных элементов - это закодировано как by default. для тех кто не хочет увеличивать объем кода дополнительными таблицами стилей по тем или иным причинам. и это совместимость и приемственность стандартов. на мой взляд - довольно удобно.

> В моем коде не сказано, что DTD указывает на структуру документа HTML. В этом коде сказано, что в данном документе XML будут применены сущности соответствующие типу и именам указанным в публичном стандарте //W3C//DTD XHTML 1.0 Transitional//EN. Указано из какого источника браузер должен загрузить эти имена сущностей.
Как не сказано?
<!ENTITY % html
		 PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
		 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" < это что такое? Это описание структуры контента html элемента.

В точку. Если брать только эту строчку кода. Инструкцией <!ENTITY> я задаю браузеру взять только сущности, а не структуру. 4.1 Character and Entity References

Другой момент, что я намерено ввожу браузер в заблуждение. Ведь в dtd описана еще и структура элементов. Он должен такие инструкции описания проигнорировать. А вот это уже зависит от того что написано в коде парсера (в 3 из 4 что-то логичное). Если вы уберете из моего кода шапку DOCTYPE. вы получите такой же результат (естественно удалив из кода и сущности).

Вернусь немного к прошлым постам. "Браузер не грузит DTD сторонних разработчиков". Примерно так это звучало.

Оpera 9.63 будет загружать, если разрешить в конфигах XML: External Entities

FireFox < 3 к сожалению не сможет. по соображениям безопасности. в FF3 я не смог найти опцию включения/выключения

Load external data file in XML

FF won't parse my xml DTD's external general entities

>Понимание алгоритма визуализации может быть и без написания собственного парсера. Еще раз повторю, если бы теги были командами, то "собака"-браузер выделял бы текст в тегах <B> жирным даже в XML документах. Парсер занимается обработкой потока. Ему все равно, какие теги, сколько их, какой у них уровень вложенности. Задача парсера - построить DOM дерево. Безликое дерево.

Браузер будет рисовать мне в "тегах <B> жирным даже в XML документах". Для этого надо сделать всего одну вещь - в /etc/mime.types подправить одну строчку "text/html html htm xml", чтобы сервер в заголовке отправлял text/html, а не text/xml. Браузер "собака" не такая уж и глупая. В его парсере существует множество алгоритмов. Если вы возьмете FF+FireBug и посмотрите на DOM второго примера поста 40, то увидите что body и все что внутри него имеют семантику HTML при этом оставаясь элементами дерева XML. И тут нет противоречия, потому что XML "коробок побольше". Но внутри body я не могу просто так написать свой тег - мне нужно будет объявить другое пространство имен (которому принадлежит мой тег), чтобы парсер клиента не пытался его "понять" как элемент пространства HTML/XHTML и не наделал ошибок.

Давайте, я возьму на себя смелость расширить для Вас, понятие команды применительно к тегу. Тег - с точки зрения программного продукта, это команда/инструкция в контексте какой-либо модели документа.

>> Итак, я до сих пор придерживаюст мнения, что создавая новые теги и атрибуты и пространства имен там где это не предусмотрено (HTML/XHTML) вы тем самым не только нарушаете спецификации, но и вставляете палки в колеса другим разработчикам ПО и устройств. Если конечно, s0rr0w, вы хотите придерживаться такой философии, присоединяйтесь к Мелкософту.

Я лично благодарен W3C. Эти ребята делают нужную работу по унификации и стандартизации. Когда каждый пишет как хочет, возникает слишком много абсурда.

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

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

[Offtopic]

>> Все понятно, Вы просто не можете пояснить. Легко сказать - трудно сделать. Ну что ж Вы видимо еще молоды, Вам простительно.

>Я поясняю на протяжении многих постов, но вот пояснения ничего не дают. Может потому что вы молоды? Максимализм и все такое...

Точно! Я молод! Горячь и необуздан! Ха-ха. Спасибо за комплимент. Здесь - лучшее место. Сейчас - лучшее время. У-РА!

[/Offtopic]

s0rr0w · January 22, 2009

А в спецификации достаточно ясно описана модель блочного форматирования и визуального предствления. И там (9 Visual formatting model) достаточно ясно дается понимание того что display относится к положению самого элемента, и его потомков.

Так так так, я весь во внимании...

Но там нигде не сказано, что низя (ну никак низя) поместить в inline box block box. В спецификации ясно написано, как элементы внутри этих блоков могут размещаться. Обратимся к разъяснениям того что такое inline box и block box

Ага, ясно написано. Есть блок - делай блок. Помещай в блоки другие блоки и лайн боксы. Есть лайн бокс - внутри могут быть другие инлайн элементы.

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

DIV станет строчным, значит будет создан анонимный блок, в который будет помещен line-box, но содержимое его будет нулевым, так как следующий элемент не является строчным элементом. Раз содержимое нулевое, то высота данного блока будет нулевой.

Нужно создать блочный элемент за line-box-ом. Внутри него создать line-box и поместить текст ссылки.

Итак, мы никак не можем засунуть блок внутрь инлайн блока. Можем создать только новый блок.

Похвально что вы прочитали спеку, но, к сожалению, не до конца.

> Другой момент, что я намерено ввожу браузер в заблуждение. Ведь в dtd описана еще и структура элементов. Он должен такие инструкции описания проигнорировать.

Как это проигнорировать? Где вы такое прочитали? DTD создан для того, чтобы описывать элементы и их структуру.

> Браузер будет рисовать мне в "тегах <B> жирным даже в XML документах". Для этого надо сделать всего одну вещь - в /etc/mime.types подправить одну строчку "text/html html htm xml", чтобы сервер в заголовке отправлял text/html, а не text/xml.

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

> Давайте, я возьму на себя смелость расширить для Вас, понятие команды применительно к тегу. Тег - с точки зрения программного продукта, это команда/инструкция в контексте какой-либо модели документа.

И что должен сделать браузер при виде тега <COLLAPSE>? Какую команду выполнить?

> стоп. стоп. не так быстро. я ни сколько не упираюсь, что спецификации не должны совершенствоваться. наоборот. я только за. я лишь вам обосновываю свою точку зрения (выражаясь иносказательно): что напильник должен быть применен именно там и именно так, где он нужен.

Разработчики спецификаций тоже люди. И им свойственно что-то упускать, что-то забывать.

Edited January 22, 2009 by s0rr0w

Yarik Voronov · January 23, 2009

>Есть блок - делай блок. Помещай в блоки другие блоки и лайн боксы. Есть лайн бокс - внутри могут быть другие инлайн элементы. Итак, что произойдет, если попытаться поместить болочный элемент внутрь строчного.

DIV станет строчным, значит будет создан анонимный блок, в который будет помещен line-box, но содержимое его будет нулевым, так как следующий элемент не является строчным элементом. Раз содержимое нулевое, то высота данного блока будет нулевой. Нужно создать блочный элемент за line-box-ом. Внутри него создать line-box и поместить текст ссылки. Итак, мы никак не можем засунуть блок внутрь инлайн блока. Можем создать только новый блок. Похвально что вы прочитали спеку, но, к сожалению, не до конца.

Да, здесь я с Вами согласен - будет огранизован анонимный блочный элемент вокруг строчного, содержащий блочный. А строчный блок будет разорван. Блочный и строчный станут потомками анонимного block-box. Так где здесь противоречие? Договариваете. А то останавливаетель на середине. Сделайте, пожалуйста, выводы в контексте своего тезиса:

Еще один из приколов конфликта стандартов на примере CSS.
С точки зрения механической валидности код валиден на 100%.
С точки зрения рендеринга это невалидный код.

>> Другой момент, что я намерено ввожу браузер в заблуждение. Ведь в dtd описана еще и структура элементов. Он должен такие инструкции описания проигнорировать.

>Как это проигнорировать? Где вы такое прочитали? DTD создан для того, чтобы описывать элементы и их структуру.

"Как это проигнорировать?" Вы где-то прочитали другое? Поделитесь ссылочкой на точное место, как браузер должен понимать инстукцию <!ENTITY>. A то я вижу в спецификации XML1.0 (4th edition) для декларации типа другую инструкцию

2.8 Prolog and Document Type Declaration
[Definition: The XML document type declaration contains or points to markup declarations that provide a grammar (прим. автора поста: grammar - основы, основные принципы, основные правила) for a class of documents. This grammar is known as a document type definition, or DTD....]

То есть там однозначно написано, что для декларации типа документа используется инструкция <!DOCTYPE>, a не <!ENTITY>. А для декларации типа документа как XHTML далеко недостаточно только инструкции <!ENTITY>.

>> Давайте, я возьму на себя смелость расширить для Вас, понятие команды применительно к тегу. Тег - с точки зрения программного продукта, это команда/инструкция в контексте какой-либо модели документа.

>И что должен сделать браузер при виде тега <COLLAPSE>? Какую команду выполнить?

В контексте какого типа документа?

Sign In

Обработчики в js

Question

Link to comment

Share on other sites

Top Posters For This Question

Popular Days

Top Posters For This Question

Popular Days

Posted Images

54 answers to this question

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Обсуждения

Important Information