Comments 124
Может я чего-то не понимаю, но почему бы это не добавить в HTML5?
Думаю по той причине, что уже есть утвержденный список всех фич/возможностей HTML5, который не подлежит сильным изменениям. А до 2014 года возможны лишь небольшие коррекции.
Да не важно в какой версии будут эти изменения, важен срок, если половина этих изменении будут внедрятся скажем в 2012-13 это будет второй революцией HTML :)))
Что именно будет революцией (кроме улучшений аудио-видео, которые всё-таки эволюция)?
HTML5+CSS3+JS это по моему ревалюция в сфере веб дизайна, а с такими изменениями 6ой версии будет второй революцией HTML :))) location,decompress,code,wysiwyg
Увы, всего лишь эволюция в веб-вёрстке. JS не изменился, поэтому даже нельзя сказать, что это эволюция разработки веб-фронтенда.
UFO just landed and posted this here
Да и JS изменился предостаточно. Всякие аксессоры, let,destructing assignment и так далее…
Вы же понимаете, что на таком уровне его знают, а тем более используют, относительно малое число людей, среди тех, кто как бы пишет на JS, типа меня :)
Так и я о том же.
Потому что, с учетом темпов утверждения и постоянным добавлением новых фич, HTML5 не выйдет из драфта вообще никогда.
потому что, колеса на ходу не меняют
На счет элемента <dеcompress>, идея конечно хорошая, но почему ZIP?
Как я понимаю, при этом будет использоваться алгоритм Deflate. Я знаю, ZIP до сих пор популярен (используется для упаковки данных многими программами и играми). Но поймите он уже сейчас устаревший (а если он выйдет лет через 7, это вообще будет катастрофа), почему не перейти на LZMA (хотя для текстовых файлов не самый лучший вариант, но лучше чем Deflate)? Как это сделал, если не ошибаюсь Flash.
Как я понимаю, при этом будет использоваться алгоритм Deflate. Я знаю, ZIP до сих пор популярен (используется для упаковки данных многими программами и играми). Но поймите он уже сейчас устаревший (а если он выйдет лет через 7, это вообще будет катастрофа), почему не перейти на LZMA (хотя для текстовых файлов не самый лучший вариант, но лучше чем Deflate)? Как это сделал, если не ошибаюсь Flash.
Хм. Браузер превращается, браузер превращается… в ОС. Вот мне интерсно это все не google продвигает случайно для свой ОС?
decompress? zip? Добро пожаловать в мир buffer overflow и т.п.? помнится, была история, как положили нахрен mail.ru, который распаковывал архивы для проверки антивирусом. Послали пару архив, распаковывающихся в нцать гигабайт — и привет.
остальные предложения на удивление внятные, даже странно, что они исходят от W3C
остальные предложения на удивление внятные, даже странно, что они исходят от W3C
Распаковку не будет делать сервер. А браузер, вроде. Даже не распаковку, а получения файла из архива. Но вот как в примере рисунок в zip-е — глупо или плохой пример.
А если засунуть в архив файл из нулей размером терабайт эдак 10, чтоб наверняка?
Нет, если такое и делать, нужно хорошо обезопасить, иначе кранты
Нет, если такое и делать, нужно хорошо обезопасить, иначе кранты
> Распаковку не будет делать сервер. А браузер, вроде.
Какая разница? Правильно упкакованый zip — и все, компьютеру легкий писец
Какая разница? Правильно упкакованый zip — и все, компьютеру легкий писец
Правильно упкакованый zip
Смысле
Послали пару архив, распаковывающихся в нцать гигабайт
То это да.
Лучше какой-нибудь mount: и можно иметь доступ к отдельным файлам внутри zip: Едро
Разница — будет ли склеивать ласты сервер, или только браузеры клиентов
А разве сейчас HTTP не использует для сжатия передаваемого трафика gzip, и этот эксплоит нельзя использовать уже и сейчас?
Это, кстати, хороший вопрос. Интересно бы попробовать :)
Доходит до смешного.
2 запроса (html + zip архив со всем контентом сайта) или 50 запросов(html + jqeury+css+css+js+js+пара десятков картин)?
UFO just landed and posted this here
<tеxtarea type="wysiwyg">Эти 25 байт — убийцы дясятков wysiwyg редакторов…
С каждым днем браузер становится все более толстым клиентом html-документов.
wysiwyg — ну наконец-то исчезнет этот заопарк из костылей под каждый браузера и что печально под каждую версию браузера
Закрывайте теги, для которых не нужен отдельный закрывающий тег. Это особенно актуально, когда видишь его первый раз и ждёшь закрытия.
Преимущества такого подхода: доступ веб-браузера к файлам из ZIP, уменьшение требований к пропускной способности каналаВозможно, для вас это окажется откровением, но веб-сервера уже много-много лет умеют отдавать сжатый контент. Причём сжатый этим самым DEFLATE. А чтобы веб-браузер его на лету разжимал, достаточно всего-лишь выдать соответствующее значение заголовка Content-Encoding.
Может ли сервер отдать несколько файлов в ответ на один запрос? Поймет ли его браузер? Можно ли в HTML ссылаться на эти файлы?
Javascript вам в руки, всё реализуемо
И вообще, есть такая штука как MHTML.
Громоздкая очень и требует поддержку со стороны сервера.
У меня такое впечатление, что вы RFC прочитать даже не попытались.
Не скажу, что прочел от корки до корки, но общий принцип, кажется, уловил. И, вроде, ни Apache, ни nginx, ни IIS этот стандарт не поддерживают. В популярных фремйворках тоже что-то не встречал, чтоб хотя бы динамически такие multipart ответы формировать. Да и расширением HTML назвать сложно, на уровне ниже он лежит в основном.
Этот формат — те самые mht-шки, в которые умеют сохранять целиковые страницы Opera и Internet Explorer. Их можно грузить прямо из файловой системы, не то что с веб-сервера.
Не пользуюсь ни тем, ни другим, так что про «те самые» не в курсе. Но поддержка со стороны сервера же всё равно нужна. Не оперу же использовать для их формирования.
Их формировать можно в веб-приложении на уровне шаблонизатора, не вижу в этом никакой сложности.
История умалчивает. В электронной почте это можно. В HTTP это можно при отправке клиент-сервер. Почему бы не сделать и при получении (типа «берите, эти файлы вам пригодятся)?
Как мне кажется не очень юзабельно это будет прежде всего для серверов, вернее разработчиков. Как вспомню мучения с этими multipart что при отправке почты, что при разборе форм на сервере. А тут всё прозрачно — выложил архив со статикой и только ссылайся на него в src.
Ну, стоит предположить, что если отдачей будет заниматься сервер, зная, что клиент ещё файлы, упомянутые в запрашиваемом HTML не получал, то для разработчика сайта всё просто, усложняется только логика сервера. В самом HTML можно прописывать всё точно так же, как если бы файлы запрашивались следующими запросами. Браузер и так вроде бы должен понимать, что раз сервер прислал HTML, а с ним кучу файлов, то файлы нужно закешировать, и в это обращение их обновления не спрашивать (предположу, что должен помочь заголовок Expires, но для самой страницы и для статики он должен бы быть разным).
<tеxtarea type="wysiwyg">
Не забудьте ещё про его стилизацию, а то опять кастыли придётся делать типа прозрачного инпута и картинок сверху.
Или пусть хотя бы одинаково выглядит во всех браузерах.
одинаково выглядит во всех браузерахНе дождетесь (посмотрите, что сейчас с html5-инпутами). Если этот тег одобрят, то будет война wysiwyg редакторов на ряду с войной браузеров.
UFO just landed and posted this here
Шестерка в логотипе ужасна.
Указав тег autocapitalize=«words», браузер каждое новое слово будет писать с заглавной буквы. Актуально для полей указания ФИО, напр. «Вася Пупкин».Автору этой идеи надо выдать премию за идиотизм и познакомить с особенностями написания имён представителей различных европейских и азиатских национальностей.
Да, идея заставить писать каждое слово с большой буквы похожа на идиотизм.
Но, наверное, автор топика просто привёл неудачный пример, т.к. идея оформлять как-то вводимые значения сама по себе не плоха.
Но, наверное, автор топика просто привёл неудачный пример, т.к. идея оформлять как-то вводимые значения сама по себе не плоха.
UFO just landed and posted this here
> text-transform: capitalize в CSS 2.1
В отличие от css, в случае с тегом autocapitalize, браузер сможет выполнять заранее заданные действия, к примеру блокировать кнопку submit или помечать поле как ошибочно заполненное.
Вот что пишет автор идеи:
В отличие от css, в случае с тегом autocapitalize, браузер сможет выполнять заранее заданные действия, к примеру блокировать кнопку submit или помечать поле как ошибочно заполненное.
Вот что пишет автор идеи:
Automatically enable or disable a «shift» key, or make some other
behavioral or content change to a software keyboard to more easily
input capital or non-capital letters.
Чем-то не тем ребята страдают… Давным-давно требуется сделать нормальную работу с лейаутами в режиме софта и в режиме печати, но никто не чешется. А ведь до сих пор ни нормального позиционирования, ни нормального вывода на принтер. Ни один драфт типа флексбокса не только никем толком не реализован, но и вообще по-человечески не продуман и представляет собою не более, чем корявый костыль.
Беспросветный ужас…
Беспросветный ужас…
Я так думаю, что до чего-то серьезного дело просто пока не дошло. Сейчас надо бы с HTML5 закончить.
Я пытался участвовать в работе WHATWG и понял одну вещь — до серьёзного никогда не дойдёт. Неудивительно, что у каждого разработчика браузеров куча проприетарщины внутрях, от собственных CSS префиксов, до расширений JS/DOM — в W3C и связаных организациях творится бардак и детский сад и всё развитие HTML5/CSS3/JS — это по сути жёсткий пушинг со стороны вендоров. Opera засставила принять тег VIDEO, Apple запушила всякие CSS эффекты ну и т.д.
Фактически, мы имеем ситуацию времён Netscape VS IE. W3C и тогда была и точно также ничего не делала, а вендоры творили чад и угар. Разница лишь в том, что тогда все бегали под двумя флагами и кидались во флаги противников какашками, а сейчас все бегают под одним флагом и кидаются какашками непосредственно друг в друга.
Фактически, мы имеем ситуацию времён Netscape VS IE. W3C и тогда была и точно также ничего не делала, а вендоры творили чад и угар. Разница лишь в том, что тогда все бегали под двумя флагами и кидались во флаги противников какашками, а сейчас все бегают под одним флагом и кидаются какашками непосредственно друг в друга.
Если все действительно обстоит именно так как вы описываете — а сомнений на этот счет почему-то и нет — то это просто феерический пи пушной зверь.
И таки получается что вот она — невидимая рука рынка.
И таки получается что вот она — невидимая рука рынка.
Зачем нужен HTML5, когда есть SL? Правильно, чтобы слезть с иглы Микрософта.
Слезая с одной, незаметно залазим на другую…
Слезая с одной, незаметно залазим на другую…
Подсветка синтаксиса для элементов <cоde>Мне вот интересно как они будут отбирать те языки, которые нужно подсвечивать по стандарту, а какие нет? Внедрят список в стандарт? А если мне нужен мой-экзотический-язык — писать прошение на добавление в w3c?
А если список языков оставят на усмотрение вендорам браузеров, то будет еще хуже:
MS IE — я не буду подсвечивать .dart файлы!
Chrome — тогда я не буду подсвечивать C# файлы!
Firefox — а я не буду посвечивать Objective-C файлы!
И в любом случае нам придется писать костыли:
if (!navigator.sourceHightlightSupported('dart')) {
// fallback...
}
Учитывая тот факт, что браузеры уже имеют средства парсинга HTML, JS и CSS, было бы неплохо иметь нативную поддержку подсветки синтаксиса без необходимости парсинга кода на стороне клиента средствами JavaScript'а.
Те мы подсвечиваем только html, js, css или встраиваем сотню «парсеров по стандарту» под все языки?!
Первая партия говна в комментах готова)
<rant> Я далек от веб-разработки, но у меня такое ощущение, что все движется в не том направлении. В HTML не хватает нормальных средств для определения макета страницы. В былые времена, когда все делалось на таблицах, можно было без особых проблем, скажем, разбить страницу на три колонки и поставить height=100%, чтобы прибить футер к низу страницы. Таблицы были не особо универсальны, нарушали семантику, но работали достаточно надежно. Теперь все принято делать на DIV и CSS, якобы с целью отделения представления от семантики. Задумка хорошая, но модель позиционирования в HTML/CSS оставляет желать лучшего, не говоря уже про особенности ее интерпретации в различных браузерах. В результате появляется необходимость в каких-то вспомогательных элементах DIV, которые к семантике документа не имеют никакого отношения, и всяких невообразимых CSS-костылях. Сделать, например, более-менее приличную трехколоночную верстку, выглядящую одинаково хорошо во всех браузерах, представляется мне неоправданно трудной задачей. Работа HTML-верстальщиков — это, должно быть, настоящий кошмар. Стандарту HTML/CSS очень нужен какой-то более простой и гибкий способ задания макета страницы. </rant>
UFO just landed and posted this here
Мне как HTML-верстальщику — возвращение к табличной верстке кажется Адом. Для меня не составляет проблем
в Div-ой верстке прибить к низу футтер. Я знаю наверняка как поведет себя див в отличии от таблицы.
и 99% верстки на дивах будет меньше по коду (HTML) и ИМХО понятнее, и 1% там где дизайнеры придумали что контент должен магическим образом тянуться в разных местах по разному — там за частую и без JS не разберешься.
Кстати насчет CSS костылей css1k.com — это сайт — своего рода конкурс — где с помощью CSS делают разный дизайн для одного и того же HTML кода при этом нужно уложиться в 1кб.
И я заявляю, ХРЕН вы сделаете столько разных «дизайнов» для одного и того же кода на таблицах.
Просто разметка страницы стала немного сложнее в вашем понимании. И станет еще сложнее с введением в жизнь переменных в css и прочих плюшек.
А Семантика это и есть использование таблиц для табличных данных а дивов как контейнеров для блоков на сайте.
В прочем я боюсь нарваться на холивар, я только хотел сказать что у меня нет проблем с использованием дивов вместо таблиц.
Добавление кучи тегов для «семантики» — делает просто больше тем для холиваров, этак мы прийдем к XML :)
PS. Мне одному мозолит глаза этот пример:
где теги footer и header вобще не не в тему используются?
в Div-ой верстке прибить к низу футтер. Я знаю наверняка как поведет себя див в отличии от таблицы.
и 99% верстки на дивах будет меньше по коду (HTML) и ИМХО понятнее, и 1% там где дизайнеры придумали что контент должен магическим образом тянуться в разных местах по разному — там за частую и без JS не разберешься.
Кстати насчет CSS костылей css1k.com — это сайт — своего рода конкурс — где с помощью CSS делают разный дизайн для одного и того же HTML кода при этом нужно уложиться в 1кб.
И я заявляю, ХРЕН вы сделаете столько разных «дизайнов» для одного и того же кода на таблицах.
Просто разметка страницы стала немного сложнее в вашем понимании. И станет еще сложнее с введением в жизнь переменных в css и прочих плюшек.
А Семантика это и есть использование таблиц для табличных данных а дивов как контейнеров для блоков на сайте.
В прочем я боюсь нарваться на холивар, я только хотел сказать что у меня нет проблем с использованием дивов вместо таблиц.
Добавление кучи тегов для «семантики» — делает просто больше тем для холиваров, этак мы прийдем к XML :)
PS. Мне одному мозолит глаза этот пример:
<teaser>
<header>
<h1><a href="http://www.myserver.com/myFirstCoolArticle.html">My First Cool Article</a></h1>
</header>
<p>This is my first article on the page, and it's really cool.</p>
<footer>
<time>3 Days Ago</time>
<div><a href="http://www.myserver.com/myFirstCoolArticle.html"
>http://www.myserver.com/myFirstCoolArticle.html</a></div>
</footer>
</teaser>
где теги footer и header вобще не не в тему используются?
Почем не в тему? Есть тизер с заголовком, содержанием и футером. Меня смущают больше h1 и div.
Хотел написать то что выше, что данные теги предназначены для разметки именно header'a и footer'a документа, но решил лишний раз залезть в спецификацию — оказалось что был не прав. Такое использование как раз является правильным.
UFO just landed and posted this here
Есть несколько стандартов на эту тему. Они обкатываются.
Можно ответить неверстальщику, а почему нельзя ввести спец. тег для таблиц, что-то вроде nonsemantic=true?
Я бы хотел увидеть вещи, перечисленные здесь: habrahabr.ru/qa/13675/
<tеxtarea type=''wysiwyg''>
Ну, как человек, своими руками написавший два визивига, очень хотел бы надеяться, что это действительно будет выходом из ада несоответствий между браузерными реализациями contentEditable, TextRange и т.п., но ведь этого не будет, да? Будет ведь только хуже :(
include(''url'');
Они бы там определились, что ли. Одной рукой через deflate уменьшают количество запросов, другой рукой увеличивают их через include'ы.
Вообще, конечно, лучше бы уже от HTTP 1.1 отошли в сторону какого-нибудь SPDY, тогда и инклуды на стороне клиента можно безболезненно будет делать.
«behaviors» или динамические подклассы элементов DOM
Вот это, кстати, шоколадно. Можно будет крайне красивые библиотеки виджетов создавать. Только представьте, насколько красивее и прямее станут YUI, Dojo, jQuery UI и т.п.
Фактически behaviors воссоздают стандарт, который когда-то придумали в IE. Те же самые bahaviors, даже называются так же.
Подпишусь.
Я даже больше скажу, они в IE вообще молодцы — и фильтры придумали, и ajax, и dhtml, и contentEditable.
Да и TextRange у них значительно прямее реализован, чем Range в W3C. Не говоря уж о том, что у них нет event propagation, только bubbling.
И это только если начать перечислять, там много всего.
Правда, нынешнему поколению веб-разработчиков ничего из этого неизвестно и неинтересно, им интересно «микрософт отстой! долой корпорацию зла!».
Я даже больше скажу, они в IE вообще молодцы — и фильтры придумали, и ajax, и dhtml, и contentEditable.
Да и TextRange у них значительно прямее реализован, чем Range в W3C. Не говоря уж о том, что у них нет event propagation, только bubbling.
И это только если начать перечислять, там много всего.
Правда, нынешнему поколению веб-разработчиков ничего из этого неизвестно и неинтересно, им интересно «микрософт отстой! долой корпорацию зла!».
Вы подменяете понятия. Нынешнее поколение разработчиков критикуют МС и IE6 не за то, что они придумали кучу клёвых штук, а за политику, из-за которой до сих пор большинство людей сидит на ужасно устаревших браузерах.
С этого места поподробнее, пожалуйста :)
Насколько я знаю, большое количество IE6 в счетчиках нам обеспечивают следующие факторы:
1) IE6 дооолго не обновлялся.
2) В корпоративных сетях админы вообще не любят что-нибудь или апгрейдить. Работали с IE6 столько времени? Ну вот и еще столько же поработают.
3) Общая неграмотность пользователей, которые, имея XP, не в курсе о существовании других браузеров и возможности обновления XP.
Но с первым пунктом они борются, как могут — насколько я знаю, сейчас даже апдейт выпустили, который принудительно будет обновлять IE6 до IE8.
Со вторым пунктом вообще непонятно, что они могут сделать — разве что рассказать этим админам, в чем прелесть новых браузеров, но MS и так постоянно рассказывает это.
С третьим пунктом тоже непонятно, в чем вина именно MS.
С моей точки зрения, MS виновата только в том, что долго не обновляла браузер, это раз, и, во вторых (что куда сильнее в данный отрезок времени сказывается) сделала настолько хорошую Windows XP sp1, что многие до сих пор не видят смысла обновляться.
Насколько я знаю, большое количество IE6 в счетчиках нам обеспечивают следующие факторы:
1) IE6 дооолго не обновлялся.
2) В корпоративных сетях админы вообще не любят что-нибудь или апгрейдить. Работали с IE6 столько времени? Ну вот и еще столько же поработают.
3) Общая неграмотность пользователей, которые, имея XP, не в курсе о существовании других браузеров и возможности обновления XP.
Но с первым пунктом они борются, как могут — насколько я знаю, сейчас даже апдейт выпустили, который принудительно будет обновлять IE6 до IE8.
Со вторым пунктом вообще непонятно, что они могут сделать — разве что рассказать этим админам, в чем прелесть новых браузеров, но MS и так постоянно рассказывает это.
С третьим пунктом тоже непонятно, в чем вина именно MS.
С моей точки зрения, MS виновата только в том, что долго не обновляла браузер, это раз, и, во вторых (что куда сильнее в данный отрезок времени сказывается) сделала настолько хорошую Windows XP sp1, что многие до сих пор не видят смысла обновляться.
>Они бы там определились, что ли. Одной рукой через deflate уменьшают количество запросов, другой рукой увеличивают их через include'ы.
Инклудить из архива? По-моему, интересный вариант. Что-то вроде SSI
Инклудить из архива? По-моему, интересный вариант. Что-то вроде SSI
Можно например добавить
вместо js кода для шифрования пароля скажем md5 или sha
вместо js кода для шифрования пароля скажем md5 или sha
Веб технологии растут как на дрожжах прям
Кстати, в FF есть протокол jar, которые делает почти то же самое, что предложенный тег decompress.
Есть такое www.gnucitizen.org/blog/web-mayhem-firefoxs-jar-protocol-issues/ и выглядит элегантней предложенного враппера.
Залил для теста:
К сожалению хабрапарсер не понимает протокол jar:, поэтому вставить картинку напрямую не могу, но это работает.
Залил для теста:
jar:http://dl.dropbox.com/u/2899751/fflogo.jar!/fflogo.pngК сожалению хабрапарсер не понимает протокол jar:, поэтому вставить картинку напрямую не могу, но это работает.
Для HTML 6 достаточно всего-лишь одного, нормальные layout элементы, а не то уныние что есть сейчас. Под нормальными подразумеваю подобие того что реализовано для Android и Silverlight.
Не понимаю, зачем здесь нужен отдельный тег ? В чем его семантика? Почему браузер не сможет открыть файл из архива и без наличия такого отдельного тега.
Ну и конечно есть вопросы и к самой идеи размещения данных в архивах. Действительно ли здесь будет экономия трафика? А что если пользователю понадобится из нескольких десятков ссылок на странице открыть лишь одну из них? Браузеру ради одной ссылки придется скачать и распаковать весь архив для этого?
Служит для идентификации названий книг, блого-постов, фильмов и тд с относящимся к ним авторам даже если разметка распространяется всего на несколько параграфов. Данная семантика может быть реализована в виде псевдо-разметки и определять связи между элементами.
Почему должна быть именно псевдо-разметка? Почему бы не сделать нормальные семантические элементы?
Элемент <editоr>
Данный элемент позволит сохранять набранный текст при переходе по ссылкам.
Непонятно.
А вообще соглашусь с некоторыми ораторами. Лучше бы сейчас всем сосредоточить силы на допиливание и реализацию CSS Layout-ов (Grid, Flexbox, Templates)
Sign up to leave a comment.
HTML.next или идеи для HTML6