Как стать автором
Обновить

Комментарии 69

Стилевые гиды, стилевые гиды - комментраии плять и ничто больше.
НЛО прилетело и опубликовало эту надпись здесь
В портале как раз таки из-за комментариев css-ка столько и будет весить. Кста, в тему - очень помогают всяческие компрессоры; имеешь читабельный оригинал, а подключаешь мин или пак.

В портале не одна css-ка, и доводить ее до истерики в 50Кб это уже слишком, проще разбить их на функциональные блоки и инклудить между собой...

Ну, все это конечно не значит, что гиды не нужны, просто большая часть приведенных примеров мне кажется весьма громоздкая...

Но все равно спасибо автору, коечто всеже возьму на заметку...
В той версии которая будет загружаться пользователями по хорошему не должно быть комментариев, но у разработчика обязательно должна оставаться версия с полным документированием.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Файрбаг чуть не захлебнулся с нее. Вы поглядите на нее подробнее.) Комментарии там вполне себе присутсвуют..
НЛО прилетело и опубликовало эту надпись здесь
Ага. Это просто ответ на вопрос. Если они есть - компрессором каким либо не пользовались. То что их мало это уже другой разговор.. К разработчикам собственно. =)
Ога, док-блоки тоже просто коментарии...их тоже не надо использовать.

Вообще, плохо, что нет стандарта, чтобы можно было им легко пользоваться в различных ИДЕ.
Я не стал бы вносить в комментарии техническую информацию о последнем редактировании, авторе и тд. С этим прекрасно справляется SVN.

Кстати, почему Cascading wtf Sheets внутри acronym?
Парсер лохе! Он styles так заменяет, это проблема разработчиков.
Да ладно! )) А если Style, без "s"?
На самом деле там Style написано, ты как администратор вроде бы можешь посмотреть исходный код.
Ну я не хотел лазить просто так, без повода... Вобще конечно цирк ))
Я тоже использую SVN и в принципе соглашусь, что эту информацию можно оставить на совесть SVN.
Напишу скоро свой styleguide, выложу на всеобщее обозрение. Спасибо за статью. Предлагаю перенести в Каскадные Таблицы Стилей.
Каждый должен писать так, как ему удобно. Если ты работаешь один с кодом, значит пиши так, как считаешь нужым - это и будет удобно.
Ну что ж за идиоты понижают карму и не пишут за что. Руки бы вам отстрелить за такое :)
Не стоит ругаться если вам понижают карму. Зло порождает зло. Карма не цель, а средство. Удачи.

Отсыпал вам кармы на всякий случай.
Во-первых очень редко бывает так, что работаешь с кодом только ты один. Не факт что через год заказчик вернется к тебе и разбираться в этом "удобстве" придется кому-то еще.

Во-вторых нужно руководствоваться не только удобством но и логикой, что собственно и определяет значение слова "styleguide", ведь вас никто не заставляет использовать чужие правила.

Напишите свои и придерживайтесь их. Дисциплина написания кода - основа успеха.
//Есть ещё более простой способ для который не использует вложенности

что-то аж прям как ножом по сердцу, поправьте пожалуйста.
Спасибо, исправил. Как додумался вставить «для» не представляю :)
Бывает:)
One think for developing bla bla bla - одна штука которая помогает разрабатывать блаблабла. "ДЛЯ" взялось отсюда:)
Я бы перевел styleguide как "соглашения по оформлению кода".
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за статью. Вдохновили меня на наведение порядка в стилях текущего проекта.

Интересный пример "стилевого гида", немного не то, но ,по-моему, тоже полезно.
Для меня сомнительна полезность комментариев вида:

> 2. Header / #header
> 3. Navigation / #navbar
> 4. Content / #content
> 5. Left column / #leftcolumn
> 6. Right column / #rightcolumn

Это же просто дублирование информации.
Это всего лишь пример, можете придумать собственную конструкцию.
Здесь, например, Header обозначает группу к которой относятся элементы. Чтобы найти эту группу в файле просто жмём ctrl-F и вбиваем название группы и автоматически перемещаемся к этому блоку в файле.
А что мешает вбить название #header в поиске и так же переместиться к нему? Всё дело в том, что в вашем CSS и так есть все нужные группирующие ID, разбивка на блоки помогает только визуальной навигации, как та же древовидность.
мало того! зачем содержание - не понимаю. все-равно нужно будет нажать ctrl+F и искать по ключевому слову (ну, класс, айдишник, свет...).
Считаю достаточным разбивать все по группам + визуальные разделители между группами.
Например, даёт представление о структуре.
Обычные камменты как и к разным функция в пхп том же, но все равно спасибо
Да, это всего лишь свод правил и соглашений как http://phpdoc.org/
ну впринцыпе да)
Стилевые гиды — эт конечно сильно. Как Промтом переводили.

