Так что, если пользовательские атрибуты HTML не являются допустимыми XHTML?

Я знаю, что по этой причине некоторые люди не одобряют их, но имеет ли это значение? Я думаю, что сила, которую они предоставляют, взаимодействуя с JavaScript и храня и отправляя информацию с и на сервер, перевешивает проблему проверки. Я что-то пропустил? Каковы последствия "недействительного" HTML? И разве пользовательский DTD не разрешит их?

 alex15 июн. 2009 г., 09:42
Мне нравится знать, что я проверяю ... Это заставляет меня чувствовать себя тепло и нечетко
 Constantine15 июн. 2009 г., 09:36
Я согласен с вами, но я хотел услышать контраргументы.
 Paolo Bergantino15 июн. 2009 г., 09:34
Я действительно хочу, чтобы так много программистов не были одержимы проверкой. Это одна из тех ситуаций, когда моя первая мысль была именно «ну и что?». К сожалению, большинство людей считают это богохульством ...
 Dan F15 июн. 2009 г., 09:38
В значительной степени дубликатstackoverflow.com/questions/992115/custom-attributes-yay-or-nay
 Paolo Bergantino15 июн. 2009 г., 09:57
Проверка это хорошо. Другое дело - поставить на карту наилучшие интересы вашего проекта для проверки. Правильные закрывающие теги, правильный синтаксис - вот что я могу получить. Выбросить решение, потому что оно не подтверждается, - это другая история. Есть причина, почему только 2 из 1000 лучших сайтов в интернете проходят валидацию. Я предпочитаю добиться цели.

Ответы на вопрос(15)

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

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

HTML-элементы с атрибутами, используя JSON:

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

А что касается последствий, см.Ответ SpliFF.

 Kirtan15 июн. 2009 г., 10:05
@ Возможно, это тоже можно сделать; но тогда нам нужно будет создать объекты DOM и сохранить их в памяти.
 Ionuț G. Stan15 июн. 2009 г., 09:54
Я не уверен, что это лучше, чем просто хранить данные как (JavaScript) свойства объекта-элемента DOM (object.attribute = "value"). Я знаю, что у Safari есть рекомендации для этого.
 belugabob15 июн. 2009 г., 09:50
Аккуратное и лаконичное решение - подводит только тот факт, что элемент и атрибуты не хранятся вместе.

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

 Ionuț G. Stan15 июн. 2009 г., 09:36
Пользовательский DTD, как правило, делает вещи хуже, чем наличие пользовательских атрибутов. И не решает никаких других проблем, кроме предупреждений о проверке, так как браузеры игнорируют типы документов.
 Radek24 авг. 2011 г., 09:46
в любом случае, браузеры будут пытаться использовать разные DTD при отображении страницы
 Paolo Bergantino15 июн. 2009 г., 09:45
Можете ли вы привести пример браузера, который будет переведен в режим причуда с помощью пользовательских атрибутов, если у вас есть действительный DOCTYPE? Это звучит маловероятно для меня ...
 Alan Plum15 июн. 2009 г., 11:07
AFAIK большинство браузеров должны быть в порядке, пока существует <! DOCTYPE html>, поэтому HTML 5 предлагает использовать только это (то есть без идентификатора PUBLIC или пути SYSTEM). Браузеры все равно не читают DTD, потому что браузеры не проверяют. Вообще говоря, они не должны даже ломаться, если сталкиваются с пользовательскими элементами (именно поэтому элементы HTML 5 работают вообще).

вы можете легально добавлять пользовательские атрибуты, используя «данные».

Например:

<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. Лучше всего держать его строчными.
 Matt Browne15 мар. 2014 г., 12:15
Примечание: согласно стандарту атрибуты данных, разделенные дефисами, преобразуются в camelCase в Javascript. Таким образом, вы можете использовать data-my-data, и это будет myData в Javascript.
 Victor Farazdagi12 мар. 2012 г., 18:02
Спасибо за упоминание jQuery.data () - делает его не только классным, но и элегантным решением!

наценка является недействительным.

 Matt Browne15 мар. 2014 г., 12:23
Было бы точнее сказать, что это не работает, если браузер не может разобрать его. Даже если пользовательские атрибуты являются «недействительными», все браузеры могут их анализировать, поэтому .html () будет работать нормально.

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

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

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

