LINUX.ORG.RU

HTML 5.1 получил статус рекомендованного стандарта

 ,


4

1

Консорциум W3C объявил версию 5.1 стандарта HTML рекомендованной. В её состав включены стабилизированные спецификации, которые не были готовы на момент выпуска 5.0.

Основные изменения:

  • тег menuitem и атрибут type="context", позволяющие добавлять дополнительные пункты в контекстные меню браузера;
  • теги details и summary, определяющие содержимое виджетов с дополнительной и сводной информацией;
  • тег picture и атрибут srcset для тега img src, предоставляющие средства для определения адаптивных изображений (Responsive Images) — возможность определить серию вариантов изображений, оптимизированных для различных типов устройств, разрешений экрана и уровня масштабирования;
  • API requestAnimationFrame для более эффективного создания анимации;
  • API HTMLMediaElement, который определяет все специализированные свойства и методы для элементов video и audio;
  • поддержка объектов srcObject, упрощающих связывание медиапотока с элементами audio и video;
  • атрибут rev для ссылок, обеспечивающий поддержку RDF/A;
  • элементы enqueueJob и nextJob для манипуляциями микрозадачами в механизме Promise, позволяющем обрабатывать значения в асинхронном режиме, ;
  • возможность создания совместно используемых на разных доменах (cross-origin) элементов track и EventSource, а также определения cross-origin контента для ImageBitmap в блоках canvas;
  • события event-source-error, event-track-error и event-track-load для извлечения медиаконтента;
  • обработчики onrejectionhandled и onunhandledrejection, а также API для отслеживания отброшенных асинхронных операция через систему Promise;
  • новые свойства HTMLTableCaptionElement, HTMLTableSectionElement и HTMLTableRowElement для манипулирования элементами HTML-таблиц;
  • свойство history.scrollRestoration для управления восстановлением позиции прокрутки при перемещении пользователем по истории открытия страниц во вкладке (кнопки назад и вперёд);
  • расширенный атрибут описания интерфейса (IDL) [SameObject] для обозначения объектов, возвращающих идентичные коллекции;
  • атрибут noopener для элементов rel и window, позволяющий явно разделить просматриваемые контексты;
  • атрибут nonce для элементов script и style, обеспечивающий поддержку CSP (Content Security Policy);
  • возможность вложенного определения тегов header и footer;
  • возможность задания пустого элемента option;
  • поддержка определения переводов для содержимого атрибута value в блоке input type="submit";
  • в теге img и связанных элементах узаконено указание нулевого размера (width="0");
  • в блоке meta refresh, значения после ; и url= переведены в разряд опциональных;
  • прекращена поддержка: appCache, command API, атрибута usemap, задания нескольких атрибутов для input type="range", вложенных элементов секций с тегом h1 для формирования отступа, navigator.yieldForStorageUpdates(), Storage mutex, использования tfoot до начала tbody.

Источник

>>> Подробности



Проверено: Klymedy ()
Последнее исправление: sudopacman (всего исправлений: 8)
Ответ на: комментарий от anc

Если серьезно, то речь об SiliconPower(да да, это тоже SSD) и Kingston. Правда не 128, а 64, но смысл не в этом.

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

vblats
()
Ответ на: комментарий от svr4

Вот честно не распарсил. Уж простите (кукрузис еще догадываюсь, остальное хз что такое).
Так нужон игровой комп в современном мире или нет? А если нет, как Вы заявляете, то почему онтопик тогда не катит как игровой?

anc ★★★★★
()
Ответ на: комментарий от vblats

Если серьезно, то речь об SiliconPower(да да, это тоже SSD) и Kingston. Правда не 128, а 64, но смысл не в этом.

И т.е. вас не смущало использование ssd размером 64, 128 ? И также не смущало скинуть туда же swap ? Тогда повторюсь - ССЗБ.

HDD не умирали. Потихонечку обрастали сбойными секторами

тут тема недавно была в админ, где я привел пример как «Потихонечку» мрет десктопный хард. Угу, меньше суток и звиздец.
ЗЫ А то что вы написали «HDD не умирали.» это было много лет назад и «уже не правда».

anc ★★★★★
()
Ответ на: комментарий от vblats

Вангую, что благодаря сандфорсу вместо контроллера.

svr4
()
Ответ на: комментарий от vblats

silicon power
kingston

ССЗБ же.

ССД (а не бальшие-бальшие флэшки) делают только Micron, Samsung и Intel.

