Виходить HTML 5.1, готується HTML 5.2



Представники організації World Wide Web Consortium (W3C) порадували громадськість відразу двома новинами. Мова йде про роботу над HTML 5.1 і HTML 5.2. Специфікація версії 5.1 вже на останній стадії узгодження.

Її статус перейшов від «Release Candidate» до «Proposed Recommendation». Таким чином, HTML 5.1 залишилося отримати «благословення» концорциума («W3C Recommendation») і вийти у світ. Новий стандарт готовий на 99,99%. Так що, найближчим часом стандарт HTML 5.0 буде не актуальне.
Читати далі →

Творець World Wide Web Тім Бернерс-Лі змінив світ, але сам залишився колишнім


фото: firepic.org

25 років тому, 23 серпня 1991 року, британський вчений Тімоті Бернерс-Лі офіційно представив перший в світі інтернет-сайт. За цей час світ змінився кардинально.

Однак те, що представляє собою інтернет зараз, вже не збігається з початковим задумом Бернерса-Лі. Погано це чи добре – спірне питання. Що з цього приводу думає творець WWW? Який шлях пройшов сам Бернерс-Лі?
Читати далі →

Ніколи не здавайся: як Netscape вів нерівну боротьбу з Internet Explorer

image
Джерело: wired.com

Вважається, що перший браузер з'явився 25 грудня 1990 року. Його творцем був Тім Бернерс-Лі, молодший співробітник Європейської організації з ядерних досліджень. За його словами, розробка не зайняла багато часу (близько двох місяців), тому що він використовував платформу зі спеціальним конструктором додатків. Тім в результаті він створив так званий Консорціум всесвітньої павутини (World Wide Web Consortium, скорочено W3C), який розробляв стандарти, впроваджувані в програмне забезпечення.

До кінця 1992 року, крім самого першого браузера під назвою WorldWideWeb, на ринку з'явилося безліч інших, більшість з яких було засновано на бібліотеці libwww – Line Mode Browser, ViolaWWW, Erwise, MidasWWW, MacWWW та інші. Такими браузерами, випущеними в 1993 році, були Cello, Arena, Lynx, tkWWW і NCSA Mosaic.

Mosaic, мультиплатформовий браузер, був розроблений в організації National Center for Supercomputing Applications (NCSA). У жовтні 1994 року Mosaic був на шляху до перетворення в еталонний для всього світу інтерфейс. Кілька компаній ліцензували Mosaic, щоб створити свої власні комерційні браузери, такі як AirMosaic і Spyglass Mosaic.
Читати далі →

Перевіряємо всі сторінки сайту валидаторе html


Інтро

Мета — створити велосипед скрипт, який пробіжиться по сайту і перевірить кожну сторінку сайту на валідність html.
Я чув, що якщо нападає перфекціонізм, то треба полежати, відпочити і це пройде.
Подумаєш, в валидаторе помилка…
Але якщо все ж не проходить, то
Читати далі →

Vibration API: кому і навіщо це потрібно?

10 лютого Консорціум Всесвітньої павутини оголосив про те, що стандарт, що описує API для керування вібрацією, отримав статус рекомендованого. Сама по собі можливість змусити браузер повибрировать пристроєм була доступна вже деякий час, але тільки зараз вона була нарешті оформлена рекомендованої специфікацією, так що прийшла пора подумати, як і де це можна використовувати на щоденній основі. Втім, вже в самому початку автори стандарту попереджають, що API розроблений спеціально для тих випадків, коли потрібна проста тактильний зворотний зв'язок, і він не призначений для використання в якості загального механізму попередження користувача. Для повідомлень рекомендується використовувати Notifications API.

Бажаючі долучитися до офіційної специфікації з усіма її нюансами можуть це зробити на сайті W3C, а тут ми лише побіжно подивимося на те, як все це можна використовувати, а також висвітлимо деякі моменти, не розкриті в документації.

Читати далі →

Стандарт HTML5 досяг статусу рекомендації W3C

Новина дуже коротка, але від цього не менш важлива: W3C офіційно оголосила HTML5 рекомендацією.

«Сьогодні ми, абсолютно не замислюючись, дивимося відео і слухаємо аудіо безпосередньо в браузері, не замислюючись, використовуємо браузер в телефоні,» — говорить Тім Бернерс-Лі, директор W3C. — «Ми очікуємо, що зможемо ділитися фотографіями, купувати, читати новини та отримувати інформацію де завгодно, на будь-якому пристрої. HTML5 і відкрита веб-платформа, залишаючись невидимими для більшості користувачів, роблять можливими і рухають вперед подібні очікування користувачів.»

Офіційний анонс тут: www.w3.org/2014/10/html5-rec.html.en

