Именуем картинки с умом

[@sse]

Спасибо. Это как раз тот случай, когда какая угодно система (в именовании) лучше, чем ее отсутствие :) А вот будет ли оно так, как вы указали, или что-то самостоятельно придуманное, большого значения не имеет.

[@eremin]

Да было бы здорово если бы все разработчики договорились именовать картинки каким-то одним способом (возможно и отличающимся от нашего, это не принципиально). Такая, казалось бы, мелочь как соглашение о именовании картинок занимает минут 10 на освоение, но увеличивает КПД разработчика (пускай и не сильно) в каждом проекте.

[@kutsy]

Супер.

[@KrasivayaSvo]

Спасибо за заметку: я тут как раз давеча искал приемлемый способ именования картинок.
Я бы предложил в

[название_]назначение[_вложенность][_фон][_позиция][_размер][_активность].расширение

поменять местами название и назначение.
Получится

назначение[_название][_вложенность][_фон][_позиция][_размер][_активность].расширение

Просто как-то уже так сложилось в программировании, что чаще всего сначала идут обязательные параметры, а потом вторичные.
Хотя это на любителя.

[@eremin]

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

И мне кажется, допустим, название
myproject_logo_bg_bl_s.jpg

воспринималось бы лучше, чем:
logo_myproject_bg_bl_s.jpg

Хотя, это кому как больше нравится :)

[@KrasivayaSvo]

Ну это на самом деле на любителя.
В любом случае спасибо, за такую простую идею…

[@Evengard]

В данном случае помоему лучше сначала писать именно назначение — оно получается как подкласс изображения, и в файл(фтп)-менеджере эти файлы удобно отсортируются по этому самому типу: вместе все лого, вместе все сервисные, и тд… И не надо искать где у вас там хранятся картинки связанные с заголовками

[@eremin]

кстати, очень интересный аргумент по поводу сортировки! Возможно действительно исходя из этих соображений лучше назначение картинки выносить вперёд. Я подумаю :)

[@eremin]

вынес назначение на первое место

[@Poiser]

А как насчёт создания стандартной структуры папок для изображений, а названия самих картинок делать односложными? Имхо это будет удобнее и понятнее чем файл с названием — hui_logo_sub_t_m_cur.jpg когда будешь смотреть на него через год? :)

[@BaBL]

если у вас AllowOverride включен, то при таком запросе апач каждую эту папку будет еще проверять на наличине .htaccess, если сервер загружен — может стать проблемой и прилично опустить планку хабраэффекта.

если изображения работают в скриптах, с именами работать проще, чем со структурами папок, тем более что часто еще придется экранировать слеши. Да и в css пути «относительные», натыкался на косяки. Еще трабла с img upload'ом дополнительная, это фактически вместо линейной галереи альбомную иерархическую городить придется.

[@danko]

Ну так AllowOverride можно вырубить персонально для дерева каталогов с картинками, там обычно всё равно ничего, кроме граф.файлов не лежит.

[@deepsweet]

уже давно использую схему:
…
bg_widget_main
bg_widget_bottom
bg_top
button_send
icon_cart
…

[@kachkaev]

Я примерно к такой же системе пришёл, только вместо первого знака подчёркивания у меня слеш, картинки раскиданы по папкам. Так легче ориентироваться, если проект крупный, либо дизайн нагромождён элементами декора. Структура папок всегда примерно одна и та же: bgs, btns, icons, sprites, stars, text, etc. Ещё есть папка temp на стадии вёрстки, куда кидаются всякие «набивочные» картинки. Эта папка потом стирается. Корневая папка для всех изображений имеет название i, всё-таки такое сокращение экономит немножко.

[@lehha]

Вот с составленной по этому топику именами точно будет не разобраться. Я делаю еще проще: 0_1.gif — первая цифра обозначает ряд, вторая номер элемента. Вполне хватает для нарезки 5-7 рядов. (line, header, logo, menu, body, adv, copyleft)

[@kachkaev]

Такие названия — ад для тех, кому потребуется потом во всем этом разбираться и что-то менять.

[@XaBoK]

я использую немного другой принцип:
страница(home)_назначение(logo)_тип(tx/bg/hr)_позицияХ_позицияУ.расширение

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

[@danko]

А если картинка используется на нескольких страницах? :)

