Известно что HTML5 это зонтик под которым прячется семейство технологий кроме собственно markup: video,canvas,local storage и пр.
В данном случае речь идет про markup только. По сравнению с HTML4 мы получаем в принципе две вещи:
1. Расширенный набор tags/elements. Включая дополнительный набор <input type=...>
2. Формализованные правила обработки ошибок парсером.
Собственно хочу обратить внимание на пункт #2. Как мне представляется в нем живет коллизия.
Скажем есть некий ЯП Alpha. Берем и добавляем в него правила обработки и восстановления после ошибок.
И просим всех эти правила строго выполнять.
Фактически после такой доработки ЯП Alpha получает новую грамматику в которой уже невалидные конструкции становятся
как бы валидными т.е. ожидаемыми и с предсказуемыми последствиями. Т.е. на самом деле мы получили ЯП Beta в котором
Alpha есть подмножество.
CS>Фактически после такой доработки ЯП Alpha получает новую грамматику в которой уже невалидные конструкции становятся CS>как бы валидными т.е. ожидаемыми и с предсказуемыми последствиями. Т.е. на самом деле мы получили ЯП Beta в котором CS>Alpha есть подмножество.
Всё так, только я пока что не вижу проблемы. Мы это уже проходили на примере XHTML и ничего страшного не случилось
CS>>Фактически после такой доработки ЯП Alpha получает новую грамматику в которой уже невалидные конструкции становятся CS>>как бы валидными т.е. ожидаемыми и с предсказуемыми последствиями. Т.е. на самом деле мы получили ЯП Beta в котором CS>>Alpha есть подмножество.
S>Всё так, только я пока что не вижу проблемы. Мы это уже проходили на примере XHTML и ничего страшного не случилось
Здравствуйте, 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 — другая.
G>По-моему, зависит от конкретных правил обработки (я не знаком с html5). Можно представить правила, исключающие или "урезающие" конструкции, ошибочные для Alpha. Тогда может получиться наоборот — Beta есть подмножество Alpha.
Да, я ошибся. На входе-то Beta == Alpha + ошибки => Beta > Alpha.
Здравствуйте, goto, Вы писали:
G>оффтоп G>Вспоминается старинный компилятор PL/1 на ЕС ЭВМ. Встречая ошибку, он своим "умом" стремился ее автоматически исправить и все же отправить программу на исполнение (тогда была распространена такая практика — отправлять программу на компиляцию и исполнение одним пакетом. Исполнение могло занимать многие часы). Никакой пользы от такого подхода не было, а вред был. Но это так. Понятно, что ситуация с html5 — другая.
В том-то и дело.
Если ты специфицируешь что ошибка A приводит к результату B то в результате находятся люди которые
для получения результата B будут использовать хак A.
Здравствуйте, c-smile, Вы писали:
CS>Т.е. специфицируя "прощающую" обработку ошибок мы фактически стимулируем их появление. CS>Типа "оно работает — чё её фиксить?"
Ну это ведь лучше, чем undefined behaviour? Тем более, что и раньше многое фиксилось.
Хотя лично мне, больше по душе xhtml, но, к сожалению использовать его проблематично.
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, c-smile, Вы писали:
CS>>Т.е. специфицируя "прощающую" обработку ошибок мы фактически стимулируем их появление. CS>>Типа "оно работает — чё её фиксить?" F> Ну это ведь лучше, чем undefined behaviour? Тем более, что и раньше многое фиксилось.
Смысл undefined behavior состоит в том что
или пиши правильный код или тестируй во всех браузерах.
Я вообще предложил в браузере показывать явно место ошибки.
Т.е. парсить все как оно есть сейчас но бить в глаз сообщением об ошибке.
В этом случае авторы будут простимулированы писать правильный markup.
Т.е. я утверждаю что undefined behavior в случае ошибки как раз лучше чем defined behavior который
фактически все ошибки переводит в класс допустимых конструкций языка. На кой тогда писать правильный markup?
Здравствуйте, c-smile, Вы писали:
CS>Я вообще предложил в браузере показывать явно место ошибки. CS>Т.е. парсить все как оно есть сейчас но бить в глаз сообщением об ошибке. CS>В этом случае авторы будут простимулированы писать правильный markup.
Ну это правильно, хотя, как по мне ещё лучше — просто ошибка и всё, как в случае с XHTML.
CS>Т.е. я утверждаю что undefined behavior в случае ошибки как раз лучше чем defined behavior который CS>фактически все ошибки переводит в класс допустимых конструкций языка. На кой тогда писать правильный markup?
Не знаю. Сам факт наличия спецификации для парсера — мне нравится. А то, что HTML5 не паханное поле, со спорными решениями — это факт.
Здравствуйте, 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 не будет, в этом же никто специально не заинтересован. Имхо, кодить правильно все-таки проще. Вот если пойдут хаки и трюки, которые еще и придется поддерживать — тады ой .
Здравствуйте, c-smile, Вы писали:
CS>Фактически после такой доработки ЯП Alpha получает новую грамматику в которой уже невалидные конструкции становятся CS>как бы валидными т.е. ожидаемыми и с предсказуемыми последствиями. Т.е. на самом деле мы получили ЯП Beta в котором CS>Alpha есть подмножество.
CS>Или как?
Ну, так. А что в этом плохого?
В принципе — это правильный подход. Реальные парсеры один фиг всегда парсят более "широкий" язык чем определено спецификацией. Введение в спецификацию этого более широкого языка приведет к лучшей совместимости и к удобству пользователей.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.