Стайл гайды, просто «гайды», код-стайл — это ещё куда ни шло. Но лучше — оформление кода. Звучит менее круто, зато по-русски и не возникает сомнений о чём речь, ведь «стайл гайд» — это ещё и пресловутые «принципы использования фирменного стиля», разработкой которых стало модно заниматься.
Я решил использовать такое определение. В начале статьи я условился, что понимать под этим понятием в данном контексте.
Я отлично вас понял, но мне кажется, что данное определение достаточно косо.
Но, опять же — имхо. Приятно всё-таки говорить по-русски, вы не находите?
Не хотел бы дискутировать на тему личных предпочтений. Как вы сказали, у каждого своё имхо.
Суть же не в том как называются методы, а в том, в чём заключается их сущность и способы их использования?
Претензия была исключительно по поводу названия. И, да, я считаю, что это важно — называть вещи доступно пониманию, избегая любых смысловых ошибок и противоречий.
И всё равно полезного очень мало, особенно про самое важное — написание самих правил. Древовидность и порядок следования — это только верхушка айсберга. Пойду дописывать продолжение «CSS-менеджмента»… там как раз об этом.
Угодить всем невозможно. Кому-то больше, кому-то меньше.
Хотелось бы услышать что-то более полезное, чем "пишите побольше комментариев и структурируйте их". Извините, но это и ежу понятно, но от этого проще не становится. Если в компании существует отдел верстки, то конечно они могут себе позволить потратить 50% времени на написание комментариев, чтоб потом не объяснять коллегам что там и как, и самому не тратить много времени на рефакторинг. Но если у компании есть штат верстальщиков (или хотя бы один), то ему платят деньги, чтоб код был качественным и читаемым, и написание комментариев входит в его обязанности.

Лично я бы хотел здесь услышать советы для непрофессиональных верстальщиков - для веб-разработчиков, которым ко всему прочему приходится писать CSS, и они хотели бы сделать его удобным, простым и подвластным рефакторингу. Хотелось бы услышать о том как лучше называть классы, как их создавать, чтоб максимально использовать наследование, и пр. С нормальными названиями, и четкой структурой огромного колличества комментариев можно избежать.
НЛО прилетело и опубликовало эту надпись здесь
Гуру пока на отдыхе или спят :)
На этих выходных напишу )
для всех этих табов желателен большой, 24-х дюймовый (хотя бы) монитор.
НЛО прилетело и опубликовало эту надпись здесь
вы пошутили про 15"?
НЛО прилетело и опубликовало эту надпись здесь
если вы только начинаете, то простительно использовать то, что есть. было дело я и 14" работал.
в ином случае, задумайтесь о покупке нового моника. 17"-19" вполне доступны по ценам сейчас. зачем травмировать себя?
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
как то настораживает следующее:

"... но мы пока рассмотрим только несколько из них. ..... (и далее в коде или когда выключено отображение графики ..... "Внимание! Если вы видите данное изображение, то данная статья была несогласованно скопирована с ресурса http://blog.obout.ru/ С политикой копирования материалов с сайта http://blog.obout.ru можно ознакомиться на странице http://blog.obout.ru/copyright" ......."

И копирайтов что-то не заметил...
Извиняюсь за неудобство, не мог предположить что кто-то ещё отключает картинки. Как я заметил, вы пока ещё на хабре ничего не публиковали, поэтому не понимаете некоторую специфику публикации здесь статей. Дело в том, что хабрахабр очень хороший источник для различных автоматических агрегаторов и копипастеров, которые категорически отказываются идти на компромис. Я думаю другие авторы публикующие свои статьи из своего блога отнесутся пониманием. Поэтому я решил провести небольшой эксперимент с применением некоторой защиты, которую администрация не может предложить пока. Как вижу один побочный результат к сожалению есть.
Не люблю заниматься самопиаром и размещать ссылки на свой сайт, никогда этого не делал, но видимо придётся.
Дофига кто отключает. В смысле, в Москве - может и не отключают, а в России отключает подавляющее большинство. Нет там приличного анлима, иногда вообще никакого нет.
Да, вы правы. Я не публиковался. Не потому, что не хочу. Опыта мало. В основном читаю и набираюсь уму разуму. ;)
Сорри, не заметил "blog.obout.ru", что это ваш блог.
размер ксс вырастет втрое

лучше сделать отдельный файлик с описанием, раз на то пошло,
или деверский пусть будет с комментариями, а тот что в релизе, без коментариев и в одну строку ;)
Вы наверное читали через строку или не дочитали до PS. Там как раз этот момент затронут ;)
меня интересует страдает ли скорость от ниже указанной формы? Или лучше всё в одном файле?

style.css
@import "reset.css";
@import "layout.css";
@import "colors.css";
@import "typography.css";
@import "flash.css";
/* @import "debugging.css"; */

или всё в одном: style.css
быстрее загрузится когда 1 файл.
мы проверяли в последнем проекте.
у нас окола 30 CSS файлов.
когда собрали все во едино, получили прирост по загрузке стилей ощутимый.
то же самое и про JS файлы.

я, преимущественно, создаю один основной файл с набором стилей
и три файла под: IE, IE6, IE7 :D

мне этого хватает с головой для обычного сайта/портала.

что же по сабжу - интересная статья.
есть моменты в которых не вижу смысла (это имхо!)
но есть некоторые решения которые думаю буду использовать.

спасибо автору.
Можно обойтись двумя файлами, причем каждый браузер будет грузить только один файл.
При большем количестве подключенных файлов возрастает количество запросов к серверу и, как следствие, скорость.
В финальной версии (той которая будет уже на рабочем сервере) лучше грамотно объединять все модули в один файл. ИМХО, а в процессе разработки можно и использовать импортирование.
Мы так и делаем, причём CSS файлов у нас не единицы, а десятки и даже сотни.
Очень интересна показалась организация построения css файлов, которую описал в своем учебнике Сагалаев Иван.
Да и сам учебник, думаю, что для начинающих будет полезен.
btw, табы - зло.

Лучше пусть будет X пробелов.
Давно сформировал для себя собственный styleguide, однако теперь буду использовать ещё и “вложения” табами. :)

Спасибо!
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории