То що, якщо власні атрибути HTML не є дійсними XHTML?

Я знаю, що з цієї причини деякі люди їх не схвалюють, але чи насправді це важливо? Я думаю, що потужність, яку вони надають, взаємодіючи з JavaScript та зберігаючи та надсилаючи інформацію із та на сервер, перевищує стурбованість. Мені чогось не вистачає? Які наслідки має "недійсний" HTML? І чи не вирішить їх у будь-якому випадку спеціальний DTD?

Вплив полягає в тому, що w3c з’являється через 2, 5, 10 років і створює атрибут з такою ж назвою. Тепер ваша сторінка зламана.

HTML5 надасть тип атрибута даних для легальних користувацьких атрибутів (наприклад, data-myattr = "foo"), тому, можливо, ви можете почати використовувати це зараз і бути достатньо безпечним від майбутніх зіткнень імен.

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

До речі, під "в основному логічним" я маю на увазі в принципі. Насправді ніщо не заважає вам використовувати сепаратор в назві класу для визначення власних значень, а також атрибутів.

class="document docId.56 permissions.RW"

Так, ви можете легально додавати власні атрибути, використовуючи "дані".

Наприклад:

<div id="testDiv" data-myData="just testing"></div>

Після цього просто використовуйте останню версію jquery, щоб зробити щось на зразок:

alert($('#testDiv').data('myData'))

або встановити атрибут даних:

$('#testDiv').data('myData', 'new custom data')

А оскільки jQuery працює майже у всіх браузерах, у вас не повинно виникнути проблем;)

оновлення

• data-myData може бути перетворена в data-mydata в деяких браузерах, що стосується механізму javascript. Найкраще, щоб він залишався малим до кінця.

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

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

Я бачив, як люди, одержимі перевіренням, роблять набагато гірші / дивні речі, ніж використання простого спеціального атрибута:

<base href="http://example.com/" /><!--[if IE]></base><![endif]-->

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

Насправді важливо, щоб у вас були правильно вкладені теги та правильно вказані значення атрибутів.

Я навіть використовую власні імена тегів (ті, що вводяться HTML5, як заголовок, нижній колонтитул тощо), але вони мають проблеми в IE.

До речі, я часто іронізую, як усі ці фанатики перевірки вклоняються перед розумними трюками Google, такими як завантаження iframe.

Замість використання користувацьких атрибутів ви можете пов’язати свої елементи HTML з атрибутами за допомогою JSON:

var customAttributes = { 'Id1': { 'custAttrib1': '', ... }, ... };

А щодо наслідків див . Відповідь SpliFF .

Зберігання кількох значень в атрибуті class - це не правильна інкапсуляція коду, а лише заплутаний спосіб руйнування. Візьмемо спеціальний ротатор оголошень, наприклад, який використовує jquery. Це набагато чистіше на сторінці

<div class="left blue imagerotator" AdsImagesDir="images/ads/" startWithImage="0" endWithImage="10" rotatorTimerSeconds="3" />

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

Повернутися до проекту через рік або прийти до нового, де попередній розробник розділився і поїхав на острів десь у Тихоокеанському регіоні, може бути бісом, намагаючись з'ясувати наміри, коли код пишеться в незрозумілому зашифрованому вигляді, як це:

<div class="left blue imagerotator dir:images-ads endwith:10 t:3 tf:yes"  />

Коли ми пишемо код на c # та інших мовах, ми не пишемо код, поміщаючи всі власні властивості в одній властивості як рядок, розділений пробілами, і в кінцевому підсумку доводиться аналізувати цей рядок кожного разу, коли нам потрібен доступ до нього або запис до нього. Подумайте про наступну людину, яка працюватиме над вашим кодом.

Річ у підтвердженні полягає в тому, що СЬОГОДНЯ це може не мати значення, але ви не можете знати, чи це буде мати значення завтра (а, згідно із законом Мерфі, це ВАЖЛИВО завтра).

Просто краще вибрати перспективну альтернативу. Якщо вони не існують ( вони існують у цьому конкретному випадку ), шлях полягає у винайденні майбутньої доказової альтернативи.

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

Стара дискусія, але тим не менше; на мою думку, оскільки html - це націнка, а не мова програмування, її завжди слід інтерпретувати з поблажливістю щодо "помилок" розмітки. Браузер цілком вміє це робити. Я не думаю, що це буде і не повинно колись змінюватися. Тому єдиним важливим практичним критерієм є те, що ваш html буде відображатися правильно у більшості браузерів і продовжуватиме робити це, скажімо, через кілька років. Після цього ваш html буде, мабуть, перероблений.

