Нестандартные атрибуты на HTML-ТЭГАХ. Хорошая вещь? Плохая вещь? Ваши мысли?
Исключения IO могут быть обнаружены только в том случае, если компилятор предсказывает, что в коде может быть что-то, что вызывает IOException. Таким образом, вы получаете предупреждение о том, что исключение IO никогда не выбрасывается из тела оператора try (поскольку в теле try нет ничего).
6 ответов
Я - большой поклонник предложенного решения для HTML 5 (data- снабженные префиксом атрибуты).Править: Я добавил бы, что существуют, вероятно, лучшие примеры для использования пользовательских атрибутов. Например, данные, которые пользовательское приложение будет использовать, которые не имеют никакого аналога в стандартных атрибутах (например, настройка для обработчиков событий на основе чего-то, чего нельзя обязательно выразить в имени класса или идентификаторе).
Мое личное отношение в Вашем примере - то, что маршрут промежутка является более соответствующим, поскольку это соответствует стандартам спецификации XHTML. Однако я вижу argment для пользовательских атрибутов, но я думаю, что они добавляют уровень беспорядка, который не необходим.
Что ж, в этом случае оптимальным решением является
<a href="#" alt="" title="Title of My Pop-up">click</a>
и использование атрибута title.
Иногда я нарушаю спецификацию, если мне это действительно нужно. Но редко и только по уважительной причине.
РЕДАКТИРОВАТЬ: Не уверен, почему -1, но я указывал, что иногда вы думаете, что вам нужно нарушить спецификацию, когда вы этого не делаете.
Другой вариант - определить что-то вроде этого в Javascript:
<script type="text/javascript">
var link_titles = {link1: "Title 1", link2: "Title 2"};
</script>
Затем вы можете использовать это позже в своем коде Javascript, предполагая, что ваша ссылка имеет идентификатор, соответствующий идентификатору в этой хэш-таблице .
У него нет недостатков двух других методов: нет нестандартных атрибутов или уродливого скрытого диапазона.
Недостатком является то, что он может быть излишним для таких простых вещей, как ваш пример. Но для более сложных сценариев, когда вам нужно передать больше данных, это хороший выбор. Особенно учитывая, что данные передаются в формате JSON, поэтому вы можете легко передавать сложные объекты.
Кроме того, вы храните данные отдельно от форматирования, что хорошо для удобства обслуживания.
Вы даже можете иметь что-то вроде это (чего нельзя сделать другими методами):
var poi_types = {1: "City", 2: "Restaurant"};
var poi = {1: {lat: X, lng: Y, name: "Beijing", type: 1}, 2: {lat: A, lng: B, name: "Hatsune", type: 2}};
...
Я тоже ломал голову над этим. Мне нравится удобочитаемость нестандартных атрибутов, но мне не нравится, что это нарушает стандарты. Пример скрытого диапазона совместим, но не очень удобочитаем. Как насчет этого:
<a href="#" alt="" title="" rel="{popup_title:'Title of My Pop-up'}">click</a>
Здесь код очень удобен для чтения из-за нотации пары ключ / значение JSON. Вы можете сказать, что это метаданные, принадлежащие ссылке, просто взглянув на нее. Единственный недостаток, который я вижу помимо взлома атрибута rel, заключается в том, что это может привести к беспорядку для сложных объектов. Мне очень нравится упомянутая выше идея атрибутов с префиксом "data-". Поддерживают ли это существующие браузеры?
Здесь есть о чем подумать. Насколько сильно несовместимый код влияет на SEO?
Пользовательские атрибуты обеспечивают удобный способ переноса дополнительных данных в на стороне клиента. Dojo Toolkit делает это регулярно, и было указано ( Разоблачение мифов о Dojo Toolkit ), что:
Пользовательские атрибуты всегда были правильный HTML, они просто не проверяют при тестировании с DTD. [...] Спецификация HTML гласит, что любой нераспознанный атрибут должен быть игнорируется механизмом рендеринга HTML в пользовательских агентах и Dojo опционально использует это для улучшения простота разработки.