Итак, что, если пользовательские атрибуты HTML недействительны XHTML?

Ответ 1

Разветвление в том, что w3c приходит через 2, 5, 10 лет и создает атрибут с тем же именем. Теперь ваша страница сломана.

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

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

Кстати, под "в основном логическим" я имею в виду в принципе. На самом деле вам нечего останавливать использование seperator в имени вашего класса для определения пользовательских значений, а также атрибутов.

class="document docId.56 permissions.RW"

Ответ 2

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

Например:

<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. Лучше всего держать его в нижнем регистре.

Ответ 3

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

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

Ответ 4

Я видел, как люди, одержимые проверкой, делали намного худшие/странные вещи, чем использование простого пользовательского атрибута:

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

По-моему, пользовательские атрибуты действительно не имеют значения. Как говорят другие, может быть хорошо следить за будущими дополнениями атрибутов в стандартах. Но теперь у нас есть атрибуты data- * в HTML5, поэтому мы сохраняемся.

Что действительно важно, так это то, что у вас есть правильно вложенные теги и правильно цитированные значения атрибутов.

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

Кстати, я часто иронически понимаю, как все эти фанатичные фанатики склоняются перед умными трюками Google, например, iframe uploads.

Ответ 5

Вместо использования настраиваемых атрибутов вы можете связать свои HTML-элементы с атрибутами с помощью JSON:

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

А что касается разветвлений, см. ответ SpliFF.

Ответ 6

Сохранение нескольких значений в атрибуте класса не является правильной инкапсуляцией кода и просто запутанным способом взлома. Возьмите собственный ротатор объявлений, например, который использует 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"  />

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

Ответ 7

Вещь с проверкой заключается в том, что СЕГОДНЯ это может иметь значение, но вы не можете знать, будет ли это завтра, и, по закону Мерфи, это будет иметь значение завтра).

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

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

Ответ 8

Старое обсуждение, но тем не менее; на мой взгляд, поскольку html - это надбавка, а не язык программирования, ее всегда следует интерпретировать с снисходительностью к "ошибкам" разметки. Браузер вполне в состоянии это сделать. Я не думаю, что это будет и должно измениться. Поэтому единственными важными практическими критериями являются то, что ваш html будет отображаться правильно большинством браузеров и будет продолжать делать это, скажем, несколько лет. По истечении этого времени ваш html будет переименован в любом случае.

Ответ 9

Чтобы добавить свой ингредиент в микс, валидация также важна, когда вам нужно создать контент, который можно/можно было бы обработать после использования с помощью автоматических инструментов. Если ваш контент действителен, вы можете гораздо легче конвертировать разметку из одного формата в другой. Например, выполнение правильного XHTML в XML с помощью конкретной схемы намного проще при анализе данных, которые вы знаете, и можете проверить, чтобы следовать предсказуемому формату.

Я, например, НЕОБХОДИМО, чтобы мой контент был действительным XHTML, потому что очень часто он преобразуется в XML для различных заданий, а затем преобразуется обратно без потери данных или неожиданных результатов рендеринга.

Ответ 10

Ну, это зависит от вашего клиента/босса/и т.д.. они требуют, чтобы он проверял XHTML?

Некоторые говорят, что есть много обходных решений - и в зависимости от сценария они могут отлично работать. Это включает в себя добавление классов, использование атрибута rel и того, кто даже написал собственный синтаксический анализатор для извлечения JSON из комментариев HTML.

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

Ответ 11

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

Ответ 12

Поскольку они не являются стандартными, вы не представляете, что может произойти, ни сейчас, ни в будущем. Как утверждают другие, W3C может начать использовать те же самые имена в будущем. Но еще более опасным является то, что вы не знаете, что сделали разработчики "браузера xxx", когда они сталкиваются с ними.

Возможно, страница отображается в режиме quirks, возможно, страница вообще не отображается на каком-то неясном мобильном браузере, возможно, в браузере произойдет утечка памяти, возможно, вирус-убийца задохнется на вашей странице и т.д. и т.д. и т.д.

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

Ответ 13

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

О, я почти забыл, если ваш код не подтвердит, что 10 котят-детей умрут. Вы убийца котенка?

Ответ 14

Jquery.html(разметка) не работает, если разметка недействительна.

Ответ 15

Проверка

Вам не нужны специальные атрибуты для проверки. Лучшим подходом было бы добавить проверку на основе фактической задачи полей.

Назначить значение с помощью классов. У меня есть классные имена:

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

Пример разметки:

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

Пример javascript (с jQuery):

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

Если вам нужны специальные валидаторы для определенного или сценария, вы просто изобретаете новые классы (или используйте selectors) для своего специальный случай:

Пример проверки соответствия двух паролей:

<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" />. Они работают из коробки.

(Убедитесь, что вы не передаете конфиденциальные данные со скрытыми входами, так как они могут быть изменены пользователем почти без усилий)