HTML 5 draft

неееет.... Мало того, что теперь для хранения кукисов понадобится держать БД на компе (найдутся же умники, которые скажут, что это удобнее), так ещё и любой сайтописатель сможет на моём компе соединения открывать... Файрволы должны будут сделать гигантский шаг вперёд, чтобы новая волна вирусов и ботнетов не зохавала планету (((

> Или вы считаете что там идиоты сидят?

Вы не поверите, но сидят именно идиоты! Старые пердуны времён текстовых терминалов, так и не понявших, куда катится мир.

Как я не раз говорил, не надо путать ВЁРСТКУ и ПРОГРАММИРОВАНИЕ. ХТМЛ - это вёрстка, причём не самой удачной архитектуры. То, что какие-то пионеры Интернета прикрутили БД к вебсерверу, ещё не означает, что теперь, сломя голову, всем нужно срочно публиковаться в браузере. Браузер - это многоплатформенный VIEWER, не более.

А вот что действительно огорчает, так это непонимание въебдизайнерами ортогональности направлений ХТМЛя и исполнения приложений. Лучше ОДНА хорошая программа с богатым интерфейсом работает на Винде, чем многоплатформенный уродец на Жабоскриптовых костылях имитирует жалкое подобие интерфейса.

>Такими темпами понятие браузер и ОС станут синонимами.

Гугл заплатил за пропихнутый стандарт?

> воистину

хм

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

>HTML из онлайна активно врывается в оффлайн и стремится изменить рынок приложений, создавая воистину кроссплатформенную среду выполнения.

на радость быдлокодерам, разве что

каждому быдлокодеру по жабе
каждому быдлодизайнеру по xhtml

> Судьба XHTML четко говорит нам, зачем нужен «просто» HTML. Потому что большинство людей не хотят заморачиваться со всеми этими правилами валидности/невалидности.

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

> HTML - это язык разметки, т.е. язык форматирования/оформления страницы, а не язык программирования!

ИМХО - нет. SGML подразумевает написание программ на языке разметки. Я не силён ы терминологии. Программы SGML (и HTML, в частности) - образец программирования, отличного от общецпотребляемого.

По поводу того, что лучше: HTML или XHTML. Ничего не лучше. Только XHTML полностью поддерживается парой браузеров, плюс XHTML должен обрабатываться как XML, только при выдаче соотв. MIME-типа. Этого многи сайты не делают и XHTML интерпретируется как тег-суп.

http://www.hixie.ch/advocacy/xhtml http://www.mozilla.org/docs/web-developer/faq.html#accept

И ещё...

Beware of XHTML: http://www.webdevout.net/articles/beware-of-xhtml

круто!

html развивается , усложняется , процесс неизбежен
то ли еще будет

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

Кстати, java превосходно исполняет битые программы. Просто при попытке использования несуществующего класса вылетает эксепшен. Только почему-то никто этой возможностью не пользуется, а кривой html пишут все....

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

> и зачем это надо? ради какой такой совершенно-необходимой-фишки набо совокупляться с xslt, что такого в xhtml, что надо строить костыли и подпорки

потому что нормальный xhtml можно парсить любым xml парсером, сравнительно дешево и просто.
это нужно не столько для брауезров сколько для спайдеров и прочих автоматических систем.
это в html парсере куча костылей и подпокорок.

>Такими темпами понятие браузер и ОС станут синонимами.

Это всяким гуглам и надо +) - лёгкая прослойка на железо + БРАУЗЕР и больше ни чего.

А-а-а-а-а XMLScript!

Делать SQL-запросы из HTML-5?

Бред какой-то. Наскока я понимаю, запросы к базе данных делаются циклически из скрипта, причём в большинстве случаев при выполнении каких-то условий.

Что, в HTML-5 сделают скриптовый язык, где будут реализованы циклы и условия?

Все эти нововведения - это фигня, по сравнению с тегом <progress>. Теперь каждый кулдезигнер сможет без использования быдлофлеша сделать прогрессбар, и выдавать его перед загрузкой своей мегастраницы.

>4.11.2. Databases

>4.11.8.2. SQL injection Authors are strongly recommended to make use of the ? placeholder feature of the executeSql() method, and to never construct SQL statements on the fly.

Ай, какая прелесть! Авторы "советуют" использовать плейсхолдеры и никогда не генерировать SQL "на лету". Отличная, отличная заshitа от хакеров. "Ребята, давайте жить дружно".

>SQL - интересно. Насколько понятно из документа это даст возможность
>писать backend к БД минуя серверную часть. Будет удобно для разного
>рода мелких специфических БД в интранете или вообще на localhost.

Дело в том, что, зачастую, поделия из localhost имеют тенденцию переползать на remothost. Вот тут ЖОПА и начинается. Прямой доступ к SQL - злейшее злобное зло. Это полный пипец данным и их актуальности.

>Прямой доступ к SQL - злейшее злобное зло.

Это не зло, это возможность. Топором можно дрова колоть, а можно и бабушку-соседку зарубить. Но никто же не говорит, что топор зло и порождение дьявола.

>потому что нормальный xhtml можно парсить любым xml парсером, сравнительно дешево и просто.

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

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

Так и с парсером, сравнительно дешево ты навытаскиваешь XML елементов из твоего xhtml-я, только вот если ты body тэг вложишь в table тег, то browser-у все равно придется попотеть.

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

Сейчас мне это помогает отлаживать сайты.

Если там будут подключения к SQL и не только, то это позволит... Даже страшно предположить, что так можно будет увидеть текст любого запроса, выполнить любой запрос, получить любые результаты...

>SQL - интересно. Насколько понятно из документа это даст возможность писать backend к БД минуя серверную часть. Будет удобно для разного рода мелких специфических БД в интранете или вообще на localhost.

> Дело в том, что, зачастую, поделия из localhost имеют тенденцию переползать на remothost. Вот тут ЖОПА и начинается. Прямой доступ к SQL - злейшее злобное зло. Это полный пипец данным и их актуальности.

Речь идет о client side базе данных, никак не server side.

> возможностью открывать новые сетевые соединения (опять же, на стороне клиента!) через как TCP, так и Bluetooth...

Какой простор для ботнетов!!!

Хакеры уже просто в диком восторге.

> Какой простор для ботнетов!!!
> Хакеры уже просто в диком восторге.
какое отношения хакеры имеют к ботнетам?

> Так и с парсером, сравнительно дешево ты навытаскиваешь XML елементов из твоего xhtml-я, только вот если ты body тэг вложишь в table тег, то browser-у все равно придется попотеть.
блин прочитай ещё раз сообщение на которое отвечал.
пофигу что там за теги. и речь не о браузере. речь о том что xhtml это валидный xml и его убодней обрабатывать всяким программам(не о браузере речь), например, поисковым системам и т.п.

>Речь идет о client side базе данных, никак не server side.

Да какая разница, если можно сделать document.write("тут код *любого* запроса к БД"). И улетят данные к тому, кто подпихнет код XSS.

>Даже страшно предположить, что так можно будет увидеть текст любого запроса, выполнить любой запрос, получить любые результаты...

Не только тебе, но и хакеру Васе. Здорово, да?

>пофигу что там за теги. и речь не о браузере. речь о том что xhtml это валидный xml и его убодней обрабатывать всяким программам(не о браузере речь), например, поисковым системам и т.п.

Речь идет от том, что для *корректного* восприятия данных необходимо представлять *структуру* документа. Даже валидный XML-документ может иметь неправильную структуру данных, тебе уже привели пример с тегом <body> внутри <title> </title>.

И максимум сложностей - это не парзер написать, пусть даже и к плохо структурированному HTML, а *воспринять* то, что находится на странице, те же два рядом стоящих поля внутри таблицы или два <div>-a, отображаемые рядом.

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

Во-вторых, если вдруг предположить, что таки сделают удалённый SQL, то grant/revoke присутствуют практически в любой уважающей себя СУБД. Маскировать данные можно через CREATE VIEW, изменять данные - через хранимые процедуры.

И чего пугаться? :)

>И чего пугаться? :)

