Комментарии 14
почему написано только о классах? немного дополню.
в значение атрибута id тоже можно пихать эмодзи: <div id="😍">
в имена атрибутов тоже можно пихать эмодзи: <div data-😍="😍">.
интересно, что A-Z в именах переводятся в нижний регистр, а остальные буквы — нет.
в именах тегов разрешены только ASCII alphanumerics. печалька…
зато в имена custom elements можно пихать эмодзи, но первый символ должен быть a-z: <f😍-😍></f😍-😍>.
Проверено валидатором HTML
я бы не стал доверять этому говну мамонта, который до сих пор HTML5 считает experimental.
я бы не стал доверять этому говну мамонта, который до сих пор HTML5 считает experimental.
Nu Html Checker регулярно обновляется и знает о многих (если не всех) фишках современного html, так что, думаю, ему можно доверять
Да, изложенное касается не только имен классов. Просто меня в данный момент интересуют именно названия классов. Если писать обо всем, то может получиться дубликат стандарта HTML.
Страшно представить, во что превратится код, если в нём использовать такое разнообразие. Предлагаю всё же не мешать красивости и закидоны с общим удобством. Не зря во всех языках есть правила хорошего тона, среди которых прописаны и рекомендации по именованию переменных. Имя класса -- та же самая переменная.
А помойку вместо аккуратного кода разбирать нет никакого удовольствия.
Статья написана не как руководство к действию, а для того, чтобы объяснить учащимся положение дел. При обучении рекомендуют не просто запрещать что-то делать, а объяснять, как и что устроено, и давать рекомендации.
Не спорю. Ясное дело, что возможностей много, их надо показать... С другой стороны, подобные дозволения усложняют парсинг. Ну решил создатель кода использовать буквально всё дозволенное... А потом кому-то с этим взаимодействовать. Человеку ли, скрипту ли -- без разницы. По мне так чистой воды неоправданное усложнение.
Я, собственно, пишу что-то вроде простого парсера HTML, поэтому читаю стандарты по теме. Да, изложенное усложняет мою работу... это не очень приятно. Однако, что делать, если стандарт это разрешает... Не будете же вы писать к своей программе-парсеру пояснения, что, дескать, товарищ пользователь, мой парсер, ищущий ошибки в твоих HTML-файлах, работает только с «хорошим» кодом, так что соблюдай рекомендации, иначе поищи другой инструмент...
Почему?
Потому что они — «общее удобство» только там, где общество говорит на английском языке. А если общество говорит на русском, китайском, арабском или казахском — там «общее удобство» основано на другой письменности и других языках.
Не соглашусь.
Для начала напомню, что языки программирования используются по всему миру. Международный официальный язык - английский. Стандарт же на то и стандарт, что всем понятен. Независимо от того, на каком языке говорит разработчик, он сможет взаимодействовать с кодом: изменять, дополнять, делать что-то на его основе и так далее.
Если же будет мешанина из всяких языков, символов, диалектов и прочего, код станет неудобен. Возможно, мелким проектикам ещё позволительно устраивать в именованиях бардак. Но когда доходит до крупных, подобная небрежность уже близка к эгоизму.
В ваших словах я прочёл, что для крупного международного проекта будет удобным использовать международный язык. Об этом и я написал, спору нет.
Но затем я добавил, что для программы, которую разрабатывают только носители одного местного языка, дело обстоит совсем иначе.
HTML, CSS: какие символы можно использовать в названиях классов CSS