[@XaBoK]

У меня такого нет. Скорее всего контроль используется на нескольких страницах — тогда указываю имя контроля. Кстати моя специфика WAP — отсюда и Х.У и отсутствие повторов.

[@Enlightened]

Я пришел к именованию картинок так же как классы в CSS. Например, есть блок страницы, ну… пусть будет логотип. У него есть класс .b-logo. Не мудрствуя лукаво, называем картинку с логотипом b-logo.png. И все, запутаться невозможно:)

А всякие дополнительные штуки, типа теней и круглых уголков — ближайший-поименованный-блок_rounded_bl.png. (левый нижний круглый уголок у блока «ближайший поименованный-блок»).

[@dzlk]

А если картинка пару раз используется или больше в самых отдаленных друг от друга местах

[@Enlightened]

А вы для оформления одинаковых блоков используете разные классы?:)

Если у вас используется одна и та же картинка для блоков с разными классами — вам стоит изменить подход к именованию классов, по-моему.

[@dzlk]

А блоки могут быть абсолютно разными, а картинка одна.

[@Enlightened]

Картинка — это оформление. Если у двух блоков одинаковое оформление (пусть и частично) — я общую часть оформления (эту самую картинку) вынесу в отдельный класс.

Ничто не мешает сделать блок с двумя классам вроде: .b-sidebox .b-latest-news

[@TonyClifton]

Я обычно использую спрайты (засовываю как можно больше картинок в одну), но CSS-классы называю примерно так, как вы написали.

[@GreyCat]

Во-во. Вроде бы уже 2010 год на дворе, а люди всё ещё картинки нарезают. Впрочем, для CSS sprites будет всё равно актуальна система в наименовании классов — так что вся эта иерархия неплохо переносится туда ;)

[@xdevel]

Давно использую именование картинок/файлов по определенной системе.
можно так же некоторые функциональные элементы так же расскладывать по папкам.
допустим, все что относится к шапке в папку header и уже опустить это в названии файла
а если использовать систему на сквозь во всех проектах (следовать ей) то написание проект от проекта становится все приятней :) даже некоторые элементы могут путешествовать из проекта в проект ( те же иконки для админки)

[@Spree]

hz_button_s — маленькая кнопка, непонятно зачем нужная )

[@pvasili]

примеров бы побольше…

[@w0lf]

hz — это пять. только не совсем понятно что это значит в терминах автора («hрен zнает» или «h*й zабей»)

[@eremin]

Хрен знает :)
Можно объявить конкурс, кто оригинальнее именует элементы, назначение которых сложно определить. Положа руку на сердце, скажу, что обычно мы пользуемся паттерном hueta_*, но в статье мы решили быть более политкорректными что ли :)

[@BaBL]

использую подобную схему сам, но в вашей вижу косяки и неоднозначность. К примеру icon_l.gif — это иконка слева (left) или большая (large)?

[@BaBL]

ну и еще ваша схема оказывается несколько не у дел, когда используются спрайты. Я обычно стараюсь максимально заспрайтить графику, обычно 2-3 спрайта и несколько мелких картинок, которые по разным причинам невыгодно пихать в спрайт, получаются в итоге.

[@eremin]

спасибо, насчёт _l вы верно заметили. Сейчас исправлю.

[@Bis]

Используя практически такие же обозначения

[@danko]

Я так понимаю, эта схема среди всего прочего, должна как-то упрощать читаемость всей этой россыпи картинок в виде списка файлов? Тогда название однозначно не может идти первым, потому что это будет полный винегрет. Первым должно быть «назначение», а название вообще лучше убрать в самый конец :) Тогда при сортировке по имени мы будем иметь хоть какую-то структуризацию, а если первым будет название — это не даст вообще никаких выгод.

[@eremin]

да, вы правы, название передвинул на второе место

[@IJIL]

Я очень люблю читать oil and gas eurasia, у нас в институте раздают их бесплатно.
В этом журнале после статьи на Английском идет сразу же статья на Русском.
Очень поучительно если не особо знаешь иностранный.
Мне кажется вам обязательно нужно сделать что-нибудь подобное,
тем более у вас в конце журнала много статей не посвящены обучению Английскому.

[@eremin]

спасибо за информацию! Правда совершенно не понял о чём вы…