Не "чего", а "кого". Тех обезьян с гранатами, которые не заморачиваются безопасностью и из-за кретинизма которых живут ботнеты.

Тот же случай с червем, который рапространялся через phpbb и google, видимо, никому ничему не научил.

>> так и Bluetooth...

> Хакеры уже просто в диком восторге.

Миллионы сотовых телефонов умрут?

> Тут не стандарт нужен. Тут нужна единая либа, четко реализующая стандарт и поддерживающаяся кем-то одним.

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

И вообще SQL и databases это просто замена кукам. Куки2 так сказать. И не понял, чего все всполошились.

ОМГ. links - наше фсио!

> Речь идет от том, что для *корректного* восприятия данных необходимо представлять *структуру* документа. Даже валидный XML-документ может иметь неправильную структуру данных, тебе уже привели пример с тегом <body> внутри <title> </title>.

Ох ты ж ёб вашу-то мать, лор в своём репертуаре.

Чучельце, ты валидность научись от велл-формедности отличать, потом приходи.

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

> Что, в HTML-5 сделают скриптовый язык, где будут реализованы циклы и условия?

Такой язык не только будет, но и был и есть, называется javascript.

>Ох ты ж ёб вашу-то мать, лор в своём репертуаре.

Именно! Опять очередной тролль-анонизмус несет ахинею.

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