svr4
()
Ответ на: комментарий от anc

Тащемта, на сэндфорсах 8 гиг от 128 отрезаются не под какой-то там резерв, а под личные нужды контроллера (что-то типа кэша, ибо своего отдельного у него нет). А так - теорема эскобара.

svr4
()
Последнее исправление: svr4 (всего исправлений: 1)
Ответ на: комментарий от anonymous

Забей, там только для нетру, но забавненько, инви не врёть.

deep-purple ★★★★★
()
Ответ на: комментарий от anonymous

Каким образом говносайт попадёт ко мне в браузер?

С выдачи гугля.

h578b1bde ★☆
()
Ответ на: комментарий от anonymous

Так верстал твой отец. И отец твоего отца. И отец отца твоего отца. Одним махом ты назвал всю свою родословную мудаками.

Fail.

h578b1bde ★☆
()
Ответ на: комментарий от invy

Обычно - да. А если я попадаю на незнакомый сайт, который по каким-то причинам мне не понравился, я выберу другой.

f1xmAn ★★★★★
()
Ответ на: комментарий от uin

Зато никакого джаваскрипта, все должны быть довольны, не?

Так ведь жабаскрипт ещё разрешить нужно тычком по иконке NoScript, а это говно будет работать сразу.

h578b1bde ★☆
()
Ответ на: комментарий от uin

тогда почему бы сразу не использовать links

Там нет вкладок, очевидно же.

браузер в режиме чтения

Хз что это, если что я в браузере не только читаю, но и пишу.

h578b1bde ★☆
()

Как много нового я узнал прочитав тред! Спасибо!

anonymous
()
Ответ на: комментарий от h578b1bde

я в браузере не только читаю, но и пишу

Тогда тебе бы могло помочь приложение на javascript, которое бы при переходе на страницу останавливало бы браузерное действие, скачивало само исходный код страницы вычищало бы его от всего лишнего (стили, скрипты, etc) и только потом вставляла в окно что бы его браузер распарсил. Но ты ведь не любишь жабоскрипт, так что ..

uin ★★★
()
Ответ на: комментарий от dk-

Да что бы говорите. Зафигачьте на него своп, только мозгов должно быть «столько» что бы он юзался постоянно... Или другой вариант, поставить офтопик, он постоянно что-то пишет...
Хотя в чем-то вы правы, купить - положить в сейф - не трогать, время жизни скорее всего увеличиться (исключение всякие пожары, землетрясения и т.п.)

anc ★★★★★
()
Ответ на: комментарий от anc

У меня самому старому ссд - более 4 лет. Офтопик, со свопом венды, с кэшем жручего до кешей софта, со всеми временными файлами, с торентами и т.п. и т.д. Признаков износа «в усмерть» даже на горизонте нет.

Подавляющее большинство смертей ссд вызваны глючными контроллерами и прошивками, но никак не износом ячеек. Было несколько исследований, где бытовые ссд по кругу перезаписывали постоянно, выясняя, когда же они наконец сдохнут. Так вот они пережили по несколько (не 2 и не 3) заявленных производителем ресурса. И большая часть из них упала в р\о, а не насовсем умерла.

ССД, по сравнению с винтами (если не нарвался на баг прошивки\контроллера), изнашиваются предсказуемо, что очень круто. А не сыпятся бэдами в одночасье, как винты.

SSD, меряемся временем\ресурсом жизни

dk-
()
Ответ на: комментарий от dk-

Все равно очень субъективно. Хотя познавательно. Спасибо!
Имхо лучше всего написал svr4 выше " А так - теорема эскобара."
Я могу привести примеры и быстрой смерти ssd в том числе на mac air (шо там юзвер делал нам не ведомо) так и свои «долго живущие».
ЗЫ К минусам домашних ssd можно отнести практическую невозможность восстановления данных. Но это уже за рамками обсуждения. Бэкапы, бэкапы и ещещ раз бэкапы.
ЗЫЫ Вообще обсуждать наработку имхо еще рано, вот лет через 7-10 будет о чем поговорить.

anc ★★★★★
()
Ответ на: комментарий от anc

Думаю согласишься, что большинство лоровских историй о смерти ссд - они не про износ, а про «ой перестал работать». У кого через дни после покупки, у кого через месяцы.

dk-
()
Ответ на: комментарий от dk-