З нагоди такої великої радості, до чергового засідання TPAC і до 20му ювілейного симпозіуму W3C ми підготували спільно з консорціумом невеликий ролик про важливість відкритих веб-стандартів:



Джерело: Хабрахабр

HTML-імпорт - include для вебу: частина 2

      Переклад статті «HTML Imports #include for the web », Eric Bidelman.
 
 Посилання на першу частину перекладу.
 
 Надання веб-компонентів
HTML-імпорт спрощує завантаження і повторне використання коду. Зокрема, це хороший спосіб поширення веб-компонентів. Це стосується як простих HTML
<template>
, так і повноцінних кастомних елементів з тіньовим DOM [1 , 2 , 3 ]. Коли ці технології працюють разом, імпорт стає інструментом для підключення веб-компонентів.
 
Читати далі →

Що таке HTML імпорт і як це працює?

      Переклад статті «What are HTML Imports and How Do They Work?», Paula Borowska.
 
Ви коли-небудь помічали, що включення однієї HTML сторінки в іншу, це якась чужорідна концепція? Це те, що має бути просто, але не це не часто відбувається. Це не неможливо, але важко. На щастя є HTML імпорт , який дозволяє запросто поміщати HTML сторінки, а також CSS і JavaScript файли, всередину інших HTML сторінок.
 
 

Введення в HTML імпорт

HTML імпорт, це проста для розуміння річ; це спосіб вставки на сторінку інших HTML сторінок. Ви можете сказати, що в цьому немає нічого особливого, так от є; раніше ви не могли це так просто зробити.
 
Цікаво те, що HTML це найпростіші файли, але іноді з ними найважче працювати. Навіть PHP файли мають можливість включення, чому ж HTML цього не може? Завдяки веб-компонентів, ми, тепер, можемо включати одні HTML документи в інші . Також, за допомогою цього ж тега, ми можемо підключати CSS і JavaScript. (Жити стало набагато краще.)
 
Читати далі →

Те, що вам ніхто не говорив про z-index у статті «Те, що вам ніхто не говорив про z-index»

    image
Майже два роки тому вийшла стаття «What no one told you about z-index » (і її переклад на Хабре «Те, що вам ніхто не говорив про z-index »), автори якої розповідають про маловідому (76 % проголосували користувачів Хабра чують про це вперше ), але документованої можливості створення нового контексту накладення вказавши
opacity
менше одиниці.
 
Але незважаючи на назву статті, автори не розповіли вам ще про дещо.
 
 Передбачається, що ви знайомі з поняттям контексту накладення (англ. stacking context).
Елементи з спільними батьками, що переміщаються на передній або задній план разом відомі як контекст накладення . Розуміння контексту накладення є ключем до розуміння
z-index
і порядку накладення елементів.
 
Кожен контекст накладення має свій кореневий елемент в HTML структурі. У момент формування нового контексту на елементі, всі дочірні елементи так само потрапляють в цей контекст і займають своє місце в порядку накладення. Якщо елемент розташовується в самому низу одного контексту накладення , то ніяким мислимим і немислимим чином не вийде відобразити його над іншим елементом в сусідньому контексті накладення , розташованим вище по ієрархії, навіть з встановленим
z-index
рівним мільйону.
— Зі статті «Те, що вам ніхто не говорив про z-index ». Для розуміння теми настійно рекомендую до ознайомлення або її, або класична праця на MDN .
Новий контекст накладення формується у випадках:
 
 
     
Кореневий елемент (
<html>
) завжди містить кореневої контекст накладення . Будь-який елемент на сторінці, що не бере участь в локальному контексті накладення (сформованому будь-яким з наступних варіантів), бере участь в кореневому контексті накладення .
 Елемент з
position
відмінним від
static
і значенням
z-index
відмінним від
auto
. Крім одного винятку для
position: fixed
, але я це виніс в окремий пункт.
 Елемент має значення
opacity
менше, ніж
1
.
 Flex-елемент зі значенням
z-index
відмінним від
auto
, навіть у разі
position: static
.
 Трансформовані елементи: значення
transform
відмінне від
none
;
transform-style
зі значенням
preserve-3d
; і
perspective
зі значенням відмінним від
none
.
 CSS Regions: встановлення значення
flow-from
відмінне від
none
для елемента з
content
відмінним від
normal
.
 Paged Media: кожен Page-Margin Box встановлює власний контекст накладення .
 І нарешті пункт, заради якого я і пишу цю статтю — мобільні браузери на основі WebKit, а також Google Chrome 22 + завжди створюють новий контекст накладання для
position: fixed
-елементів, навіть з
z-index: auto
!
 
Розглянемо останній сценарій більш докладно. Він єдиний з усього списку не описаний стандартами W3C.
 
 Погляньте на приклад .
 
На цій сторінці дві схожі DOM-структури:
 