[@dzlk]

А почему подчеркивание, а не дефисы?

[@juliv]

это дело привычки.
для меня тоже удобнее дефисы.

[@dzlk]

Я просто прочитал все комменты и все используют подчеркивание, вот и закралось, что что-то неладное =)

[@smileonl]

WSG Russia всегда была за дефисы в названиях.

[@dzlk]

Чем обусловлено, привычкой, или чем-то другим?

[@pepelsbey]

Хе-хе, да — именно!

[@kachkaev]

Когда название идёт первым, это очень нехорошо. Гораздо удобнее первым писать назначение картинки (фон, кнопка, и т. д.). Представьте, что вам через полгода потребуется найти изображение фона со всякими вензелями. Вы будете искать на букву «в»? А если это называлось не вензеля, а кренделя? Ещё и на «к» поищите. А потом на «р» (рюшечки) и т. д. Короче, потеря времени. Лучше всегда фон искать на букву «b» (background), и быстренько выбрать нужную картинку из 2-5 с одним префиксом. А ещё лучше — раскидать изображения разного назначения по разным подпапкам.

[@eremin]

обновил статью, теперь назначение идёт первым

[@kachkaev]

Какой Вы хитрый. =) Теперь Вы пишите:

назначение[_название][_вложенность][_фон][_позиция][_размер][_активность].расширение

Почему название — опциональный элемент? Должно быть уж тогда так:
[назначение]_название[_вложенность]…

Почему первое подчёркивание перед названием после кавычки? Чтобы все неклассифицированные элементы были рядом друг с другом, а не «просачивались» между кнопок, фоновых картинок и т. д. Но тут опять косяк — Ubuntu, например, сортирует файлы невзирая на подчёркивание, идущее первым (кто знает, как это отключить?). В любом случае лучше раскидывать разные изображение по разным папкам, я об этом уже писал выше.

[@neJa]

сори, но я не вижу смысла в таких извращениях… зачем нужны приставки «вложенности», «размера», «позиции», «активности»? Первые две вообще непонятны. Третья — старайтесь не привязываться к позиции чего-либо на странице, если у вас есть две иконки — одна слева, другая справа, как будете называть? Или будете резать две? Тоже относится и к классам/id в HTML. Четвертая — «активность», правилом хорошего тона является использование спрайтов для всяких ховерных/активных состояний.
ЗЫ. приставка «hz» — улыбнуло. Интересно, не русскоязычный заказчик за всю свою жизнь сможет понять что это значит? ))

[@Zarohan]

представляю:
hz_button_hz_hz_tl_s_hz.png

а если серьезно — любая систематизация однозначный плюс, спасибо за идею.

[@EzS]

А можно сделать грамотно и всё запихнуть в <a href=«habrahabr.ru/blogs/client_side_optimization/18730/'>спрайт и не забивать себе голову мелочами -)

[@pepelsbey]

Насчёт конфликта left / large — делать «la» имеет только в том случае, если вы пишете парсер и вам нужна однозначность. В случае с обычной вёрсткой, вы сами поймёте что имеется в виду. Ведь если есть large, значит есть что-то другое. Как обычно случается и с left.

Как выше правильно заметили — любая система лучше, чем никакой.
А тут ещё всё удачно и без фанатизма. Ну, минус подчёркивания вместо дефисов ;)

[@eremin]

Учёл многочисленные комментарии по поводу дефисов вместо подчёркиваний. Теперь в статье описано 2 варианта именования — с дефисами и подчёркиваниями. Также обновил демонстрационный скрипт.

[@ZaiSL]

А у меня вообще такая привычка: при разработке раскидываю всю графику по стандартному набору папок:
1. layout — здесь графика для глобальных элементов разметки (основной бэграунд и все остальное того же типа). Здесь картинки обычно именуются по принципу: [идентификатор_класса].png/jpg
2. elements — это всякие стрелочки, кружочки, иконки. Эта графика обычно используется очень часто и встречается во всех разделах сайта. Такие картинки предпочитаю называть интуитивно понятными именами, по принципу: что видим, так и называем
3. buttons — кнопки
Еще бывают папки «специального» назначения. Например, графику для слайдшоу на главной странице сайта я предпочту уложить в директорию «slideshow» и т.п.