Не соглашусь, только по причине что не вел статистику :) А статистика личного опыта конечно пока не большая. Как уже написал, посмотрим лет через 7-10.

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

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

За этой хренью будущее. Самсунг (кто там еще? интел и микрон?) постоянно делают новые ништяки. Цены в баксах падают постоянно.

Слава ссд!)

dk-
()
Ответ на: комментарий от dk-

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

Вот тут я с вами согласен полностью!!! Не для того покупаю, что бы экономить «на спичках».

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от uin

Вот как раз в JS ничего плохого не вижу, с ним все научились жить и бороться. А вот это - лишняя непонятная фигня.

Самое главное, не вижу юзкейсов (кроме спама), когда имеет смысл запхивать что-то в контекстное меню браузера. Все кнопки «share on ...» прекрасно делались жабоскриптом.

invy ★★★★★
()
Ответ на: комментарий от StReLoK

нужно давно запилить что-то внятное с нуля, а то для вяленого

Звучит как «нужно давно запилить чудоспецию, чтобы говно можно было есть»

cipher ★★★★★
()
Ответ на: комментарий от invy

Вас черт разберешь, одни кричат «долой джаваскрипт! даешь чистые BrowserAction интерфейсы!» другие долой уродливые браузерные элементы из стандартного набора!

И действительно, всю свою дурную славу JS получил как раз благодаря костылешаманствам с элементами вроде <input type="file" /> пряча их куда-то и вызывая костыльным методом elem.click() получая таким образом открытие диалогового окна выбора файла, потому что никаких прямых функций для этого дела браузер не предоставляет. И точно так же он не предоставляет прямых функций для некоторых действий доступных в системном меню (например «сохранить как»), так же до сих пор не все хорошо c Clipboard API и History API (что бы можно было отказаться от доступных из браузерного меню cоpy/paste), не говоря уже о том что в системном меню еще и расширения прописываются. А делать свое через Javascript это отменять браузерное действие по правому клику и вытаскивать свой самодельный красивый список.

Нет, я не за то что бы напихивать в системное меню элементы таким способом, но мне очень нравится идея простого добавления атрибута contextmenu="image_context" например к изображению что бы при клике выподало то самое <menu id="image_context"> тогда как с самодельным меню приходится вешать обработчик oncontextmenu вытаскивать размещать его в нужном месте высчитав позиционирование, вешать обработчик onmouseup на страничку что бы следить за тем куда и какой кнопкой мыши нажали что бы если что его спрятать/переместить/оставить наместе/ Добавь еще к этому отслеживание положения z-index если у нас в окне несколько абсолютно позиционированных элементов - ужас, и ладно что все это на самом деле не так уж много кода написать потребует, но ведь потребует то писать каждому, то есть 1000000 реализовываний одного и того же.

Почему бы и не предоставить сразу из коробки? Только не в системное меню куски пихать как сейчас а полностью конструировать свое через вот этот интерфейс, а на недостающие пункты сделать что то вроде:

<menu id="image_context">
   <item type="update-page" title="Обновить страницу" icon="update.png"></item>
   <item onclick="openInEditor">Отредактировать</item>
   /* ... */
   <item type="save-as">Сохранить эту хуйню как</item>
   <menu type="extensions-block"></menu>
</menu>

ну или предоставить прямые функции для тех же сохранений, хотя и одно другому не помешает.

uin ★★★
()
Ответ на: комментарий от uin

Вас черт разберешь

Кого это «вас»? Я ни в какие секты не записывался и высказываю свое мнение и свой опыт (как пользователя).

Если бы был интерфейс создания отдельного независимого меню (не зависимого от контекстного браузера), то было бы совсем другое дело. А контекстное меню - инстурент управления браузером и лепить туда управление вэб-страниецй не правильно.

invy ★★★★★
()
Ответ на: комментарий от invy

контекстное меню - инстурент управления браузером

Ты имеешь в виду браузерное системное контекстное меню? Вообще это идея мозилы, они давно ее двигают (google: HTML5 Context Menus) b в огнилисе фича поддерживается где то с фф 10х версий если не еще раньше, только вот разрабртчики хромого сразу сказали что не будут поддерживать это говно и добавлять элементы в контекстное меню в их браузере можно через API доступное только для расширений.
Так что в этом плане врядли что изменится.

Если бы был интерфейс создания отдельного независимого меню (не зависимого от контекстного браузера), то было бы совсем другое дело.