апсуляция кода, а просто хитрый способ действий. Возьмите пользовательский ротатор рекламы, например, который использует 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 # и других языках, мы не пишем код, помещая все пользовательские свойства в одно свойство в виде строки с пробелом, и в конечном итоге приходится анализировать эту строку каждый раз, когда нам нужно получить к ней доступ или выполнить запись. Подумайте о следующем человеке, который будет работать над вашим кодом.

 SpliFF03 мар. 2014 г., 03:53
Ваше утверждение о том, что одно более запутанно, чем другое, не подтверждается ничем, кроме вашего собственного мнения. В любом случае вам нужно будет где-то документировать атрибуты, чтобы следующий человек мог работать с любым форматом. Тот факт, что вы намеренно изменили идентификаторы на неопределенные аббревиатуры во втором примере, просто чтобы подчеркнуть, что в действительности вы никогда не имели их.

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

Решение Вопроса

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

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

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

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

class="document docId.56 permissions.RW"

 Quentin16 июн. 2009 г., 10:50
Даже если что-то не станет стандартом W3C, оно может быть использовано в проприетарном расширении браузера, расширении плагина браузера или стороннем JavaScript, который вы хотите использовать. Вы можете уменьшить вероятность возникновения коллизии, но если не использовать нестандартные атрибуты, то во-первых, это полностью исключается.
 Constantine15 июн. 2009 г., 10:47
Я считаю, что это хорошее возражение, хотя во многих примерах, которые я привожу в недавних проектах, это не представляет опасности. (Вероятно, «disbursementId» станет атрибутом w3c?) Тем не менее, зная, почему чего-то следует избегать, вы узнаете, когда этого не следует избегать.
 Smithy03 февр. 2013 г., 15:09
Разве это не правдоподобно, что собственное расширение браузера также будет использовать соглашение об именовании данных?
 Nenotlep10 нояб. 2014 г., 10:42
Как и другие разработчики, прокомментируйте разделитель точек - он может сломать селекторы классов:class="thingType.image" -> думать о таргетинге.thingType.image{} или же$('.thingType.image').
 Ionuț G. Stan15 июн. 2009 г., 09:31
Может быть решена путем префикса их. Не говоря уже о том, что настоящий XHTML может извлечь выгоду из пространств имен, но настоящий XHTML в любом случае встречается редко.

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

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

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

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

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

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

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

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

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

Между прочим, я часто иронично вижу, как все эти фанаты проверки склоняются перед хитрыми хитростями Google, такими как загрузка iframe.

Проверка

ы добавить проверку на основе полей фактической задачи.

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

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

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

то СЕГОДНЯ это может не иметь значения, но вы не можете знать, будет ли это иметь значение завтра (и, согласно закону Мерфи, это БУДЕТ иметь значение завтра).

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

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

 Vinko Vrsalovic15 июн. 2009 г., 11:21
Кроме того, подход, основанный на комментариях, будет достаточно надежным в будущем, как и использование JavaScript для хранения данных вместо пользовательских атрибутов. Мне также нравится подход HTML5, делающий ставку на будущий стандарт.
 Paolo Bergantino15 июн. 2009 г., 10:01
Какой из них вы предлагаете использовать в вопросе, на который вы ссылаетесь? Ответ с наибольшим количеством голосов не будет подтвержден как XHTML
 Vinko Vrsalovic15 июн. 2009 г., 11:18
Ответ, получивший наибольшее количество голосов, не является постоянным, поэтому я не могу понять, на что вы ссылаетесь. В любом случае я пропустил теги XHTML в вопросе.

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

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

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

 Paolo Bergantino15 июн. 2009 г., 10:51
... давай согласимся не соглашаться.
 Thomas Hansen15 июн. 2009 г., 14:36
... @ Паоло ... Это не один из тех случаев, это больше похоже на случай, когда ты ошибаешься, а Чак прав ...;)
 Paolo Bergantino15 июн. 2009 г., 09:47
Это больше похоже на страх, чем на любую законную причину избегать пользовательских атрибутов. страница не отображается вообще из-за пользовательского атрибута? действительно? утечка памяти? действительно?
 Paolo Bergantino16 июн. 2009 г., 05:14
... давай согласимся не соглашаться.
 Chuck15 июн. 2009 г., 10:33
Вы знаете, что значит «неопределенное поведение», Паоло? Если вы на какое-то время закодировали C, у вас появится очень здоровый, очень оправданный страх перед ним. Большинство браузеров обрабатывают большинство страниц перчатками для детей, но посмотрите на все страницы, «разбитые» IE 7/8, чтобы увидеть, к чему ведет политика, основанная на нестандартном поведении.

Ваш ответ на вопрос