<div class="container">
  <div class="green"></div>
  <div class="pink"></div>
  <div class="fixed">
    <div class="orange"></div>
  </div>
</div>

Зі стилями:
 
.container { position:absolute; }
.green { position:relative; z-index: 1; }
.pink { position:relative: z-index: 3; }
.fixed { position:fixed; }
.orange { position:relative; z-index: 2; }

Єдина відмінність — у другому варіанті доданий
opacity: .99
для
.fixed
. Оскільки в Google Chrome (починаючи з 22 версії), а також в мобільних WebKit-браузерах фіксовано-позиційований елементи створюють новий контекст накладення (так само як і елементи з
opacity: .99
) — у цих браузерах обидві фігури будуть ідентичні.
 image
 
У свою чергу інші браузери покажуть іншу картину.
 image
 
Так вийшло тому, що значення
z-index
нашого
.fixed
-елемента одно
auto
(що не створює контексту накладення в лівій фігурі).
.orange
опинився в контексті накладення
.container
і встав згідно свого
z-index
(після
.green
, але перед
.pink
).
 
 

Навіщо Google Chrome пішов проти стандартів?

До слова, першими так стали робити Apple в Safari на iOS 5 +, а також основні браузери для Android (крім Firefox).
 
Щоб зрозуміти навіщо, варто було покопатися в архіві www-style@w3.org і знайти лист Джеймса Робінсона з Google , в якому він детально викладає суть проблеми, призводить приклад (який я використовував в статті) і розповідає, що новий контекст накладення для
position: fixed
-елементів у мобільних браузерах створюється для оптимізації скролла і поліпшення user experience (хоча я так і не можу зрозуміти, про яку конкретно оптимізації йдеться і буду вдячний якщо хто-небудь зможе мені пояснити).
 
 Частина листи, де розповідається про причини такої поведінки на мобільних пристроях (англійською) On touch-based devices, responsiveness to touch events and in particular scrolling is essential to providing a good user experience. Users really notice if the page is «behind» their finger. As a result, browsers go to great lengths to provide a good scrolling experience. A big part of this is decomposing a web page into portions that move when the page scrolls and portions that do not, then moving these portions relative to each other on a dedicated thread. Stacking contexts render atomically so a page can always be divided into the stuff «behind» the stacking context, the stacking context's content, and the stuff «above» the stacking context (with the minor wrinkle that the background of an element appears «below» its negative z-index children). Elements that are position: fixed but do not form a stacking context are difficult — the browser would like to separate out the parts that do not scroll with the page, but that may include elements that participate in z-index lists of stacking contexts outside the position: fixed subtree. It would be at least in theory possible to detangle this situation, but the complexity is daunting and as far as I know nobody has attempted this yet.
 
As a result, in MobileSafari on iOS 5 + and the most recent Android browser position: fixed elements establish a new stacking context. As a result, the two test cases in webstuff.nfshost.com / tests / fixpos.html render identically to each other. Firefox on Android appears to render the same way as desktop Firefox, and scrolling is quite janky. Chrome on Android Beta does something more complicated on this page that results in a desktop-like rendering, but I consider that a bug (hey, it's Beta) and intend to bring its behavior in line with MobileSafari. I do not have access to any Windows Phone devices, but I'm curious what its browser does.
Таким чином в Google Chrome просто зробили однакову поведінку фіксованих елементів на desktop і mobile, проігнорувавши рекомендації W3C. Хоча з їхнього боку були пропозиції взяти таку поведінку
position: fixed
в стандарт
, але консорціум поки не виявив інтересу до цих змін.
 
 

Як йдуть справи на поточний момент?


Підводячи підсумки, новий контекст накладення для
position: fixed
формується в наступних браузерах:
 
     
Мобільні браузери на основі WebKit
 Google Chrome 22 + (і його похідні)
 Apple Safari 6.1 + (Desktop)
 Opera Blink (а також мобільні версії )
 
Mozilla Firefox не створюють контекст накладення в такій ситуації і не вважають це необхідним ні для Desktop, ні для Mobile, оскільки не відчувають проблем з оптимізацією скролла.
 
Internet Explorer (перевірив версії 10 і 11) також не формують контекст накладення для
position: fixed
, але коментарів від представників Microsoft я не знайшов і незрозуміла їх позиція в цьому питанні. У мене не було можливості перевірити поведінку на Windows Phone і дізнатися, чи відповідає воно поведінці на Desktop. Буду вдячний, якщо хтось поділиться результатом експерименту.
 
У кожному разі W3C дає лише рекомендації, а кожен вендор вирішує сам для себе дотримуватися їх чи ні. Нам же, простим розробникам, залишається лише враховувати подібні нюанси в своїх веб-додатках (добре, що одна корпорація з відомим продуктом закаляла нас роками).
 
Дякую за увагу!
  

    
Джерело: Хабрахабр