Чому нам доводиться використовувати діви?


13

Сьогодні вранці, коли я писав деякі html та haml, мені спало на думку, що спосіб використання divs є смішним. Чому діви не маються на увазі? Уявіть, якщо це:

<div class="hero-img">
   <img src="http://whatever.com/this.jpg">
</div>

було це:

<hero-img>
   <img src="http://whatever.com/this.jpg">
</hero-img>

Якби передбачалася частина елемента "div class", HTML був би більш семантичним і нескінченно більш читабельним із відповідними тегами, що закриваються!

Це схоже на HAML, де у нас є:

.content Hello, World!

Що стає:

<div class='content'>Hello, World!</div>

Мені здається, єдине, що повинно статися для цього в браузерах, це те, що браузери можуть почати інтерпретувати кожен елемент без наявного визначення елемента html як такого, що передбачає <div class="<element name>">.

Це може бути повністю сумісним назад; для селекторів CSS та jQuery тощо "div.hero-img" все ще може працювати і бути необхідним синтаксисом для вибору елементів.

Я знаю про нову специфікацію веб-компонентів, але це значно складніше, ніж пропонується тут. Ви можете уявити, як приємно було б подивитися джерело веб-сайту і побачити html, який виглядав так ?!

То чому ми повинні використовувати діви?

Якщо ви подивитеся на список елементів Mozilla html5 , кожен елемент має семантичне значення, і тоді ми переходимо до цього, <div>і він говорить:

"Представляє загальний контейнер без особливого значення."

..і потім вони перераховують довільні елементи, які вони додають до html5 <details>.

Звичайно, якби до поняття html було додано це поняття, що мається на увазі, знадобиться десять років, щоб стати стандартними, що становить мільйон років у веб-часі.

Тож я думаю, що має бути вагома причина, що цього ще не сталося. Будь ласка, поясніть мені це!


Насправді є два
Lie Ryan

Відповіді:


7

Завдання 1: Пробіли

Я вважаю, що це взагалі не вийшло. Хоча, одна вагома причина, що цього не відбувається і, мабуть, не повинно статися, це тому, що white-spacesв CSS classesвизначають кілька класів для елемента, а в HTML вони визначають attributes.

Поясніть (або попросіть браузер проаналізувати) наступний код:

<pet family style=" ... ">
  <img src="my-pets-family.jpg"/>
</pet family>

Чи familyє визначенням другого класу чи атрибутом елемента HTML? Як ви, напевно, бачите з аналізатора цього сайту, він вважає, що це атрибут.

Тож, якщо я хочу <div class="pet family">, немає можливості насправді визначити два класи, що є однією з двох головних причин того, що я б у будь-якому разі використовував клас замість ідентифікатора.

Проблема 2: сумісність вперед!

<div>На даний момент використання s примушує нас (принаймні деяких із нас) правильно відступати та коментувати наш код, що є хорошою практикою для всіх мов програмування.

Натомість перетворення HTML-блоків у змінні призведе до великої плутанини у нових програмістів щодо того, що є, а що не робить чогось конкретного в HTML .

Крім того, це спричинить смішний побічний ефект, що ви повинні почати порівнювати свій старий код з новими тегами HTML5, щоб переконатися, що вони не придумали те саме ім’я, яке ви робили для класів вашого діва ...

Ця ж проблема стосується variablesвикористання reserved wordsдеяких мов. PHP вирішив це знаком долара, тому подібний підхід у HTML призведе до чогось не набагато кращого, ніж поточне використання <div class="something">.


Чи були б проблеми з хлопцем, який винайшов "клас", уточнюючи, який <z:name1 attr1=foo attr2=bar> ... <z/name2 attr3=boz ... </z>би був семантично еквівалентний, <div class="name1" attr1="foo" attr2="bar">...</div><div class="name2" attr1="boz"> ... </div>але знадобиться набагато менше часу, щоб надіслати модем 14,4 К?
supercat

Я думаю, що не. Але це був би просто інший синтаксис для написання точно тієї самої речі, не вдосконалюючи поняття <div class="">жодним чином. Знову ж таки, навіщо визначати це z:name1чи z/name2тег HTML, classа не його id? І проблема білого простору тут знову з’являється. Тож треба було б z:"name1 name2"оголосити два класи, що в значній мірі знову стає тим самим.
mavrosxristoforos

Є багато можливостей синтаксису. Моя думка полягала в тому, що в епоху, коли багато людей використовували 14,4 К або повільніші модеми, повинна була бути така форма, яка б хоч дещо розглядала проблеми пропускної здатності.
supercat

Я точно це розумію. Як веб-розробник, я все ще намагаюся мінімізувати що-небудь для створення швидших веб-сайтів тощо. Я вважаю, що це хороший підхід у багатьох аспектах, як і є.
mavrosxristoforos

5

Ми використовуємо <div>замість того, що тикає ваші фантазії, оскільки це робить обробку та візуалізацію браузером простішою.

Як зустрічний приклад, XML дозволяє створювати будь-яке тего-ім'я, яке потрібно. Можливість створення довільних імен тегів поставляється із витратою на обробку. XML-аналізатори повинні скласти словник тегів, які використовуються в документі як частина / під час його аналізу.

Використовуючи <div>веб-переглядачі, ви знаєте, що там є контейнер і він може ігнорувати контейнер або передати його іншому інструменту ланцюга, який може щось зробити з контейнером.


Я майже впевнений, що якби браузери просто використовували згадуваний метод діва, вартість обробки була б малим. І користь для читання, і можливість писемності були б величезними.
Йордан Девіс

