Comments 50
А в чем проблема добавления style=" " напрямую в тэг в HTML? Это всего лишь вопрос традиций, или это негативно влияет на какие-либо аспекты?
HTML предназначен для вывода информации. Оформление происходит в CSS. Использование атрибута style никак не влияет на страницу, даже проходит валидацию, но HTML не предназначен для оформления, для этого есть CSS.
Как понимать фразу «HTML не предназначен для оформления», если спецификацией предусмотрен атрибут style, и он поддерживается всеми браузерами? Каким ещё должен быть HTML, чтобы оказаться «предназначенным для оформления»?
Указание стилей в атрибуте style имеет свои недостатки (дублирование кода, сложность изменения, если стиль одинаковый для разных элементов, высокий приоритет правил — не переопределяешь через стили для всей страницы), но в мелких проектах его может быть совершенно достаточно, а иногда и совершенно необходимо (например, когда элемента становится видимым после каких-то действий пользователя — тогда прописать «display: none» в style при верстке гораздо нагляднее).
Указание стилей в атрибуте style имеет свои недостатки (дублирование кода, сложность изменения, если стиль одинаковый для разных элементов, высокий приоритет правил — не переопределяешь через стили для всей страницы), но в мелких проектах его может быть совершенно достаточно, а иногда и совершенно необходимо (например, когда элемента становится видимым после каких-то действий пользователя — тогда прописать «display: none» в style при верстке гораздо нагляднее).
В будущем возможны сложности изменения вёрстки при использовании style="". Особенно когда над сайтом будет работать другой верстальщик. Ему будет проще делать правки в CSS, а не искать нужный код в файлах.
В стандарте не указано, что в HTML нельзя оформлять страницы, но я думаю стоит разделять вывод информации (HTML) и её оформление (CSS).
В стандарте не указано, что в HTML нельзя оформлять страницы, но я думаю стоит разделять вывод информации (HTML) и её оформление (CSS).
более того, предусмотрен тег
В современном мире — аттрибут style является нарушением CPS, в частности позволяет unsafe-inline и возможно даже unsafe-eval.
Потому лично я бы не рекомендовал его использовать. Пользуйтесь классами.
Потому лично я бы не рекомендовал его использовать. Пользуйтесь классами.
Одноразово пофиг.
А многоразово плохо.
Потом задолбетесь искать все места использования.
А многоразово плохо.
Потом задолбетесь искать все места использования.
Спасибо, кэп.
12. Теги На странице должен быть только один заголовок в теге . В основном, в этом теге находится название страницы.
Кстати html5 допускает на одной странице несколько h1 заголовков, каждый пределах ```html
```
12. Теги На странице должен быть только один заголовок в теге . В основном, в этом теге находится название страницы.
Кстати html5 допускает на одной странице несколько h1 заголовков, каждый пределах ```html
```
… в пределах тегов section.
Ничто не мешало использовать и в html4 более одного h1.
Просто логически в этом мало смысла.
Если нужно несколько h1, то может стоит использовать h2.
1 h1 нужен больше поисковикам.
Просто логически в этом мало смысла.
Если нужно несколько h1, то может стоит использовать h2.
1 h1 нужен больше поисковикам.
Более того, он рекомендует это делать. w3c. В каждом section должен быть свой h1, что иногда заставляет попотеть и воспламеняет невероятные споры с СЕО-шниками, которых даже стандарты переубедить не могут.
Далее немного конструктивной критики
- про длину селекторов и что браузеру что-то там тяжело — не в 2016 году, да и почему именно 3? Магическое число?
- магические числа. Про них не сказано, зато примеры с ними есть. Они как 2005 были злом, так и остались. Разработчик должен понимать откуда каждое число берется
- у иконочного шрифта есть еще одно огромнейшее преимущество: возможность перекрашивать иконки, чего нет у спрайта
- инлайновые стили не зло. Через js их вполне можно пихать (так построены половина библиотек на react), как всегда — инструментом нужно пользоваться с умом
- пиксели в дробных значениях что-то сверх-упоротое, не встречал такого, однако, справедливости ради, с чего вдруг пиксель — это что-то неделимое? Ныне в css виртуальный пиксель достаточно поверхностно связан с физическим и не является чем-то неделимым.
- id и классы имеют разное предназначение и их нужно использовать так же с умом, по обстоятельствам, правила в виде "id не должно быть в css" беспочвенно.
- Пункт 10. Это с чего вдруг? Так называемая accessibility ныне достигается иными способами, а семантика — я уже давал ссылку, где есть пример того, как должно выглядеть семантичное меню
- Сравнение html с Word это как сравнить машинный код и visual studio. Во-первых, Word это приложение, а html — язык разметки, во-вторых, внутри docx лежит такой же xml, не так уж и далеко ушедший от html. Просто странное сравнение.
Статья «Привет из 2005 года»
Стили в html можно и нужно применять в виде тега
Почему-то мой комментарий значительно обрезался.
Попробую повторить:
Стили в HTML можно и нужно применять в виде тега style в заголовке для ускорения загрузки страницы, размещая в нем основные используемые классы, переместив ссылки на файлы остальных стилей в конец html-файла. Разница будет заметна прежде всего в CMS, где используется подгрузка всех стилей независимо от их наличия на конкретной странице. Тоже советует и Google Pagespeed.
Насчет пункта «неправильное название классов» — тут тоже неоднозначно, т.к. например при написании шаблона для CMS мы уже опираемся на константные значения цвета и определенное расположение элементов, которые меняться не будут. Использование в классе понятных имен типа цвета или расположения значительно ускоряет процесс написания и читаемости разметки, с последним например согласен Bootstrap, предоставляя нам набор готовых классов для размещения элементов.
В целом статья кажется незавершенной без комментариев автора относительно тех или иных утверждений, например, почему нужно обязательно использовать атрибут alt в тэгах img, или почему меню должно быть написано с использованием ul/li?
Попробую повторить:
Стили в HTML можно и нужно применять в виде тега style в заголовке для ускорения загрузки страницы, размещая в нем основные используемые классы, переместив ссылки на файлы остальных стилей в конец html-файла. Разница будет заметна прежде всего в CMS, где используется подгрузка всех стилей независимо от их наличия на конкретной странице. Тоже советует и Google Pagespeed.
Насчет пункта «неправильное название классов» — тут тоже неоднозначно, т.к. например при написании шаблона для CMS мы уже опираемся на константные значения цвета и определенное расположение элементов, которые меняться не будут. Использование в классе понятных имен типа цвета или расположения значительно ускоряет процесс написания и читаемости разметки, с последним например согласен Bootstrap, предоставляя нам набор готовых классов для размещения элементов.
В целом статья кажется незавершенной без комментариев автора относительно тех или иных утверждений, например, почему нужно обязательно использовать атрибут alt в тэгах img, или почему меню должно быть написано с использованием ul/li?
Много вопросов почему нужно именно так, а не иначе. Не во всех пунктах раскрыт этот вопрос.
обычно так "кто так делает, горите в аду11!!!".
Да там вот это
исходит из предпочтений мнимой потери в производительности. То что на каждый чих увешиваться классами, увеличивать для парсера количества строк, а следовательно терять туже производительность — эт типа норм.
Чем меньше css тем лучше. Как для парсера, так и человека. Все эти игры «id быстрее класса» «два класса хуже чем один» просто из вакуума. Как будто кто-то видел эту разницу на практике.
Да там вот это
/* предпочтительнее примера выше, если есть возможность */
.form-submit-link {}
исходит из предпочтений мнимой потери в производительности. То что на каждый чих увешиваться классами, увеличивать для парсера количества строк, а следовательно терять туже производительность — эт типа норм.
Чем меньше css тем лучше. Как для парсера, так и человека. Все эти игры «id быстрее класса» «два класса хуже чем один» просто из вакуума. Как будто кто-то видел эту разницу на практике.
Согласен. А также некоторые пункты, в частности №13, так вообще не являются ни ошибкой, ни чем либо увеличивающим нагрузку на сервер или браузер… Чистое имхо автора… Да, непрофессионально, но это не ошибка (исходя из заголовка статьи).
ИМХО в 5 пункте лучше будет вот так:
Ведь по «плохой» версии видно, что пытаются стилизировать ссылку заголовка, а не все ссылки item`а. Ну или как написано дальше:
/* не рекомендуется, большая вложенность */
.page .item .title a {}
/* можно сократить */
.item .title a {}
Ведь по «плохой» версии видно, что пытаются стилизировать ссылку заголовка, а не все ссылки item`а. Ну или как написано дальше:
.item-title-link {}
>Многие верстальщики, когда надо сделать текст зелёным цветом, прикрепляют к нему класс .green.
На этом чуть менее, чем полностью построен bootstrap :)
На этом чуть менее, чем полностью построен bootstrap :)
bootstrap построен на message message-success, а не на message message-green
Вот эта ерунда https://gist.github.com/bryanwillis/279b0f89ef74c39d0aea7ba5037406e3 раньше по ходу была в самом бутстрапе (аутсорсер предоставил верстку с такими классами :) )
Ту да же классы типа italic, fs-11, lh-20
Если не было в самом бутстрапе, то сорри, мне было не до этого, верстка уже была несемантическая.
Из-за оленей сложилось такое впечатление :)
Ту да же классы типа italic, fs-11, lh-20
Если не было в самом бутстрапе, то сорри, мне было не до этого, верстка уже была несемантическая.
Из-за оленей сложилось такое впечатление :)
>>Несколько маленьких картинок рекомендуется соединять в один файл (такой файл называется спрайт). Это уменьшит количество запросов на сайт и улучшит скорость загрузки страницы.
Это если используется старый HTTP/1.1, сейчас пришло время HTTP/2, где это уже неактуально.
Это если используется старый HTTP/1.1, сейчас пришло время HTTP/2, где это уже неактуально.
10. Почему меню должно быть в списке?
Почему не так:
Почему не так:
UFO just landed and posted this here
HTTP/2 arrives but sprite sets ain’t no dead
Спрайты, как и минификация css/js и SPA всё ещё имеют смысл. И, в общем-то, будут иметь смысл ещё наверное до тех пор, пока все ресурсы не будут загружаться одновременно.
UFO just landed and posted this here
Ага, и от меня спасибо, кэп.
А почему alt обязателен, даже если он пустой?
А почему alt обязателен, даже если он пустой?
UFO just landed and posted this here
Да я понимаю, что стандарт требует, но как его отсутствие (пустого alt) скажется на работе сайта? На процессор нагрузка возрастет, грузиться дольше будет, со скриптами какими-то проблемы могут быть?
Если картинки используются в качестве декоративных элементов, а единственный минус — что страница не пройдет валидацию — да и фиг с ним же.
Если картинки используются в качестве декоративных элементов, а единственный минус — что страница не пройдет валидацию — да и фиг с ним же.
UFO just landed and posted this here
Sign up to leave a comment.
15 ошибок или советов HTML и CSS