HTML5
От: c-smile Канада http://terrainformatica.com
Дата: 29.08.11 23:57
Оценка:
Известно что HTML5 это зонтик под которым прячется семейство технологий кроме собственно markup: video,canvas,local storage и пр.

В данном случае речь идет про markup только. По сравнению с HTML4 мы получаем в принципе две вещи:
1. Расширенный набор tags/elements. Включая дополнительный набор <input type=...>
2. Формализованные правила обработки ошибок парсером.

Собственно хочу обратить внимание на пункт #2. Как мне представляется в нем живет коллизия.

Скажем есть некий ЯП Alpha. Берем и добавляем в него правила обработки и восстановления после ошибок.
И просим всех эти правила строго выполнять.

Фактически после такой доработки ЯП Alpha получает новую грамматику в которой уже невалидные конструкции становятся
как бы валидными т.е. ожидаемыми и с предсказуемыми последствиями. Т.е. на самом деле мы получили ЯП Beta в котором
Alpha есть подмножество.

Или как?
Re: HTML5
От: adontz Грузия http://adontz.wordpress.com/
Дата: 30.08.11 01:24
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>2. Формализованные правила обработки ошибок парсером.


Так разве это всё не рекомендация?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re: HTML5
От: Sinix  
Дата: 30.08.11 01:35
Оценка:
Здравствуйте, c-smile, Вы писали:


CS>Фактически после такой доработки ЯП Alpha получает новую грамматику в которой уже невалидные конструкции становятся

CS>как бы валидными т.е. ожидаемыми и с предсказуемыми последствиями. Т.е. на самом деле мы получили ЯП Beta в котором
CS>Alpha есть подмножество.

Всё так, только я пока что не вижу проблемы. Мы это уже проходили на примере XHTML и ничего страшного не случилось
Re[2]: HTML5
От: Mamut Швеция http://dmitriid.com
Дата: 30.08.11 07:00
Оценка: +1 :))
CS>>Фактически после такой доработки ЯП Alpha получает новую грамматику в которой уже невалидные конструкции становятся
CS>>как бы валидными т.е. ожидаемыми и с предсказуемыми последствиями. Т.е. на самом деле мы получили ЯП Beta в котором
CS>>Alpha есть подмножество.

S>Всё так, только я пока что не вижу проблемы. Мы это уже проходили на примере XHTML и ничего страшного не случилось



Да. XHTML умер.


dmitriid.comGitHubLinkedIn
Re[3]: HTML5
От: Sinix  
Дата: 30.08.11 07:15
Оценка: +1 :)
Здравствуйте, Mamut, Вы писали:

M>Да. XHTML умер.

Ага, я хотел написать то же самое, но побоялся, что меня опять обзовут кэпом
Автор: Sinix
Дата: 15.04.11
Re: HTML5
От: goto Россия  
Дата: 30.08.11 10:21
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Известно что HTML5 это зонтик под которым прячется семейство технологий кроме собственно markup: video,canvas,local storage и пр.


CS>В данном случае речь идет про markup только. По сравнению с HTML4 мы получаем в принципе две вещи:

CS>1. Расширенный набор tags/elements. Включая дополнительный набор <input type=...>
CS>2. Формализованные правила обработки ошибок парсером.

CS>Собственно хочу обратить внимание на пункт #2. Как мне представляется в нем живет коллизия.


Почему именно коллизия?

CS>Скажем есть некий ЯП Alpha. Берем и добавляем в него правила обработки и восстановления после ошибок.

CS>И просим всех эти правила строго выполнять.

CS>Фактически после такой доработки ЯП Alpha получает новую грамматику в которой уже невалидные конструкции становятся

CS>как бы валидными т.е. ожидаемыми и с предсказуемыми последствиями. Т.е. на самом деле мы получили ЯП Beta в котором
CS>Alpha есть подмножество.

CS>Или как?


По-моему, зависит от конкретных правил обработки (я не знаком с html5). Можно представить правила, исключающие или "урезающие" конструкции, ошибочные для Alpha. Тогда может получиться наоборот — Beta есть подмножество Alpha. Мне такой подход даже кажется более логичным, хотя я не знаток веб-программирования.

оффтоп
Вспоминается старинный компилятор PL/1 на ЕС ЭВМ. Встречая ошибку, он своим "умом" стремился ее автоматически исправить и все же отправить программу на исполнение (тогда была распространена такая практика — отправлять программу на компиляцию и исполнение одним пакетом. Исполнение могло занимать многие часы). Никакой пользы от такого подхода не было, а вред был. Но это так. Понятно, что ситуация с html5 — другая.
Re[2]: HTML5
От: goto Россия  
Дата: 30.08.11 10:28
Оценка:
G>По-моему, зависит от конкретных правил обработки (я не знаком с html5). Можно представить правила, исключающие или "урезающие" конструкции, ошибочные для Alpha. Тогда может получиться наоборот — Beta есть подмножество Alpha.

Да, я ошибся. На входе-то Beta == Alpha + ошибки => Beta > Alpha.
Re[2]: HTML5
От: c-smile Канада http://terrainformatica.com
Дата: 30.08.11 17:46
Оценка:
Здравствуйте, goto, Вы писали:

G>оффтоп

G>Вспоминается старинный компилятор PL/1 на ЕС ЭВМ. Встречая ошибку, он своим "умом" стремился ее автоматически исправить и все же отправить программу на исполнение (тогда была распространена такая практика — отправлять программу на компиляцию и исполнение одним пакетом. Исполнение могло занимать многие часы). Никакой пользы от такого подхода не было, а вред был. Но это так. Понятно, что ситуация с html5 — другая.