Еще раз и медленно: да, с валидным XHTML работать проще; никто не обратного не утверждал.

Разговор о том, что для понимания информации, размещенной на странице, документ надо *построить*, а не просто прогнать через XML/HTML парзер. Так вот; задача даже минимального рендеринга документа несоизмеримо сложнее задачи парзинга.

Для поисковых систем, индексаторов и т.п., просто распарзить документ недостаточно; я уже приводил пример о двух <td> в таблице.

> Так вот; задача даже минимального рендеринга документа несоизмеримо сложнее задачи парзинга.

Да ведь ты глуп. Хочешь сказать, что рендерить НЕВАЛИДНЫЙ (X)HTML так же легко, как и валидный? В корчах околей, все разработчики браузеров больше всего на свете мечтают о том, чтобы наконец выкинуть эту обратную совместимость с IE4 и начать рендерить всё по-человечески, а невалидные документы посылать в анальную жопу. И только убогонькие вроде тебя выскакивают время от времени заявлениями типа "XHTML не нужен".

> Еще раз и медленно: да, с валидным XHTML работать проще; никто не обратного не утверждал.

Вы, милейший, говорите, да не заговаривайтесь:

> Даже валидный XML-документ может иметь неправильную структуру данных, тебе уже привели пример с тегом <body> внутри <title> </title>.

Эту фразу, по-вашему, я сам придумал? И вот именно из-за того, что различное припизднутое быдло, вроде вас, ничего не смысля ни в XML, ни в SGML, берётся решать судьбы всего мира, веб и превратился в говно. Когда ж вы передохнете, блядёныши?

> Мы же все знаем, что "text/html" - атавизм? Зачем они сделали первый - не понятно.

считается, что XHTML это "слишком сложно и вообще". вопрос только в том, для кого... кому сложно, тех и так бы неплохо метлой то из веб-разработки (imho)

> что парсер xhtml должен прекращать работу при первой же ошибке. и то, что почти все современные cms генерят невалидный xhtml, и про то, сколько надо костылей, чтобы пользователь не ввел чего невалидного...

Валидный xml писать не так уж и сложно, если думать головой при реализации. А насчёт костылей.. ээ.. значит попробовать интерпретировать текст (возможно полученный после уже обработка) как XML и при неудаче делать htmlspecialchars() (если php) это сверхсложно и суперкостыль?

> Судьба XHTML четко говорит нам, зачем нужен «просто» HTML.

Судьба XHTML чётко говорит нам - IE должен умереть

> Я так и не понял. На смену HTML пришел XHTML. Но опять же они делают HTML5 и делают XHTML 2.0 ... Ничего не понимаю. > Зачем два стандарта? Они как бы для одной цели то.

По концепту было так: XHTML - это HTML с более строгими правилами и при одной лишь ошибке в валидности он не должен показываться браузеру. А HTML при ошибках уже в зависимости от браузера рендерится. Так что здесь уже верстальщик выбирает качество и время на разработку или легкость и скорость разработки.

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

> задача даже минимального рендеринга документа несоизмеримо сложнее задачи парзинга.

если имеется ввиду исправление кривизны некоторых страниц (и заточеных под особенности конкретного браузера, и благодаря кривым рукам девелопера страницы) то согласен, лечится только показательным отрубанием рук раздолбаям

> Для поисковых систем, индексаторов и т.п., просто распарзить документ недостаточно; я уже приводил пример о двух <td> в таблице.

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

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

Подразумевается всего-лишь что бы XML был well-formed. Это не так уж и сложно. Это даже проще, чем програмный код писать. Там уже при несуществующих функиях - отказ компиляции, а тут даже при несуществующих элементах ничего, всё продолжает работать.

> Это не так уж и сложно. Это даже проще, чем програмный код писать.

Сравните реализации bbcodes генерирующию валидный html и валидный xhtml и посмотрите которая из них проще (hint: не xhtml)

> Если мы будем браковать весь документ при первой же ошибке разметки, это испортит жизнь многим. Вот поэтому просто HTML тоже должен жить. Не забывайте, что помимо олигархии из 3—4 «тяжелых» браузеров есть еще куча маленьких простых движков для мобильных телефонов, почтовых программ, кофейников и т.п.

Ты противоречишь сам себе. Если все сайты будут валидными, парсер html станет наоборот, проще. Фактически это будет пресловутый "зумль с пацветкой". Понятие "тяжелый браузер" просто отпадет.