Просто для додавання мого інгредієнта до суміші, перевірка також важлива, коли вам потрібно створити вміст, який можна / можна обробити за допомогою автоматизованих інструментів. Якщо ваш вміст дійсний, ви можете набагато легше перетворити розмітку з одного формату в інший. Наприклад, зробити дійсний XHTML для XML з певною схемою набагато простіше при аналізі даних, які ви знаєте і можете перевірити, щоб виконати передбачуваний формат.

Мені, наприклад, ПОТРІБНО, щоб мій вміст був дійсним XHTML, оскільки дуже часто він перетворюється у XML для різних завдань, а потім перетворюється назад без втрати даних або несподіваних результатів візуалізації.

Ну, це залежить від вашого клієнта / боса / тощо. Чи вимагають вони перевірки XHTML?

Деякі люди кажуть, що є багато обхідних шляхів - і залежно від сценографії вони можуть чудово працювати. Сюди входить додавання класів, використанняrel атрибута та когось, хто навіть написав власний синтаксичний аналізатор для вилучення JSON із коментарів HTML.

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

Використання нестандартного HTML може змусити браузер відображати сторінку в "дивовижному режимі", і в цьому випадку деякі інші частини сторінки можуть відображатися по-різному, а інші речі, такі як позиціонування, можуть дещо відрізнятися. Однак використання спеціального DTD може обійти це.

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

Може бути , сторінка відображається в режимі сумісності, можливо , сторінка не робить на всіх на якому - то неясний мобільному браузері, можливо , браузер буде витік пам'яті, може бути вірус вбивця подавиться на вашій сторінці, і т.д., і т.д., і т.д.

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

Я думаю, що розробники перевіряють лише для перевірки, але є що сказати про те, що він підтримує чисту розмітку. Однак оскільки кожен (попередження про перебільшення!) Браузер відображає все по-різному, насправді немає стандарту. Ми намагаємось слідувати стандартам, оскільки це дає нам відчуття, що ми хоча б маємо певний напрямок. Деякі люди стверджують, що дотримання стандарту коду запобіжить виникненню проблем та конфліктів у майбутньому. Моя думка: Зверніть увагу, що сьогодні в будь-якому випадку ніхто не впроваджує стандарти правильно та повно, може припустити, що з часом ваш код провалиться. Якщо це працює, це працює, використовуйте його, якщо тільки він брудний або ви просто не намагаєтеся ігнорувати стандарти, щоб додати його до W3C або щось інше. Думаю, важливо пам’ятати, що стандарти впроваджуються дуже повільно, чи все змінилося в Інтернеті за 5 років. Я Я впевнений, що хтось буде попереджати роки, коли йому потрібно буде виправити потенційний конфлікт. Немає причин планувати сумісність стандартів у майбутньому, коли ви навіть не можете покладатися на сучасні стандарти.

О, я майже забув, якщо ваш код не підтвердить, 10 кошенят загинуть. Ви вбивця кошенят?

Jquery .html (розмітка) не працює, якщо розмітка недійсна.

Перевірка

Для перевірки вам не потрібні власні атрибути. Кращим підходом було б додати перевірку на основі фактичного завдання полів.

Додайте значення за допомогою класів. У мене є назви класів, як:

• date (Дати)
• zip (ЗІП код)
• area (Райони)
• ssn (Номер соціального страхування)

Приклад розмітки:

<input class="date" name="date" value="2011-08-09" />

Приклад JavaScript (з jQuery):

$('.date').validate(); // use your custom function/framework etc here.

Якщо вам потрібні спеціальні валідатори для певного або сценарію, ви просто вигадуєте нові класи (або використовуєте селектори ) для свого особливого випадку:

Приклад перевірки відповідності двох паролів:

<input id="password" />
<input id="password-confirm" />

if($('#password').val() != $('#password-confirm').val())
{
 // do something if the passwords don't match
}

(Цей підхід працює цілком безперешкодно як з перевіркою jQuery, так і з середовищем mvc .net, а також, можливо, і з іншими)

Бонус: Ви можете призначити кілька класів, розділених пробілом class = "ssn custom-one custom-two"

Надсилання інформації "з і на сервер"

Якщо вам потрібно повернути дані назад, використовуйте <input type="hidden" /> . Вони працюють нестандартно.

(Переконайтесь, що ви не передаєте будь-які конфіденційні дані із прихованими входами, оскільки вони можуть бути змінені користувачем майже без зусиль)