В том-то и дело.

Если ты специфицируешь что ошибка A приводит к результату B то в результате находятся люди которые
для получения результата B будут использовать хак A.

В качестве примера:

вот erroneous markup:

<body>
  <p>One <b>two </p>
  <p>three</b> four</p>
</body>


По идее это должно парсится как-то так
<body>
  <p>One <b>two </b></p>
  <p>three four</p>
</body>


Но обработка такой ошибки должна приводить к:
<body>
  <p>One <b>two </b></p>
  <p><b>three</b> four</p>
</body>


Т.е. специфицируя "прощающую" обработку ошибок мы фактически стимулируем их появление.
Типа "оно работает — чё её фиксить?"
Re[3]: HTML5
От: fddima  
Дата: 30.08.11 19:50
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Т.е. специфицируя "прощающую" обработку ошибок мы фактически стимулируем их появление.

CS>Типа "оно работает — чё её фиксить?"
Ну это ведь лучше, чем undefined behaviour? Тем более, что и раньше многое фиксилось.
Хотя лично мне, больше по душе xhtml, но, к сожалению использовать его проблематично.
Re[4]: HTML5
От: c-smile Канада http://terrainformatica.com
Дата: 30.08.11 22:32
Оценка:
Здравствуйте, fddima, Вы писали:

F>Здравствуйте, c-smile, Вы писали:


CS>>Т.е. специфицируя "прощающую" обработку ошибок мы фактически стимулируем их появление.

CS>>Типа "оно работает — чё её фиксить?"
F> Ну это ведь лучше, чем undefined behaviour? Тем более, что и раньше многое фиксилось.

Смысл undefined behavior состоит в том что
или пиши правильный код или тестируй во всех браузерах.

Я вообще предложил в браузере показывать явно место ошибки.
Т.е. парсить все как оно есть сейчас но бить в глаз сообщением об ошибке.
В этом случае авторы будут простимулированы писать правильный markup.

Т.е. я утверждаю что undefined behavior в случае ошибки как раз лучше чем defined behavior который
фактически все ошибки переводит в класс допустимых конструкций языка. На кой тогда писать правильный markup?
Re[5]: HTML5
От: fddima  
Дата: 30.08.11 22:39
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Я вообще предложил в браузере показывать явно место ошибки.

CS>Т.е. парсить все как оно есть сейчас но бить в глаз сообщением об ошибке.
CS>В этом случае авторы будут простимулированы писать правильный markup.
Ну это правильно, хотя, как по мне ещё лучше — просто ошибка и всё, как в случае с XHTML.

CS>Т.е. я утверждаю что undefined behavior в случае ошибки как раз лучше чем defined behavior который

CS>фактически все ошибки переводит в класс допустимых конструкций языка. На кой тогда писать правильный markup?
Не знаю. Сам факт наличия спецификации для парсера — мне нравится. А то, что HTML5 не паханное поле, со спорными решениями — это факт.
Re[5]: HTML5
От: goto Россия  
Дата: 31.08.11 01:02
Оценка:
Здравствуйте, c-smile, Вы писали:

F>>Здравствуйте, c-smile, Вы писали:


CS>>>Т.е. специфицируя "прощающую" обработку ошибок мы фактически стимулируем их появление.

CS>>>Типа "оно работает — чё её фиксить?"

Так это стимулируется уже сейчас. Кто-то все это поддерживает, а кто-то за это платит. Вспоминается история про поддержку пресловутого бага SimCity в Win95, за который заплатили те, кто в SimCity никогда и не играл.

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

F>> Ну это ведь лучше, чем undefined behaviour? Тем более, что и раньше многое фиксилось.


CS>Смысл undefined behavior состоит в том что

CS>или пиши правильный код или тестируй во всех браузерах.

CS>Я вообще предложил в браузере показывать явно место ошибки.

CS>Т.е. парсить все как оно есть сейчас но бить в глаз сообщением об ошибке.
CS>В этом случае авторы будут простимулированы писать правильный markup.

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

CS>Т.е. я утверждаю что undefined behavior в случае ошибки как раз лучше чем defined behavior который

CS>фактически все ошибки переводит в класс допустимых конструкций языка. На кой тогда писать правильный markup?

Так оно уже сейчас так по факту. Упомянутый тобой язык Beta уже есть, только он у каждого свой. А это — попытка узаконить беспредел и упорядочить хаос в одном месте за счет чего-то другого — компромисс. Неизвестно, что будет. Подобных по масштабу прецедентов, насколько я понимаю, не было. Может быть, никакой лавины кривого html не будет, в этом же никто специально не заинтересован. Имхо, кодить правильно все-таки проще. Вот если пойдут хаки и трюки, которые еще и придется поддерживать — тады ой .

п.с.
Да, чуть забыл. Во всем виноват ИЕ .
Re: HTML5
От: VladD2 Российская Империя www.nemerle.org
Дата: 01.09.11 16:18
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Фактически после такой доработки ЯП Alpha получает новую грамматику в которой уже невалидные конструкции становятся

CS>как бы валидными т.е. ожидаемыми и с предсказуемыми последствиями. Т.е. на самом деле мы получили ЯП Beta в котором
CS>Alpha есть подмножество.

CS>Или как?


Ну, так. А что в этом плохого?

В принципе — это правильный подход. Реальные парсеры один фиг всегда парсят более "широкий" язык чем определено спецификацией. Введение в спецификацию этого более широкого языка приведет к лучшей совместимости и к удобству пользователей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
http://nemerle.org/Banners/?g=dark
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.