3
<div>означає меншу складність, що завжди добре. HTML по своїй суті побудований з двох типів конструкцій: рівень блоку та вбудована розмітка. Маючи більше способів виразити одне й те саме, лише додає безладдя, що є HTML.

" полегшує обробку та рендерінг браузером. " Це насправді не так. Браузер зобов’язаний розбирати нерозпізнані теги, і всі методи DOM та селектори CSS все ще повинні працювати над ними так, як ви очікували, і браузери все одно застосовуватимуть CSS до нерозпізнаних елементів. Єдине, що браузер не робить із нерозпізнаними тегами, це застосувати типи за замовчуванням (стилі користувацьких агентів) та поведінку.
Лежи Райан

3

Ви пропонуєте дозволити веб-авторам додавати до HTML довільні назви елементів для приватних (нестандартних) цілей. У цьому є велика проблема: це стане небезпечним додавати нові елементи до стандарту HTML, оскільки різні автори вже можуть використовувати одне і те ж ім’я елемента в приватних цілях - тим самим змінюючи заднім числом семантику сторінки. Люди не тішаться, коли нові версії веб-переглядачів порушують існуючі веб-сторінки, тому це не потрібно.

Ця ж проблема полягає у використанні довільних імен атрибутів у приватних цілях. Ось чому HTML5 призначає префікс "data-" для атрибутів приватного використання, тому вони не будуть стикатися з новими атрибутами в стандарті.

Div та span визначаються як семантично нейтральні елементи, а це означає, що ви можете використовувати їх у приватних цілях, не побоюючись, що семантика зміниться у майбутніх браузерах. Звичайно, для додавання імені класу потрібно ще кілька символів, але сумісність вперед робить його вартим того.


2

Ваш власний приклад показує одну властивість, чому діви не такі смішні.

<div class="hero-img">
  <img src="http://whatever.com/this.jpg">
</div>

Ви правильно не закрили imgтег. Деякі теги, такі як img, br, hr, та інші не мають ніякого змісту, і, отже , не повинні бути закриті. Парсер це знає.

З divіншого боку, тег повинен бути закритим, оскільки він містить вміст. Якщо ви просто зірвали свій власний тег, аналізатор не мав би уявлення, чи варто очікувати, що тег буде закритий чи ні.

Причина, чому деякі елементи мають бути закриті, а інші - не з спадщини SGML, про яку чудово описується ця публікація в блозі: http://www.colorglare.com/2014/02/03/to-close-or-not- to-close.html


2

Це питання визначеності. Якщо ви використовуєте XHTML, який є чистим XML, отже, повністю визначений, то ви можете використовувати власну область імен, наприклад, за допомогою префікса q::

<q:hero-img>
    <img src="http://whatever.com/this.jpg">
</q:hero-img>

Якщо ви використовуєте XML для перетворення в (X) HTML, ви б повністю вільно генерувати з реального HTML-коду з безкоштовним тегом "HTML" <div class="hero-img">.


У деяких тегах атрибут простору імен із власною (фіктивною) URL-адресою:

xmlns:q="http://..."

1
+1 для простого рішення. Він навіть не повинен включати префікс простору імен і може просто оголосити NS за замовчуванням для загального документа та надати XSLT для перетворення його на (X) HTML.
DougM

1
Простір імен XML визначається не префіксом, а значенням декларації xmlns цього префікса. qтут є абсолютно безглуздий префікс (і недійсний XML), якщо ви не оголосили xmlns десь у документі. Ви також можете передекларувати один і той же простір імен з різними префіксами або встановити простір імен за замовчуванням для певного розділу документа, і якщо значення xmlns рівні, ці різні префікси будуть розглядатися однаково при застосуванні CSS або в DOM.
Лежи Райан

@LieRyan хороший момент. Я повинен був це згадати. Передбачається, що факт був відомий. Додано
Joop Eggen

0

Одним із ключових елементів HTML є фактично попередньо визначені елементи тегів. Ось чому.

Клас div = це спосіб обійти це "обмеження".

І тому ви не бачите цих "натяканих" конструкцій.


Скажіть, що всім інженерам Google, що визначають нову специфікацію веб-компонентів ... Я бачу, що ви маєте на увазі, але в кінцевому підсумку це наступні кілька років буде вибухом елементів, створених розробниками незалежно. Моя ідея просто більш зручна у користуванні. Точка взята, хоча.
Йордан Девіс

0

Призначення елемента div - лише структура. Це дозволяє групувати елементи разом під одним загальним елементом. Це не має нічого спільного з білим простором, швидкістю, візуалізацією, семантикою чи чим-небудь іншим. Це допомагає вам з CSS з точки зору стилізації та javascript з точки зору селекторів. Якщо ви змінюєте його на будь-який інший елемент, то ви змінюєте призначення.

Як створити власний названий елемент, як ви показуєте, виникає проблема в тому, що пошукові системи та інші інструменти не знають, яке значення мають ваші елементи. Що таке "hero-img" і чим він відрізняється від мого "image-hero" і як мій API повинен обробляти це, коли я відвідую вашу сторінку? Як браузер повинен поводитися з цим елементом? Це рівень блоку чи вбудований? Занадто багато питань.


0

Як правило, теги div корисні для застосування розділів чи розділів на веб-сторінці. Ви можете використовувати тег div як контейнер, в який можна застосувати інші елементи. Це також допоможе застосувати CSS та деякі сценарії до певного елемента.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.