Так вот и я об этом же, просто вот с этим фронтендом <menu><item> его бы можно и оставить, мне он нравится (гораздо удобнее хромовских chrome.contextMenus.create(), chrome.contextMenus.onClicked).

uin ★★★
()
Ответ на: комментарий от uin

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

Но они это тоже через флаги разрешили:

Note: Chrome support is limited to Chrome 48+ running with --enable-blink-features=ContextMenu.
Between Chrome 48 and 52, it was enabled behind the «Experimental Web Platforms» feature flag.

https://dpogue.ca/articles/html5-menu.html

Так вот и я об этом же, просто вот с этим фронтендом <menu><item>

только он не для того, а именно для того что ты называешь системным меню браузера. У хрома вроде бы это тоже есть, включается флагами:

invy ★★★★★
()
Последнее исправление: invy (всего исправлений: 1)
Ответ на: комментарий от uin

Тогда тебе бы могло помочь приложение на javascript, которое бы при переходе на страницу останавливало бы браузерное действие, скачивало само исходный код страницы вычищало бы его от всего лишнего (стили, скрипты, etc) и только потом вставляла в окно что бы его браузер распарсил.

Для чего мне такая помощь? У меня скрипты блокируются для минимизации тормозов говносайтов, написанных жабоскрипт-макаками, а не наоборот для добавления. Заодно блокируется реклама и всякое ненужное всплывающее говно на всю страницу в процессе чтения контента типа „подпишись на нашу ненужную группу в ненужной соцсети”. Стили же мне никак не мешают, кроме клинических случаев когда просмотр контента специально блокируется до включения жабоскрипта, но тут для одноразовых сайтов с единственным юзкейсом „прочитал и забыл” фаербаг с display: none; и Ctrl+W решают. Собственно, многоразовых сайтов, у которых есть такое поведение, для меня не существует.

h578b1bde ★☆
()
Последнее исправление: h578b1bde (всего исправлений: 1)
Ответ на: комментарий от invy

Ого, не знал.

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

Да знаю я прекрасно для чего он, сам добавлял туда пункты типа зарепортить / найти в гугле итп. И кастомные меню делал для веб приложений встроенных на сайте. Я именно что о том что если бы завтра стандартизовали кастомное создание менюшек (вместо вот этого говна) то интерфейс создания можно было бы оставить этот.

uin ★★★
()

HTML5 is a living standard © А это всего лишь форк-снапшот.

anonymous
()
Ответ на: комментарий от StReLoK

запретить использование xml

Ты ещё с жуйсоном говна не пожрал, я смотрю.

anonymous
()
Ответ на: комментарий от arkhnchul

Видимо поэтому музыку без DRM не продают. Или погоди-ка...

anonymous
()
Ответ на: комментарий от ism

Кто-нибудь мне может объяснить, как стандарт на разметку элемента и на его, гм, оформление, приведёт к тому, что сам элемент получит хоть какую-то разумную логику своей работы посложнее того, что было в HTML 4?

От стандарта хотелось бы не ещё более запутанной разметки, а превращения HTML из набора белиберды в язык описания стандартизованного набора виджетов (с их стандартизованными же базовыми алгоритмами поведения - потенциально изменяемыми/заменяемыми в JS) вместе с описанием их взаимодействия (как расположены, как воздействуют друг на друга при изменении).

А мы имеем всё тот же бред сивой кобылы в духе «напиши 10000 ничего не значащих слов в угловых скобочках и припиши к этому CSS-описание с JavaScript'ом, чтобы это всё имело хотя бы минимальный смысл».

DRVTiny ★★★★★
()
Ответ на: комментарий от anonymous

Да я их уже 20 с лишним лет жду.

Веб-технологии за это время окончательно укатались в сраное тормозное г*вно, сколько можно-то?!

DRVTiny ★★★★★
()
Ответ на: комментарий от annulen

Да, у меня это говно не установлено.

anonymous
()
Ответ на: комментарий от StReLoK

Вообще нужно давно запилить что-то внятное с нуля

Ну так запили, чего ты время на трёп тратишь-то?

anonymous
()

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

phoen ★★
()
Ответ на: комментарий от phoen

Ну и куда ты отойдёшь? Чтобы «отойти» нужно всё, изобретённое долгими мучительными годами, переизобрести заново. Куча времени и человеколет, да и кто будет делать сайты на том, что нигде не поддерживается? Да и поддержку старого выкидывать нельзя, а смысл тогда?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.