Ян Хиксон (Ian Hickson (http://ian.hixie.ch/)), создатель спецификации HTML 5, автор тестов Acid и соавтор спецификаций CSS, от имени сообщества WHATWG (http://www.whatwg.org/) анонсировал (http://blog.whatwg.org/html-is-the-new-html5) некоторые существенные изменения в формировании web-стандарта HTML5. Наиболее важным изменением является отказ от нумерации версий HTML - вместо HTML5 в спецификациях (http://whatwg.org/html) отныне будет просто указываться "HTML". Более того, обновления стандарта теперь будут выпускаться в непрерывном цикле, без явной фиксации версий, без предварительного тестирования черновых вариантов и проведения их публичных обсуждений.
Спецификации HTML5 отныне будут развиваться (http://wiki.whatwg.org/wiki/FAQ) поступательно и постоянно поддерживаться в актуальном виде. Сам процесс расширения спецификаций остается неизменным, так как практика непрерывного внесения изменений во внутренние документы практикуется уже несколько лет. Изменение состоит лишь в превр...URL: http://blog.whatwg.org/html-is-the-new-html5
Новость: http://www.opennet.me/opennews/art.shtml?num=29335
ИМХО правильная инициатива, потому что старперы из W3C совсем оторвались от реальности: "ожидалась в 2022 году" - это вообще нормально? Они там что, два космических корабля и атомную электростанцию попутно построят, чтоли? oO
В общем, HTML5 никогда не выйдет.
Duke Nukem Forever будет написан на HTML5
И CSS4, да!
финал HTML в 2022 - круто еще десять лет обсуждать собираются ;)))
Обратите внимание, когда появился HTML4 (и 4.01) и когда его начали полноценно применять. Я не приветствую это, но и не стоит туманить себе взор.
Скажите, что они там 11 лет делать собираются? И что делать эти 11 лет? Жить без стандарта, ой, то есть с древним HTML4.x который уже неактуален? Ну да, вот прямо сейчас все для непонятно чего притормозят прогресс на 11 лет. Аж 2 раза. В итоге благодаря W3C получается что веб по сути без стандартов. А когда в стандарте одно а по факту другое - это плохо. И если народ начинает массово забивать на стандарты и юзать еще не выпущенный стандарт - это вина стандартов и стандартизаторов, что они не устривают слишком много людй и не укладываются в разумное время. Люди устали ждать. Люди хотят HTML5. То то HTML5 стал звучным buzzword - это сигнал к тому что никакие 11 лет ждать никто не собирается. Хорошо что хотя-бы до WHATWG это дошло.
> то есть с древним HTML4.x который уже неактуален?Чем он не актуален? Что такого есть в HTML 5, без чего нельзя делать современные сайты.
<video>, WebGL. Для некоторых применений локальные БД. Или предлагается это отдать дырявым и кривым флешам и сильверлайтам? А оно надо? Если кто-то пытается сгородить надстройку над веб, значит, вероятно, в основной части стандарта чего-то не хватило.
Все, что вы перечислили, кроме тэга <video>(Который везде реализован уже), добавили в стандарт в последние несколько лет. А браузеры уже успели устареть без этого? :DИ да, если вы не в курсе, стандарт заклепляют, когда большинство из него успели реализовать в бразерах.
Не все делают статические "сайты". Люди еще делают веб приложения.
Ну и чего вам конкретно для Web-приложений не хватает в современной редакции DOM/HTML/JS?
в зависимости от конкретики приложения может не хватать повсемесной работы <canvas>, <video>, <audio>, WebGL, работы с микрофоном, работы с видеокамерой, WebSocket, localStorage, работы с upload-файлами из js, c сенсорами наклона устройства на котором запущен браузер.
Вот "сенсорами наклона устройства на котором запущен браузер" особо актуально.
чувствуется, полезные приложения будут )))
Заголовок мне чем-то напоминает анекдот про третий этап завершения окончания продолжения установки MS Office.
>без предварительного тестирования черновых вариантов и проведения их публичных обсужденийЭто как? Типа сегодня добавили, завтра все поюзали, послезавтра кучу баг нашли?
Нет, это сегодня разметку сделал чистую по спекам, а завтра валидатор в ней 100 ошибок нашёл.
Тосто. HTML4 с 1997 года.
"Обратная совместимость", знаешь такую?
Сегодня написал, прошёл валидатор, и через неделю прошёл валидатор, но при этом можно добавить пару фич и снова пройти без ошибок.
> а завтра валидатор в ней 100 ошибок нашёл.а этот сделанный сайт -- он тоже валидатором будет открываться?
...или же всётакие браузерами? (которые будут поддерживать не только HTML5-current , но и HTML5-legacy )
> а этот сделанный сайт -- он тоже валидатором будет открываться?
> ...или же всётакие браузерами? (которые будут поддерживать не только HTML5-current , но
> и HTML5-legacy )А если разработчик браузера пропустил (не успел реализовать) какие-то HTML5-legacy фичи? Где он прочитает о них и как узнает что что-то пропустил?
Ждем новой серии "W3C наносит ответный удар" и запасаемся попкорном конечно.
Бешенными темпами, что-то не очень заметно, супертехнология флэша так и доминирует на просторах, ie9 после истории с прохождением тестов, логично бы допилить до какого-нить нормального результата, фф собирается и на qt портироваться и оптимизироваться под gl, опере после перехода с qt, стабильности бы поднабраться, им похоже скучно стало, теперь опять каждый вендор на себя одеяло тянуть будет..
> Бешенными темпами, что-то не очень заметно,Да, а всякие там базы данных в браузере, вебсокеты, webgl, <video>, геолокационные сервисы и что я там еще забыл - это совсем такие медленные и незначительные темпы.
Все перечисленное и было основой html5, которую пытались стандартизировать, и кстате так и стандартизировали, html5 мог стать чертой, между старыми и новыми браузерами, какому-нить там kernel.org эти навороты нифиг не упали, а новые ресурсы могли бы ограничится только поодежкой html5, выгодно было всем, производителям браузеров еще раз пропиарится, ie10, opera12. Уже существующим сайтам и интернет проектам стрясти денег с инвесторов, новым не заморачиваться на поддержку мамонтов, в итоге вместо if(window.supportHTML5), получим портянку из 200-т строк кода, с определением поодерживает ли браузер, видео, а какой формат, и бла-бла-бла, jquery распухнет еще сильнее, и его копировалие каждому пользователю увеличит трафик, в сущности не нужный, зато эти товарищи сняли с себя всякую ответственность, и устранились от решения чьи стандарты принять, тем самым избежав судебных исков и критики, страусы долбанные.
> получим портянку из 200-т строк кода, с определением поодерживает ли браузер, видео, а какой формат, и бла-бла-бла, ...вообщето когда делаешь какоето www-приложение -- то ты [при НЕУВЕРЕННОСТИ наличия/отсутствия определённой функции] (в случае когда оно предполагает открываться на РАЗНЫХ реализациях www-броузеров) просто ОБЯЗАН проверить поддерживается ЭТА функция
и проверять ты должен ИМЕННО "спорную" ФУНКЦИЮ , а НЕ какуюто ОБЩУЮ абстракцию (такую как "ааа... значит мы работает в Фурефоксе -- значит всё будет в порядке....")
(хотя -- это можно и не проверять (а просто использовать будтобы они точно поддерживаются) .. если предпологается что "будет используется ТОЛЬКО самый современный броузер" , или если "будет использоваться ТОЛЬКО <определённый> броузер с <такойто> версией" ... но в остальных случаях ПРОВЕРКА БЫТЬ ОБЯЗАНА и причём именно ДЕТАЛЬНОЙ)
...
> в итоге вместо if(window.supportHTML5)
что-то в моём Firefox-4.0-b8 -- переменная "window.supportHTML5" равна <undefined> ... не скажешь интересно же почему это?
а если некий броузер поддерживает HTML4.01 не на 100% а на 99.999999% -- то чему же по-вашему-домыслу должна быть равна переменная window.supportHTML401 ???
перестаньте думать что мир монохромно-чёрнобелый (думать что -- "HTML-version-X.Y" либо поддерживается <чемто> полностью, либо не поддерживается совсем) ..
спецификации нужны не для того чтобы разработчики им следовали на 100% .. а для того чтобы не было ЯВНЫХ разхождений у разработчиков в понимании того или иной сущности
> перестаньте думать что мир монохромно-чёрнобелый (думать что -- "HTML-version-X.Y" либо поддерживается <чемто> полностью, либо не поддерживается совсем) ..Это не означает, что к этому не надо стремиться.
> спецификации нужны не для того чтобы разработчики им следовали на 100% .. а для того чтобы не было ЯВНЫХ разхождений у разработчиков в понимании того или иной сущности
Они нужны для того, чтобы сайты выглядели и работали одинаково во всех браузерах, поддерживающих данные стандарты. И чтобы веб-разработчикам не нужно было для этого вставлять кучу проверок на все случаи жизни (в идеале они вообще не должны делать никаких проверок).
> вообщето когда делаешь какоето www-приложение -- то ты ... просто ОБЯЗАН проверить поддерживается ЭТА функция
И чем больше таких проверок я вставлю в код, тем больше мне заплатит работодатель (считай - деньги в трубу, т.к. никакой функциональности это не прибавит) и тем сильнее будут тормозить браузеры посетителей.
>> перестаньте думать что мир монохромно-чёрнобелый (думать что -- "HTML-version-X.Y" либо поддерживается <чемто> полностью, либо не поддерживается совсем) ..
> Это не означает, что к этому не надо стремиться.нет.. к этом не надо стремиться... это как "ссать против ветра"...
...мир никогда не станет чорнобелым -- и вы должны смеритсья с этим ... так как "монохромная-чорнобелость" -- это ПРОТИВОЕСТЕСТВЕННО
> И чтобы веб-разработчикам не нужно было для этого вставлять кучу проверок на все случаи жизнитык -- надо сразу определить для себя (как разработчика) -- "насколько старые www-броузеры мы будем рассматривать как поддерживаемые для нашего www-проекта?"
например если мы берём период "1 год" -- то значит должны учитывать наиболее популярные реализации www-стандарта -- ТОЛЬКО в течении 1 года
а если мы (как разработчики) решили взять на себя обазянность реализовать ту или иную функциональность с учотом дравности обратной совместимости "5 лет" -- то тут КОНЕШНОже не обойтись без "кучу проверок на все случаи жизни"
однако спросите себя -- ну зачем вам эти 5 лет? "пол года" это вполне нормальный срок (+ ещё пол года уйдёт на разработку www-программы -- в итоге выйдет 1 год обратной совместимости)
....за эти прошедшии "пол года" никаких координальный изменений www-стандарта не происходит... и поэтому количество "спорных" функциональностей остаётся очень не много
(но какой бы срок-обратной-совместимости мы не взяли -- сёравно проверять нужно именно ИНДЕВИДУАЛЬНО "спроные функции" ("спорные" за этот период) а не "обобщённые абстракции функциональности... такие как .. поддерживает ли броузер HTML5 или нет")
> И чем больше таких проверок я вставлю в код, тем больше мне заплатит работодатель (считай - деньги в трубу, т.к. никакой функциональности это не прибавит) и тем сильнее будут тормозить браузеры посетителей.в программе (и в www-программе тоже) -- не всё определяется параметром "функциональность"
...хотя именно параметр "функциональность" обычно только и бросается в глаза :-)
есть ещё такие параметры как "совметимость" и "надёжность" (и другие параметры тоже....)... если разработчик потратил деньги работодателя (на "совместимость" и "надёжность") и никто не увидил результат его трудов -- то это конешно печально...
.....именно поэтому проприетарщики и коммерсанты стараются меньше уделять внимание на "совместимость" и "надёжность" -- так как сёравно это не бросается в глаза (и в результате какбы "деньги в трубу")
> ...и тем сильнее будут тормозить браузеры посетителей.для того чтобы броузеры сильно не тормазили -- КОНЕШНОже необходимо держать www-программу в актуальном виде
..это значит в том числе и то -- что когда появляются более новые сущности в www-стандарте, а другие сущности устаревают -- то мы всегда должны помнить какой период-обратной-совместимости был выбран для нашей программы
....и РАЗУМЕЕТСЯ необходимо время-от-времени удалять из www-программы код связанный с той обратной совместимостью которая уже вышла за временной-предел нашей поддержки
зачастую разработчикам просто жалко удалять "чрезмерно устаревший код" (некоторые разработчики попросту могут забыть о том что не "количество написанных строчек" является результатом труда разработчика -- а "хорошо работающщий модуль") .. или они не могут найти на это время...
Ой, как много буков и всё не по существу. Даже поспорить не с чем.
Удалять код и тем самым ломать совместимость с чем-то...оправдано в некоторых исключительных случая, коим html ни как не является, 1 год, то есть, имея проект, не зависимо от его объема команда разработчиков должна каждый год его переписывать.Вы видимо не имеете ни малейшего представления об абстракциях.
> Удалять код и тем самым ломать совместимость с чем-то...оправдано в некоторых исключительных случая, коим html ни как не является, 1 год, то есть, имея проект, не зависимо от его объема команда разработчиков должна каждый год его переписывать.к сожелению ничего не поня в этом предложении :-( :-(
...попробуйте кроме зяпятых ещё и другие знаки припенания поставить (точки, например)... ато как "казнить, нельзя, помиловать" получилось :-( :-(
> Вы видимо не имеете ни малейшего представления об абстракциях.
уровень абстракции -- в своих проектах можете делать какой хотите... но однако -- это никак не отменит сказанного мной :-)
вся разницца будет только в том -- какие файлы придётся редактировать (для поддержания проекта в актуальном состоянии относительно HTML5-current) ...
> >> перестаньте думать что мир монохромно-чёрнобелый (думать что -- "HTML-version-X.Y" либо поддерживается <чемто> полностью, либо не поддерживается совсем) ..
> > Это не означает, что к этому не надо стремиться.
> нет.. к этом не надо стремиться... это как "ссать против ветра"...
> ...мир никогда не станет чорнобелым -- и вы должны смеритсья с этим ... так как "монохромная-чорнобелость" -- это ПРОТИВОЕСТЕСТВЕННОчЁрно-белым мир может и не станет. Только ничего естественного в языках программировая нет, если уж суд классифицирует деяния человека, то идеализировать html сможет даже сопливый школьник.
> вместо if(window.supportHTML5), получим портянку из 200-т строк кода, с определением поодерживает ли браузер, видео, а какой формат, и бла-бла-бларазмечтался, никакого if(window.supportHTML5) никогда бы не было ни при каком наименовании HTML.
HTML5 - это пиар имя для большого набора стандартов, которые браузеры реализуют постепенно, год за годом, в разных версиях. Твои пожелания-мечты сделать все сразу в одной версии никто исполнять не будет.
> распухнет еще сильнее, и его копировалие каждому пользователю увеличит трафик, в сущности не нужный
Такова жизнь.
> Такова жизнь.Вот именно такие мысли сопровождают молчаливое согласие и пускают дело на самотек.
и будет как в винде: API d'jour
> и будет как в винде: API d'jourа как в венде (с этим неким "d'jour")...? можете хотяб дать ссылку на то что такое "d'jour" ?
translate.google.com
Мне кажется, что возмущающиеся здесь не совсем правильно поняли идею. Упоинание про 2022 год написано как допущение в будущее, которое могло бы быть.Новость о том, что автор HTML5 пришел к rolling-release. Эта модель все более популяризуется. Есть схема, когда народ потеет над релизом, дата которого все ближе и ближе. А есть те, кто сделал фичу - протестировал - выбросил в релиз. И далее по накатанной. В данном случае это хорошо, потому что схема release plan замедляет прогресс для таких основных вещей, как HTML5 (и не только).
Всё-таки хорошо бы этим rolling-релизам ещё и циферки присваивать, а то может получиться что каждый браузер будет поддерживать свой набор от общего стандарта, а пересекающихся фич окажется не очень-то и много. И что толку от такого стандарта?
Всё-таки с циферками легче было бы приостановить внедрение новых возможностей и кинуть силы на то, что пропустили (ради объявления что "браузер X полностью поддерживает HTML Y.Z").
> Всё-таки с циферками легче было бы приостановить внедрение новых возможностей и кинуть
> силы на то, что пропустили (ради объявления что "браузер X полностью
> поддерживает HTML Y.Z").это хорошо только по началу (до тех пор пока этих X.Y не накопитсья больше 20~100 штук .. а как накопиться -- можете представить себе что начнётся?)...
заглянем в гипотетическое (такое) будущее:
вот предположим вышел HTML-5.01 (и броузеры объявляют о том что они поддерживают HTML501)
потом выходит HTML-5.02 (и соотсвтетственно поддержка броузеров -- window.supportHTML502)..., HTML-5.03, HTML-5.04, HTML-5.05, HTML-5.06, HTML-5.07, ... HTML-5.25, HTML-5.26, ...
в новых HTML-5.2X -- допустим появляется (а подругому быть и НЕ МОЖЕТ) какието новые абстракции которые в свою очередь приводят к тому что другие абстракции становятся устаревшими...
(но броузеры как и пологается (в отличии от стандартов) имеют некую обратную совместимость и поддерживают оба набора сущностией -- и HTML-5.05 и HTML-5.25 )
...потом выходят HTML-5.50 .. и опять набор новых сущностей ..(опять старые некоторые сущности устаревают)
...
и тут разработчикам броузеров приходит мысль в голову что они не могут обеспечивать обратную совместимость СОВСЕМ-уже-старым сущностям (когда они протеворечат с новой моделью стандарта HTML-5.50)....
и потехоньку эти сущности необходимо удалять
и вот тут вопрос -- КАК же быть тогда разработчиком броузеров с "декларированием поддержки" ?
некое ранее-актуальное window.supportHTML502 -- уже не правда ... и возможно эту декларацию тоже надо удалить .... но кто знает какие это вызовет последствия для старых сайтов?
(кто знает через какую извращённую схему те или иные сайты проверяются относительно window.supportHTML5XX-параметра!!!?)
...и опятьже -- как выявить все регрессии для ЧРЕЗМЕРНО-УСТАРЕВШИХ стандартов?
и где найти тесты для чрезмерно устаревших стандартов?
а какой смысл заниматься этой очень КРОПОТЛИВОЙ работой?
...ведь у тесторов и без этого много дел, кроме как тестирование броузера на предмет поддержки-или-не-поддержки чрезмерно-устаревших стадартов* * *
во много раз прощще ВСЕМ (в том числе и разработчикам www-приложений, а не только разработчикам www-броузеров) -- не декларировать броузерам о том какую версию стандарта они поддерживают... а декларировать о своих возможностях детально (например декларировать о том что "может ли броузер играть видио-файлы.. и какие форматы он поддерживает для этого")
...при этом каждая сторона (и разработчик www-приложения и разработчик www-броузера) будут стараться чтобы их продукты были как-можно-более не противоречивее относительно current-стандарта ...
цыфра-стандарта в этом деле только помешает (создаст дополнительную путанницу, добавит порцию кретинических случаев -- когда когда www-приложение использует совсем не те функции (не эффективные) которые могла-бы использовать -- только изза того что оно "подумало" что эти функции не работают.
...а может быть и ещё хуже ситауция -- например табличка о том что "ваш броузер устарел! www-программа не запуститься! установите более новую версию" на самом новейшем броузере)
Опять много буков не по существу, но попробую ответить.
> это хорошо только по началу (до тех пор пока этих X.Y не
> накопитсья больше 20~100 штук .. а как накопиться -- можете представить
> себе что начнётся?)...И куда делись ваши размышления о нужности поддержки только актуальных браузеров?
> в новых HTML-5.2X -- допустим появляется (а подругому быть и НЕ МОЖЕТ)
> какието новые абстракции которые в свою очередь приводят к тому что
> другие абстракции становятся устаревшими...А, так вот где отправная точка всех ваших домыслов!
Нет, HTML развивается по пути добавления новых возможностей, старые абстракции не устаревают и по-прежнему выполняют свои функции. И пока что нет оснований сомневаться в том, что так будет и впредь.Дальше не цитирую, т.к. идёт длиннющая цепочка заключений на основе ложных предпосылок.
> цыфра-стандарта в этом деле только помешает (создаст дополнительную путанницу, добавит
> порцию кретинических случаев -- когда когда www-приложение использует совсем не те
> функции (не эффективные) которые могла-бы использовать -- только изза того что
> оно "подумало" что эти функции не работают.Цифры ничему не помешают и не помогут. Это всего-лишь milestones для удобства отсчёта. Приведу показательный пример: http://htmlbook.ru/css/display - из 16 возможных значений полностью сегодня можно применять только 4. И дело тут не в мифических устаревших абстракциях и не в проверках, а тупо в том что браузеры без реализации всех возможностей стандарта css2(!) всё ещё в ходу. Так вот, я за то, чтобы FF и Safari уже остановились наконец в гонке за постоянно ускользающим html5, и реализовали-таки полностью весь(!) стандарт css2.1
>> в новых HTML-5.2X -- допустим появляется (а подругому быть и НЕ МОЖЕТ)
>> какието новые абстракции которые в свою очередь приводят к тому что
>> другие абстракции становятся устаревшими...
> А, так вот где отправная точка всех ваших домыслов!
> Нет, HTML развивается по пути добавления новых возможностей, старые абстракции не устаревают
> и по-прежнему выполняют свои функции. И пока что нет оснований сомневаться
> в том, что так будет и впредь.Ложь. Самый наглядный пример: http://www.w3.org/TR/html5/obsolete.html
> Ложь. Самый наглядный пример: http://www.w3.org/TR/html5/obsolete.htmlНу хорошо, согласен, некоторые сущности всё-таки устаревают. Но это всегда контролировалось объявлением DOCTYPE с номером версии стандарта.
Производителям браузеров не нужно удалять поддержку устаревших сущностей, им достаточно переключить движок в зависимости от этого доктайпа. Отсутствие же номера версии действительно может внести бардак во всё это.
> Производителям браузеров не нужно удалять поддержку устаревших сущностей, им достаточно
> переключить движок в зависимости от этого доктайпа.по мере увеличения количества таких вот движков -- разработчикам придётся отлаживать каждый такой движок индивидуально..
(ведь у каждого движка будет индивидуальная кодовая база (c пересечениями, разумеется, но сёравно) и индивидуальные баги )никто из разработчиков броузров -- не захочет взять на себя такой титанический труд (с учотом того что все движки кроме последнего -- не перспективны)
для разработчиков броузеров намного прощще -- поддерживать в актуальном виде только один www-стандарт .
> Отсутствие же номера версии
> действительно может внести бардак во всё это.какойже тут бордак -- когда в любой момент можно открыть CURRENT-спецификацию да и посмотреть спорные моменты :-) :-)
> по мере увеличения количества таких вот движков -- разработчикам придётся отлаживать каждый
> такой движок индивидуально..А старые зачем отлаживать? Они уже давно отлажены.
> никто из разработчиков броузров -- не захочет взять на себя такой титанический
> трудПрежде всего они не захотят, чтобы в их новых браузерах перестало работать половина интернета.
>> Отсутствие же номера версии
>> действительно может внести бардак во всё это.
> какойже тут бордак -- когда в любой момент можно открыть CURRENT-спецификацию да
> и посмотреть спорные моменты :-) :-)Вы предлагаете веб-разработчикам каждый день заглядывать в CURRENT-спецификации и исправлять все свои работы из портфолио?
>> по мере увеличения количества таких вот движков -- разработчикам придётся отлаживать каждый
>> такой движок индивидуально..
> А старые зачем отлаживать? Они уже давно отлажены.Вы наивны до невозможности. Во-первых, отлаженными они точно не будут, они могут быть лишь приемлемо работоспособными.
Во-вторых, всё равно будут иметь место какие-то изменения внутренней архитектуры по мере развития каждого браузера — просто оптимизации, улучшения юзабилити, поддержка каких-то дополнительных стандартов...
В-третьих, просто дорабатываться они тоже будут — в этом треде уже упоминалось, что CSS 2.1 полностью не поддерживается ни одним браузером (что, кстати, свидетельствует не только и не столько о лени программистов, сколько о сложности реализации отдельных элементов стандарта).
>> никто из разработчиков броузров -- не захочет взять на себя такой титанический
>> труд
> Прежде всего они не захотят, чтобы в их новых браузерах перестало работать
> половина интернета.Вы забыли один тонкий момент. Половина интернета тоже не захочет, чтобы она перестала работать в новых браузерах. И будет в свою очередь подстраиваться. Выживает самый гибкий — как с одной, так и с другой стороны.
>>> Отсутствие же номера версии
>>> действительно может внести бардак во всё это.
>> какойже тут бордак -- когда в любой момент можно открыть CURRENT-спецификацию да
>> и посмотреть спорные моменты :-) :-)
> Вы предлагаете веб-разработчикам каждый день заглядывать в CURRENT-спецификации и исправлять
> все свои работы из портфолио?Полностью согласен.
> Вы наивны до невозможности. Во-первых, отлаженными они точно не будут, они могут
> быть лишь приемлемо работоспособными.Не надо буквоедства. Естественно я имел ввиду только то, что под этим движком вчерашний интернет прекрасно работал, а новые сайты всё-равно будут делать по новым стандартам и их можно рендерить новым движком.
> Во-вторых, всё равно будут иметь место какие-то изменения внутренней архитектуры по мере
> развития каждого браузера — просто оптимизации, улучшения юзабилити, поддержка
> каких-то дополнительных стандартов...Ну естественно будут - в новом движке, из которого можно смело убрать те вещи, которые устарели ещё с принятием HTML4.0 Transitional.
> В-третьих, просто дорабатываться они тоже будут — в этом треде уже упоминалось,
> что CSS 2.1 полностью не поддерживается ни одним браузеромДа я только ЗА. Пусть доработают (только в новом движке или без разделения, мне без разницы), но только пусть сделают это сейчас, а не когда он уже устареет.
> (что, кстати,
> свидетельствует не только и не столько о лени программистов, сколько о
> сложности реализации отдельных элементов стандарта).А вот тут не согласен. 'display:run-in' реализовать гораздо легче того же API IndexedDB, в IE это работает начиная с IE8 и только ФФ с сафари тормозят прогресс. Дело только в приоритетах.
>> Прежде всего они не захотят, чтобы в их новых браузерах перестало работать
>> половина интернета.
> Вы забыли один тонкий момент. Половина интернета тоже не захочет, чтобы она
> перестала работать в новых браузерах. И будет в свою очередь подстраиваться.Этого не захочет только первая половина, а остальные вполне могут и забить (по разным причинам) на такой браузер. И в первую очередь на него забьют пользователи.
> Выживает самый гибкий — как с одной, так и с другой стороны.
Что-то мне подсказывает, что при таком сценарии проиграют все. И ведь проблема создана искусственно на пустом месте, верните назад версии стандарта и всё вернётся на свои места.
>> Вы предлагаете веб-разработчикам каждый день заглядывать в CURRENT-спецификации и исправлять
>> все свои работы из портфолио?
> Полностью согласен.С чем? Это был вопрос :)
>> Вы наивны до невозможности. Во-первых, отлаженными они точно не будут, они могут
>> быть лишь приемлемо работоспособными.
> Не надо буквоедства. Естественно я имел ввиду только то, что под этим
> движком вчерашний интернет прекрасно работал, а новые сайты всё-равно будут делать
> по новым стандартам и их можно рендерить новым движком.Допустим. С такой формулировкой согласен (правда, почему нельзя было сразу ей воспользоваться?.. Ну да ладно)
>> Во-вторых, всё равно будут иметь место какие-то изменения внутренней архитектуры по мере
>> развития каждого браузера — просто оптимизации, улучшения юзабилити, поддержка
>> каких-то дополнительных стандартов...
> Ну естественно будут - в новом движке, из которого можно смело убрать
> те вещи, которые устарели ещё с принятием HTML4.0 Transitional.Не-не-не, вы не так поняли: я говорю про изменения, которые будут касаться кода браузера в самых неожиданных (для вас сейчас) местах, и не обязательно вообще касаться реализации собственно HTML- или CSS-спецификации. Например, отдельным промышленном стандартом станет такое: при двойном щелчке на слове появляется меню, в котором, помимо всего прочего, есть перевод слова на язык пользователя. Причём должен быть доступ к такому тултипу через DOM. Представили? Хорошо. :)
>> В-третьих, просто дорабатываться они тоже будут — в этом треде уже упоминалось,
>> что CSS 2.1 полностью не поддерживается ни одним браузером
> Да я только ЗА. Пусть доработают (только в новом движке или без
> разделения, мне без разницы), но только пусть сделают это сейчас, а
> не когда он уже устареет.Так в том-то и дело, что доработку те же самые пользователи будут требовать для всех движков. Вспомните, сколько сайтов в своё время прекрасно обходились без DOCTYPE или честно признавались, что они поддерживают спецификацию 3.2 — что, CSS 2.1 должен был пройти мимо них?
>> (что, кстати,
>> свидетельствует не только и не столько о лени программистов, сколько о
>> сложности реализации отдельных элементов стандарта).
> А вот тут не согласен. 'display:run-in' реализовать гораздо легче того же API
> IndexedDB, в IE это работает начиная с IE8 и только ФФ
> с сафари тормозят прогресс. Дело только в приоритетах.Знаете, в таких случаях моя бывшая девушка, один из самых замечательных людей на этом свете, любила повторять: «Если ты такой умный, то почему строем не ходишь?» ;)
API IndexedDB, кстати, само по себе реализовать как раз не так сложно, по одной простой причине: оно не особо завязано горизонтальными связями с другими сущностями. А именно горизонтальные связи создают головную боль в программировании, именно они — причина стремления многих проектов к модульности — чтобы естественным образом стараться таких связей избежать.
Для реализации IndexedDB достаточно: 1) Взять какой-нибудь BDB, или сваять (если нечего делать) свой; 2) Добавить соответствующие интерфейсы в DOM. Эта операция по сложности примерно аналогична написанию расширения для FireFox, может, даже проще.
А вот при реализации run-in необходимо учитывать множество подводных камней, связанных как с требованиями самого CSS, так и с особенностями внутренней архитектуры каждого конкретного браузера.
>>> Прежде всего они не захотят, чтобы в их новых браузерах перестало работать
>>> половина интернета.
>> Вы забыли один тонкий момент. Половина интернета тоже не захочет, чтобы она
>> перестала работать в новых браузерах. И будет в свою очередь подстраиваться.
> Этого не захочет только первая половина, а остальные вполне могут и забить
> (по разным причинам) на такой браузер. И в первую очередь на
> него забьют пользователи.Уверяю вас, хоязева подавляющего большинства сайтов (особенно если считать учитывать «вес» в виде популярности оных) ОЧЕНЬ не хотят терять свою аудиторию на пустом месте.
>> Выживает самый гибкий — как с одной, так и с другой стороны.
> Что-то мне подсказывает, что при таком сценарии проиграют все. И ведь проблема
> создана искусственно на пустом месте, верните назад версии стандарта и всё
> вернётся на свои места.Каком сценарии? Я всего лишь рассказал вам о том, что есть много разных, так или иначе уравновешивающих друг друга сил. Точка равновесия плавает со временем, конечно, так как на эту систему постоянно что-то действует: рост популярности Flash, распространение Linux, взрыв популярности соцсетей и сетевого видео и т.д.
>>> Вы предлагаете веб-разработчикам каждый день заглядывать в CURRENT-спецификации и исправлять
>>> все свои работы из портфолио?
>> Полностью согласен.
> С чем? Это был вопрос :)Ещё скажите, что он был не риторический :-D
> Не-не-не, вы не так поняли: я говорю про изменения, которые будут касаться
> кода браузера в самых неожиданных (для вас сейчас) местах, и не
> обязательно вообще касаться реализации собственно HTML- или CSS-спецификации.Пусть об этом голова болит у разработчиков браузеров. К вопросу о необходимости нумерации стандартов это никак не относится.
> Так в том-то и дело, что доработку те же самые пользователи будут
> требовать для всех движков. Вспомните, сколько сайтов в своё время прекрасно
> обходились без DOCTYPE или честно признавались, что они поддерживают спецификацию 3.2
> — что, CSS 2.1 должен был пройти мимо них?Он уже прошёл мимо них. Сайты, разработанные в те давние времена, сегодня уже не будут ничего требовать. Они уже были созданы с учётом реалий того времени и реализация чего-то дополнительно на них никак не скажется. Лишь бы из старого ничего не сломалось.
> А вот при реализации run-in необходимо учитывать множество подводных камней, связанных
> как с требованиями самого CSS, так и с особенностями внутренней архитектуры
> каждого конкретного браузера.Хорошо, допустим что API IndexedDB приделать гораздо легче. Но с принятия CSS2 уже сколько времени прошло? Уже 10 раз можно было переписать внутреннюю архитектуру, если не гнаться за новомодными фичами (которые придуманы только вчера, их легче приделать, но которые всё-равно повсеместно ещё не скоро будут применяться).
> Уверяю вас, хоязева подавляющего большинства сайтов (особенно если считать учитывать «вес»
> в виде популярности оных) ОЧЕНЬ не хотят терять свою аудиторию на
> пустом месте.Это понятно, что "большинства из популярных". С остальными что делать предлагаете? Держать для них дополнительно старую версию браузера? Пока я вижу только проблемы, созданные на пустом месте.
> Каком сценарии? Я всего лишь рассказал вам о том, что есть много
> разных, так или иначе уравновешивающих друг друга сил. Точка равновесия плавает
> со временем, конечно, так как на эту систему постоянно что-то действует:
> рост популярности Flash, распространение Linux, взрыв популярности соцсетей и сетевого
> видео и т.д.Как всё это связано с желанием нормально видеть в своём браузере все сайты, независимо от их популярности, желаний и возможностей (на данный момент) их хозяев?
>>>> Вы предлагаете веб-разработчикам каждый день заглядывать в CURRENT-спецификации и исправлять
>>>> все свои работы из портфолио?
>>> Полностью согласен.
>> С чем? Это был вопрос :)
> Ещё скажите, что он был не риторический :-DТогда к чему вся эта риторика про "выживает самый гибкий" и "не хотят терять свою аудиторию"?
>> Не-не-не, вы не так поняли: я говорю про изменения, которые будут касаться
>> кода браузера в самых неожиданных (для вас сейчас) местах, и не
>> обязательно вообще касаться реализации собственно HTML- или CSS-спецификации.
> Пусть об этом голова болит у разработчиков браузеров. К вопросу о необходимости
> нумерации стандартов это никак не относится.Чем больше головной боли у разработчиков, тем больше глюков у пользователей. Закон Фост... тьфу, жизни. :) Вы предлагаете увеличить объём работы программистов ради некоего идеала. А ничего, что эти программисты будут заниматься непродуктивным делом вместо того, чтобы (например) реализовывать нужные вам функции? Или, может, это вы спонсируете хотя бы процетов на 30 разработку одного из популярных браузеров, или хотя бы их движков?
>> Так в том-то и дело, что доработку те же самые пользователи будут
>> требовать для всех движков. Вспомните, сколько сайтов в своё время прекрасно
>> обходились без DOCTYPE или честно признавались, что они поддерживают спецификацию 3.2
>> — что, CSS 2.1 должен был пройти мимо них?
> Он уже прошёл мимо них. Сайты, разработанные в те давние времена, сегодня
> уже не будут ничего требовать. Они уже были созданы с учётом
> реалий того времени и реализация чего-то дополнительно на них никак не
> скажется. Лишь бы из старого ничего не сломалось.То есть вы предлагаете искусственно создать дополнительные барьеры совместимости? Шикарно. И этот человек запрещает мне ковыряться в носу... :)
>> А вот при реализации run-in необходимо учитывать множество подводных камней, связанных
>> как с требованиями самого CSS, так и с особенностями внутренней архитектуры
>> каждого конкретного браузера.
> Хорошо, допустим что API IndexedDB приделать гораздо легче. Но с принятия CSS2
> уже сколько времени прошло? Уже 10 раз можно было переписать внутреннюю
> архитектуру, если не гнаться за новомодными фичами (которые придуманы только вчера,
> их легче приделать, но которые всё-равно повсеместно ещё не скоро будут
> применяться).Так, может, и ценность run-in вами несколько преувеличена? Повторюсь, вы хотя бы код одного из современных браузеров видели? Представляете себе, что это такое? Очень легко сказать, как несложно что-то сделать. Докажите делом. Код Webkit и FireFox открыт, если чо. Жду ваших патчей, можно прямо здесь.
>> Уверяю вас, хоязева подавляющего большинства сайтов (особенно если считать учитывать «вес»
>> в виде популярности оных) ОЧЕНЬ не хотят терять свою аудиторию на
>> пустом месте.
> Это понятно, что "большинства из популярных". С остальными что делать предлагаете? Держать
> для них дополнительно старую версию браузера? Пока я вижу только проблемы,
> созданные на пустом месте.Вовсе нет. Делается нормальными людьми всё примерно так: HTML-ка скармливается символ за символом парсеру, который строит некое дерево объектов. Как это дерево выглядит — личное дело каждого браузера, хотя обычно оно (для простоты создания интерфейсов) более-менее соответствует одной из спецификаций DOM. В процессе постройки могут вызываться какие-то дополнительные обработчики (скажем, по мере встреч c элементами SCRIPT). Парсеров может быть несколько, или у него могут быть какие-то внутренние переключатели режимов, но внутреннее представление — единое. Благодаря этому можно так же пользоваться единым рендером (обработка CSS-указаний), единым скриптовым движком и т.д.
Вы предлагаете размножить сущности, сделав кучу комплектов "внутреннее представление + рендер" (на каждую комбинацию версии HTML + версии CSS — хвала богам, для последних нынче достаточно обойтись CSS 2.1 и CSS 3); допустим, что скриптовой движок будет один. Так вот, вы представляете себе, сколько это принесёт с собой геморроя? Нет? Тогда говорить больше не о чем, мы слишком по-разному видим проблему.
>> Каком сценарии? Я всего лишь рассказал вам о том, что есть много
>> разных, так или иначе уравновешивающих друг друга сил. Точка равновесия плавает
>> со временем, конечно, так как на эту систему постоянно что-то действует:
>> рост популярности Flash, распространение Linux, взрыв популярности соцсетей и сетевого
>> видео и т.д.
> Как всё это связано с желанием нормально видеть в своём браузере все
> сайты, независимо от их популярности, желаний и возможностей (на данный момент)
> их хозяев?Так, что оное желание — лишь одна из упомянутых выше сил.
>>>>> Вы предлагаете веб-разработчикам каждый день заглядывать в CURRENT-спецификации и исправлять
>>>>> все свои работы из портфолио?
>>>> Полностью согласен.
>>> С чем? Это был вопрос :)
>> Ещё скажите, что он был не риторический :-D
> Тогда к чему вся эта риторика про "выживает самый гибкий" и "не
> хотят терять свою аудиторию"?Эм. Вы это серьёзно спрашиваете???
> Чем больше головной боли у разработчиков, тем больше глюков у пользователей. Закон
> Фост... тьфу, жизни. :)"выживает самый гибкий" (c) ваш.
> То есть вы предлагаете искусственно создать дополнительные барьеры совместимости?
Чего? Да я тут уже несколько дней пытаюсь вам объяснить как важно сохранить совместимость со старыми сайтами.
Это вы здесь рассказываете мне сказки о недостижимости идеала, как программистам сложно, как выживает самый гибкий и как все подорвутся исправлять давно работающие сайты, чтобы они и в новых браузерах работали не хуже.> Шикарно. И этот человек запрещает мне ковыряться в носу... :)
Да ковыряйтесь где хотите, мне-то какое дело?
> Так, может, и ценность run-in вами несколько преувеличена? Повторюсь, вы хотя бы
> код одного из современных браузеров видели? Представляете себе, что это такое?
> Очень легко сказать, как несложно что-то сделать. Докажите делом. Код Webkit
> и FireFox открыт, если чо. Жду ваших патчей, можно прямо здесь.http://lurkmore.ru/Сперва_добейся ??
Я не программист. Мне достаточно того факта, что даже в ИЕ это уже сделали (без лишних соплей и воплей об архитектуре движка). И дело тут не в ценности run-in, а в подходе к значимости стандартов: если каждый разработчик браузера будет сам решать какие вещи в стандарте ценные, а какие нет - мы рискуем вернуться во времена, когда сайты были IE-only и Netscape-only.> Вы предлагаете размножить сущности, сделав кучу комплектов "внутреннее представление
> + рендер" (на каждую комбинацию версии HTML + версии CSS —
> хвала богам, для последних нынче достаточно обойтись CSS 2.1 и CSS
> 3); допустим, что скриптовой движок будет один.Не надо перевирать мои слова, я говорил лишь о двух движках: старом, включающим в себя HTML4.* и всё что было раньше, и новом, включающим в себя HTML4.* и всё что выше. Новый включается только с доктайпом html5. Никаких комбинаций не надо, css входит в HTML.
Да и само разделение движков я предлагал только в качестве компромисса, для сохранения совместимости и облегчения работы программистам. Если вы можете сохранить совместимость как-то иначе - пожалуйста.
> Так, что оное желание — лишь одна из упомянутых выше сил.
И на основании этого "вы предлагаете искусственно создать дополнительные барьеры совместимости?" (с) ваш.
>>>>>> Вы предлагаете веб-разработчикам каждый день заглядывать в CURRENT-спецификации и исправлять
>>>>>> все свои работы из портфолио?
>>>>> Полностью согласен.
>> Тогда к чему вся эта риторика про "выживает самый гибкий" и "не
>> хотят терять свою аудиторию"?
> Эм. Вы это серьёзно спрашиваете???Естественно серьёзно. Вы же ратуете за отмену совместимости, и тут же соглашаетесь с тем, что разработчики не должны постоянно исправлять свои сайты. По-моему это взаимоисключающие вещи...
Объяснитесь, уж будьте так любезны.
>> Чем больше головной боли у разработчиков, тем больше глюков у пользователей. Закон
>> Фост... тьфу, жизни. :)
> "выживает самый гибкий" (c) ваш.Одно другому не мешает.
>> То есть вы предлагаете искусственно создать дополнительные барьеры совместимости?
> Чего? Да я тут уже несколько дней пытаюсь вам объяснить как важно
> сохранить совместимость со старыми сайтами.А, так вот чем вы, оказывается, занимаетесь? То есть вы думали, что никто до такой простой вещи ещё не додумался?..
> Это вы здесь рассказываете мне сказки о недостижимости идеала, как программистам сложно,
> как выживает самый гибкий и как все подорвутся исправлять давно работающие
> сайты, чтобы они и в новых браузерах работали не хуже.Чего?! Когда это я говорил, что все подорвутся исправлять эти сайты?!
>[оверквотинг удален]
>> код одного из современных браузеров видели? Представляете себе, что это такое?
>> Очень легко сказать, как несложно что-то сделать. Докажите делом. Код Webkit
>> и FireFox открыт, если чо. Жду ваших патчей, можно прямо здесь.
> http://lurkmore.ru/Сперва_добейся ??
> Я не программист. Мне достаточно того факта, что даже в ИЕ это
> уже сделали (без лишних соплей и воплей об архитектуре движка). И
> дело тут не в ценности run-in, а в подходе к значимости
> стандартов: если каждый разработчик браузера будет сам решать какие вещи в
> стандарте ценные, а какие нет - мы рискуем вернуться во времена,
> когда сайты были IE-only и Netscape-only.То есть вы не программист, но при этом позволяете себе советовать, КАК ему надо выполнять свою работу. Ещё раз: не ЧТО в итоге сделать (чтобы сайт показывался), а КАК это сделать. Так кому бы первому прогуляться к Луркоморю?..
>> Вы предлагаете размножить сущности, сделав кучу комплектов "внутреннее представление
>> + рендер" (на каждую комбинацию версии HTML + версии CSS —
>> хвала богам, для последних нынче достаточно обойтись CSS 2.1 и CSS
>> 3); допустим, что скриптовой движок будет один.
> Не надо перевирать мои слова, я говорил лишь о двух движках: старом,
> включающим в себя HTML4.* и всё что было раньше, и новом,
> включающим в себя HTML4.* и всё что выше. Новый включается только
> с доктайпом html5.Позвольте задать наивный вопрос: а что такое, по-вашему, движок браузера?
> Никаких комбинаций не надо, css входит в HTML.
Убили на месте. На http://www.w3.org / прогуляйтесь, что ли, для общего развития. То, что эти стандарты связаны, вовсе не означают, что один входит в другой. CSS помимо HTML может прекрасно использоваться в XHTML, для форматирования XML-документов и даже в Qt. Точно так же HTML-документы могут прекрасно существовать без единой стилевой таблицы.
> Да и само разделение движков я предлагал только в качестве компромисса, для
> сохранения совместимости и облегчения работы программистам. Если вы можете сохранить совместимость
> как-то иначе - пожалуйста.Вообще-то о том и речь, что предлагаемый вами способ — более проблемный, чем используемый ныне.
>> Так, что оное желание — лишь одна из упомянутых выше сил.
> И на основании этого "вы предлагаете искусственно создать дополнительные барьеры совместимости?"
> (с) ваш.Вовсе нет. Тут возникают уже естественные (точнее, вытекающие из других причин) барьеры, но не создаваемые искусственно.
>>>>>>> Вы предлагаете веб-разработчикам каждый день заглядывать в CURRENT-спецификации и исправлять
>>>>>>> все свои работы из портфолио?
>>>>>> Полностью согласен.
>>> Тогда к чему вся эта риторика про "выживает самый гибкий" и "не
>>> хотят терять свою аудиторию"?
>> Эм. Вы это серьёзно спрашиваете???
> Естественно серьёзно. Вы же ратуете за отмену совместимости,Когда?! То, что я спорю с предложенным вами способом, означает, что я спорю со способом, а не с тем, что он должен решить.
> и тут же соглашаетесь
> с тем, что разработчики не должны постоянно исправлять свои сайты. По-моему
> это взаимоисключающие вещи...
> Объяснитесь, уж будьте так любезны.Объясняю: вы сморозили (по незнанию) глупость. Когда вам попытались на это указать, вы решили, что оппонент (я) утверждает не то, что предложенная вам схема хуже нынешних, а то, что оппонент хочет против совместимости как таковой.
Я (и не только) описал вам конкретные проблемы, к которым приведут множественные релизы стандарта, мало чем отличающиеся друг от друга. Предлагаемая вами схема будет плоха и в этом случае тоже; более того, она будет плоха в ещё большей степени, чем в нынешней ситуации, когда стандартов (по сравнению с прогнозируемым) совсем тщуть-тщуть.
Кхм.> Вообще-то о том и речь, что предлагаемый вами способ — более проблемный, чем используемый ныне.
Я бы сказал, что ныне никакого способа не используется, то есть, кто-то проверяет используемые функции по-штучно, кто-то привязывается к версии браузера - парся узерагент, что в сущности и предлагается прокачать, режимы совместимостимости - можно было бы добавить для отстройки от конфликтов версий, когда функции с одинаковым именем ведут себя по разному в разных версиях, хотя допущение такого = ломание обратной совместимости = в стандартах не разделенных длительным периодом времени нонсес, ноуворанти - со всеми вытекающими.
Хорошим примером, я бы назвал libfuse, несколько версий этого самого фусе прекрасно уживаются в одной библиотеке, и даже в одних заголовочных файлах (*.h), переключение по #define FUSE_USE_VERSION, которая автоматом дефайнится, если не указать.
Хотя использование минорно-мажорной семантики не так однозначно. Впрочем, наплевать, пусть уже примут хоть какой-нить стандарт, а то обновил оперу полез, на сайт мтс ммску отправить, а там кнопки 'отправить' нет, написал в поддержку, а они мол юзайти эксплорер, ну и каким хреном под линух его прикручивать, получается линуксоиды и не люди вовсе, черт, ненавижу корпорастов, и крыть не чем, стандарта-то нет.
>> Вообще-то о том и речь, что предлагаемый вами способ — более проблемный, чем используемый ныне.
> Я бы сказал, что ныне никакого способа не используется, то есть, кто-то
> проверяет используемые функции по-штучно, кто-то привязывается к версии браузера - парся
> узерагент, что в сущности и предлагается прокачать, режимы совместимостимости - можно
> было бы добавить для отстройки от конфликтов версий, когда функции с
> одинаковым именем ведут себя по разному в разных версиях, хотя допущение
> такого = ломание обратной совместимости = в стандартах не разделенных длительным
> периодом времени нонсес, ноуворанти - со всеми вытекающими.Да, это недостатки текущей схемы, когда используется единый движок, в котором отдельные элементы могут работать в разных режимах, но в целом движок один, только парсеры (по сути, тупейшие конечные автоматы, или что-то эквивалентное) могут различаться.
> Хорошим примером, я бы назвал libfuse, несколько версий этого самого фусе прекрасно
> уживаются в одной библиотеке, и даже в одних заголовочных файлах (*.h),
> переключение по #define FUSE_USE_VERSION, которая автоматом дефайнится, если не указать.У libfuse весьма простой интерфейс, который вдобавок не определяется «сверху» и поэтому, как следствие, не может содержать противоречий и т.д. Так что хотя архитектурно сравнение корректно, с точки зрения конкретной реализации — уже не очень. В одной местности почтальону лошадь будет подспорьем, в другой — с ней будет больше возни, чем от неё самой пользы...
Так о том и речь, надо бы вертикаль власти укрепить, такие надежды были на html5, а они тупо слили ((
>>> Чем больше головной боли у разработчиков, тем больше глюков у пользователей. Закон
>>> Фост... тьфу, жизни. :)
>> "выживает самый гибкий" (c) ваш.
> Одно другому не мешает.А при чём тут "не мешает"? Я говорил, что если разработчик браузера не сможет обеспечить нормальную работу своего продукта, то он просто вылетит с рынка. "Выживает самый гибкий".
> А, так вот чем вы, оказывается, занимаетесь? То есть вы думали, что
> никто до такой простой вещи ещё не додумался?..
> Чего?! Когда это я говорил, что все подорвутся исправлять эти сайты?!А вот это о чём:
>> Вы забыли один тонкий момент. Половина интернета тоже не захочет, чтобы она
>> перестала работать в новых браузерах. И будет в свою очередь подстраиваться
>> Выживает самый гибкий — как с одной, так и с другой стороны.???
> То есть вы не программист, но при этом позволяете себе советовать, КАК
> ему надо выполнять свою работу. Ещё раз: не ЧТО в итоге
> сделать (чтобы сайт показывался), а КАК это сделать. Так кому бы
> первому прогуляться к Луркоморю?..Я не настаиваю на КАК, я настаиваю на ЧТО! Не цепляйтесь к моему КАК, не объясняйте мне как это сложно, не объясняйте про архитектуры, а просто сделайте. И тогда ни от кого не будете слышать про КАК. Не можете сделать, ну чтож, "выживает самый гибкий" (c) ваш.
Ещё раз: я не настаиваю на КАК, я настаиваю на ЧТО!> Я (и не только) описал вам конкретные проблемы, к которым приведут множественные
> релизы стандарта, мало чем отличающиеся друг от друга. Предлагаемая вами схема
> будет плоха и в этом случае тоже; более того, она будет
> плоха в ещё большей степени, чем в нынешней ситуации, когда стандартов
> (по сравнению с прогнозируемым) совсем тщуть-тщуть.Я никогда не предлагал *множественные* релизы стандарта. Я даже никаких новых схем не предлагал (уж не знаю, где вы это увидели в моих словах), я только выступаю против полного отказа от нумерации версий. Конкретно, против вот этого:
-------------------------------------------
Наиболее важным изменением является отказ от нумерации версий HTML - вместо HTML5 в спецификациях отныне будет просто указываться "HTML". Более того, обновления стандарта теперь будут выпускаться в непрерывном цикле, без явной фиксации версий, без предварительного тестирования черновых вариантов и проведения их публичных обсуждений.
-------------------------------------------
> Так вот, я за то, чтобы FF и Safari уже остановились наконец в гонке за постоянно ускользающим html5, и реализовали-таки полностью весь(!) стандарт css2.1ну лично мне -- тоже не нравиться что броузеры никак не могут осилить основные элементы в CSS :-(
позор! :-D
темболее CSS не проверить Javascript`ом и поэтому CSS-костылестроение приходиться делать -- очень уж "хитрое"
* * *
хотя успокаивает одно: для целей web-applications -- особого исполнения CSS -- не требуется
развитОй CSS -- требуется только для "сайтов компаний". где основная цель это "красивий стиль" а не "полезность" (ну это так думает владелец такого тепичного сайта)
при том что пользователям таких "красивых" сайтов -- как правило пофигу на всю эту "красоту" (им главное это -- найти нужную информацию на сайте. и ВСЁ!).. а сама же эта "красота" нужна только для самоудовлетворения владельцев сайтов
С современными темпами развития веба такое решение напрашивается само собой. Все правильно сделали.
Члены комитета стандартизации C++ подавились слюной от зависти.
Может умрет окончательно.. и то хлеб.
> без предварительного тестирования черновых вариантов и проведения их публичных обсужденийОй... Может, не надо?
Всем спакойно. Нумерация нужна. Всю жизнь она была и сейчас нужна. Помню книгу по HTML 2.0 покупал, а счаз что?! Наверное номер Revision будут указывать своей спецификаци.. А может быть какой API придумать для сайтов что бы можно было понять чего это херня умеет, а чего нет?
Логотип напоминает Метро 2033 :-)
Смотрю много роликов на ютубе уже как месяца 4 на html5, и скажу, что вполне сносно все и нормально для глаз. Вполне нормальный проект, должно же хоть, что нибудь меняться то наконец или нет.