Comments 62
Я никак не могу понять тенденцию использовать тэги не по назначению. Тэг <i> — выделение текста курсивом, какого черта делать из этого картинку.
Было такое, что я изменял чужой код. Для меня пустой тэг <i> — это отсутствующий текст курсивом. Я его удалил как мусор, т.к. текста нет и в той области сайта нет генерируемого в JS контента. А оказалось там были какие-то иконки. Пришлось исправлять назад.
Пожалуйста, не делайте геморрой при поддержке кода. Используйте тэги по назначению.
Было такое, что я изменял чужой код. Для меня пустой тэг <i> — это отсутствующий текст курсивом. Я его удалил как мусор, т.к. текста нет и в той области сайта нет генерируемого в JS контента. А оказалось там были какие-то иконки. Пришлось исправлять назад.
Пожалуйста, не делайте геморрой при поддержке кода. Используйте тэги по назначению.
Данный подход я позаимствовал у далеко не последнего по популярности фреймворка. И да, тег <i> не пустой, у него есть класс img-cat, что как бы намекает. Порой, выйти за рамки — это хорошо :)
Я понимаю, что я «никто и ничто» чтоб критиковать Twitter Bootstrap, тем не менее, даже у них — это плохая практика. Имхо.
А чем плох <span class=«img-cat»> или <div class=«img-cat»>. Длиннее на 2-3 символа? Зато понятно что это какой-то блок, а не текст курсивом.
А чем плох <span class=«img-cat»> или <div class=«img-cat»>. Длиннее на 2-3 символа? Зато понятно что это какой-то блок, а не текст курсивом.
У <img /> есть обязательный атрибут src, который сводит всю задумку на нет. Я сам бы рад использовать именно этот тег.
и
alt тоже обязательный, кажется
Можно написать сниппет для вашего текстового редактора, например
который по хоткею вставит что-нибудь такое:
Выход может быть в любом синтаксисе (haml если надо)
Или я не совсем понял проблемы?
testimg-800-600который по хоткею вставит что-нибудь такое:
<img src="http://placekitten.com/800/600" width="800" height="600" alt="Test image">Выход может быть в любом синтаксисе (haml если надо)
Или я не совсем понял проблемы?
Никто не запрещает оставлять значение src пустым (вуаля, src="", и всё замечательно).
Пихните в него пустую прозрачную гифку 1х1 пиксель и проблема решена. В погоне за непонятой экономии символов получается невероятная чушь, по сути можно всю html верстку сделать из тега i (+ огромная таблица стилей, перепределяющая поведение тега в заивисимости отустановленного класса) и будет экономно и черт ногу сломит что с этим делать. Полностью согласен что теги надо использовать по назначению.
вы забыли указать что весь этот длинный код просто ушел в css файлик
Меньше HTML-кода:
<i class="img-cat"></i>
вместо
<img src="<?=$this->theme->baseUrl?>/images/cat.png" style="width: 64px; height: 64px;" />
Думаю, это будет действительно экономить время!
вы забыли указать что весь этот длинный код просто ушел в css файлик
Вы указали всего лишь один пункт из 4. И при этом довели его до абсурда.
Ну незнаю, имхо абсурд это использование тега курсива для вывода бекграунда чтобы имитировать картинку. Ну да бог с ним, кому как нравится, просто потом тяжело разгребать все эти хитросплетения верстальщиков, когда шаблон на проект натягиваешь и мозг рушится от нелогичных решений, которые еще надо заставить работать, да к ним еще и IE хаки под каждый недобраузер применить.
Можно кстаии вообще свой тег сделать, типа и ему в css-ки прописать:
Давно такое не пробовал, но помнится что в Опере лет 5 назад прокатывало — делал свои теги для отображения модулей внутри WYSIWYG редатора.
Про пункты… 1 пункт уже давно многими для веба используется (у гугла вроде как 1 спрайт на всё), конечно всё подряд в спрайты не напихать, но например хорошо подходит для круговых обзоров товаров (не помню как это правильно называется, когда мышкой крутишь, а объект как бы крутится по одной или 2м осям, т.е. просто огромный бэкграунд передвигается), 2 пункт вытекает из первого, 3 пункт — раздутая css-ка или гора css-ок под каждый шаблон (но это не в коем слуучае не минус, у самого такая же штука, да и gzip никто не отменял)
Можно кстаии вообще свой тег сделать, типа и ему в css-ки прописать:
mycat {
width:
height:
background: url(tralalala)
}Давно такое не пробовал, но помнится что в Опере лет 5 назад прокатывало — делал свои теги для отображения модулей внутри WYSIWYG редатора.
Про пункты… 1 пункт уже давно многими для веба используется (у гугла вроде как 1 спрайт на всё), конечно всё подряд в спрайты не напихать, но например хорошо подходит для круговых обзоров товаров (не помню как это правильно называется, когда мышкой крутишь, а объект как бы крутится по одной или 2м осям, т.е. просто огромный бэкграунд передвигается), 2 пункт вытекает из первого, 3 пункт — раздутая css-ка или гора css-ок под каждый шаблон (но это не в коем слуучае не минус, у самого такая же штука, да и gzip никто не отменял)
Тоже думал о том, чтобы ввести свой тег. Возможно сделаю это вообще настройкой, чтобы каждый мог указать по своему вкусу. Но изначально ориентировался на Twitter Bootstrap, как на очень популярное решение.
UFO just landed and posted this here
Кстате для таких не хитрых программистов как вы, нормальный хитрый верстальщик засунет в этот тег знак пробела чтоб вы видели его и подумали 10 раз перед тем как удалить его.
О, Вы немного подправили коммент. Думаю это хороший вариант, чем не повод для пулл реквеста?
Полагаю, тег
<i> в качестве жертвы был выбран из-за намеков на слова «icon» или «image». Кто-то курсив и тегом <em> делает
Для курсива уже используется em Для курсива i использовать уже не верно вроде бы как)
Не совсем верно, он всё также в строю, просто теперь у него сузилась семантика.
UFO just landed and posted this here
Вы в большей части бекенд программист?
Да.
Из чего вывод сделали, если не секрет?
Из чего вывод сделали, если не секрет?
Я фронтенд разработчик и сразу видно программиста когда он начинает рассуждать о тегах, css и подобных вещах. И часто видно что им встречается работа только плохих фронтенд разработчиков.
Если бы был фронтэнд разработчик — тэги и css были бы его головной болью. Я бы только контроеллеры-модельки пописывал. :)
Но нас есть верстальщик, на нем верстка + немного js, слайдеры, окошки и т.п. Я думаю фронтэнд разработчик это гораздо более широкое понятие. А вот верстальщик, да, видно что делает лишь бы выглядело как на макете и во всех браузерах. Порой кажется, что он даже не понимает как этот код потом будет преобразован во view. И что надо делать чтоб он был удобен в использовании, максимально стойким к правкам, которые всегда есть и будут.
Сейчас понемногу собираю материалы по верстке (хотя сам в ней довольно слаб) обязательные для ознакомления верстальщикам.
Но нас есть верстальщик, на нем верстка + немного js, слайдеры, окошки и т.п. Я думаю фронтэнд разработчик это гораздо более широкое понятие. А вот верстальщик, да, видно что делает лишь бы выглядело как на макете и во всех браузерах. Порой кажется, что он даже не понимает как этот код потом будет преобразован во view. И что надо делать чтоб он был удобен в использовании, максимально стойким к правкам, которые всегда есть и будут.
Сейчас понемногу собираю материалы по верстке (хотя сам в ней довольно слаб) обязательные для ознакомления верстальщикам.
А почему бы верстальщику не делать сразу во вьюхах код? Потом будет гораздо проще заменять текстовую рыбу на переменные. Правда здесь надо очень хорошо понимать что и в каком виде придёт в шаблон.
Я вообще против того, чтобы отдавать в интеграцию чистый html.
По поводу материалов можем пообщаться отдельно, у меня тоже есть мысли на этот счёт, но с другой стороны баррикад.
Я вообще против того, чтобы отдавать в интеграцию чистый html.
По поводу материалов можем пообщаться отдельно, у меня тоже есть мысли на этот счёт, но с другой стороны баррикад.
Я для генерации спрайтов использую glue, для автоматического расчёта размеров rails-sass-images
Там всё красиво + retina
Раньше compass'ом баловался, но он перестал быть актуальным чуть менее чем полностью
Для тестовых картинок http://placekitten.com/ & http://lorempixel.com/
Там всё красиво + retina
Раньше compass'ом баловался, но он перестал быть актуальным чуть менее чем полностью
Для тестовых картинок http://placekitten.com/ & http://lorempixel.com/
Хорошие инструменты, смотрел на них перед написанием либы. Но рассмотренная либа даёт ощутимо больше возможностей.
Можно уточнение в чем же потеряна актуальность компасса?
Например, добрая половина миксинов заменяется этим https://github.com/ai/autoprefixer
Вы так говорите, будто Compass — это только ценный мех работа с префиксами.
А что там такого ещё есть выдающегося?
Вполне хорошо живётся с http://bourbon.io/docs/ + compass для rails 4 нестабилен
Вполне хорошо живётся с http://bourbon.io/docs/ + compass для rails 4 нестабилен
UFO just landed and posted this here
мне тоже кажется что по сравнению с компасом это неочень…
Не видел у них поддержки :hover, плюс хотелось реализации именно в стиле Twitter Bootstrap.
В спрайтах у compass есть «magic selectors» :hover, :active, :target http://compass-style.org/help/tutorials/spriting/magic-selectors/
Кстати, в 3-ем бутстрапе иконочки вынесены в отдельный репозиторий и тег
http://glyphicons.getbootstrap.com/
<i> заменён на <span>http://glyphicons.getbootstrap.com/
Отлично! Предложение перейти на <span> уже звучало несколько раз. И я добавил апдейтом в пост, что планирую сделать это изменение.
То-есть из-за того что функция возвращает список тегов развернулся эпичный срач какой тег юзать? (я не нашел больше в коде нигде теги)
Интересует простой китайский вопрос — а на хуа? Куда потом этот список тегов юзать, кроме как для примера?
Ну и сразу чтобы два раза не вставать — а чем compass не в стиле бутстрапа, раз ховер и компанию уже нашли?
Интересует простой китайский вопрос — а на хуа? Куда потом этот список тегов юзать, кроме как для примера?
Ну и сразу чтобы два раза не вставать — а чем compass не в стиле бутстрапа, раз ховер и компанию уже нашли?
Если картинка несет смысловое значение (относится к тесту) то следует использовать отдельные файлы изображений, тэг
Если же картинка играет роль иконки, бэкграунда и не несет смыслового значения, то лучше всего задавать ее в качестве
При этом очистить html-код от мусорных тегов, вроде предложенных вами
Генерация спрайтов — задача тривиальная и решенная уже много-много раз (полный список решений). Тем более, последнее время использование
Так, собственно вопрос, зачем еще одно решение задаче, которая уже давно решена?
img с аттрибутом alt. Если же картинка играет роль иконки, бэкграунда и не несет смыслового значения, то лучше всего задавать ее в качестве
background-image для нужного тега. (найдено на stackoverflow)При этом очистить html-код от мусорных тегов, вроде предложенных вами
<i class="some-image"></i> или предложенных в комментириях <span class="some-image"></span> помогут псевдоэлементы ::before и ::after коих целых 2 на каждый тег (за исключением input)Генерация спрайтов — задача тривиальная и решенная уже много-много раз (полный список решений). Тем более, последнее время использование
data:uri считается более лучшим, так как экономит память и количество запросов к серверу, и, в качестве бонуса, избавляет от головной боли слежения за версией спрайта (если сайт обновляется и с некоторой периодичностью в спрайт добавляются новые иконки).Так, собственно вопрос, зачем еще одно решение задаче, которая уже давно решена?
Если все ради того, чтобы ускорить набор кода, то я вам советую выбрать хороший редактор. Например: webstorm с плагином emmet, live templates и автоматической подстановкой (включая размеры картинок) по клавише
tab UFO just landed and posted this here
Не стал вдаваться в поддробности по поводу тегов без псевдоэлементов, спасибо за дополнение.
А по поводу иконок — опять таки, если иконка прямо относится к тексту, то используйте img, если нет — все что угодно, но при этом по возможности семантично (лишние теги плодить не имеет смысла).
И, кстати, забыл упомянуть, что если верстка проекта нацелена на хорошие браузеры (IE9+) то есть еще возможность использовать множественные бэкграунды, для избавления от лишних тегов.
А по поводу иконок — опять таки, если иконка прямо относится к тексту, то используйте img, если нет — все что угодно, но при этом по возможности семантично (лишние теги плодить не имеет смысла).
И, кстати, забыл упомянуть, что если верстка проекта нацелена на хорошие браузеры (IE9+) то есть еще возможность использовать множественные бэкграунды, для избавления от лишних тегов.
data:uri бесспорно интересная технология, но в FF и IE работает далеко не оптимально. И этим никак нельзя принебречь. А за версией спрайта мне кажется следить очень просто: по времени его создания и времени обновления директории с исходными изображениями. Вот Вам и один из плюсов моего велосипеда :)
Для большей нагядности приведу пример кода из документации:
abstract class BaseController
{
public function init()
{
...
if (APP_ENV === APP_ENV_DEV) {
Yii::app()->sprite->generate(); // Regenerates sprite only if source dir was changed
}
...
}
}Склонен не доверять результатам данного теста, тесты какие-то слишком синтетические. Я ради эксперимента провел аналогичный сравнительный анализ на одном из последних своих проектов: два теста на двух сборках проекта — одна с картинками в файлах, другая с картинками в
data:uri (в data:uri добавлялись только иконки, причем оптимизированные с помощью imageOptim, размер не более 2х кб на каждую). И результаты в FF (версии 21, 22) получились ровным счетом обратные, в сборке с data:uri событие window.onload срабатывало в среднем в 3-4 раза быстрее. Для чистоты эксперимента — в Сhrome и FF nightly 25.0a1 data:uri быстрее в 2 разаСегодня в этом уже нет никакого смысла. Просто настройте себе HTTP/2
Sign up to leave a comment.
Bootstrap CSS Sprite: синтаксический сахар для <img />