Прошу профессионалов покритиковать верстку
2195 повідомлень
#17 років тому
Встретил в статье упоминание lynx - очень хороший способ проверить качество верстки и отличить "семантическую" от не оной.Насчет именно lynx не скажу, но знаю много людей, пользующихся текстовым браузером links чуть ли не как основным. С некоторых пор в обязательном порядке проверяю каждую работу по верстке в этом браузере.
Оффтопик
Цитата:
А зачем вы смотрите в html код?
Пользователь не должен этого делать.
Деревья же - по мне те же "nested sets" очень удобно представлять в html <ul> списком, а во многих проектах да та же структура сайта в таком виде в базе лежит.
А я с этим не согласен, по-моему, наоборот, использование лишнего тега <li> нелогично, только отвлекает от пунктов меню при просмотре HTML кода.
А зачем вы смотрите в html код?

Деревья же - по мне те же "nested sets" очень удобно представлять в html <ul> списком, а во многих проектах да та же структура сайта в таком виде в базе лежит.
Куда-то далеко я отвлекся от этой верстки, извиняюсь.
tvv, еще раз спасибо за критику. Возможно, действительно, кому-то из начинающих верстальщиков будет интересно о двух разных разных подходах и подтолкнет к тому или иному.)
3240 повідомлень
#17 років тому
Оффтопик
Постараюсь объяснить свой подход.
Я - программист.
И понятие семантики в программировании так же важно и актуально, как и в верстке.
Но когда я вижу код, соответствующий рекомендациям семантически языка, и который занимает, скажем, 200 строк, но который можно было бы без потери наглядности (а то и сделав намного более понятным и наглядным) сократить, скажем, до одного экрана, мой выбор будет однозначным, выберу более компактный вариант.
Почему?
Я не только программист, но также еще и веду свой бизнес (фриланс - это бизнес), то есть стараюсь считать деньги, как свои, так и деньги заказчика.
Компактный небольшой кусок кода я:
а) быстрее напишу
б) его намного проще отладить, так как в нем соответственно будет меньше дефектов
в) как ни странно, в нем будет проще разобраться другим, прежде всего, потому что кода-то меньше на экране, не нужно взад-вперед пролистывать, достаточно откинуться на спинку кресла и замедитировать перед экраном
г) и т.д.
Это все выразится в том, что будет экономия времени, а соответственно и денег.
Объясню на примере. Вот пример рекомендаций с точки зрения семантики в программировании на Java:
if ("0".equals(param)) {
......return null;
}
return param;
А по мне, более логичным вариантом, и я так всегда и делаю (ух, чувствую как некоторые морщатся), было бы использовать:
return "0".equals(param) ? null : param;
Прошу прощения, я тоже отвлекся от верстки...
Я - программист.
И понятие семантики в программировании так же важно и актуально, как и в верстке.
Но когда я вижу код, соответствующий рекомендациям семантически языка, и который занимает, скажем, 200 строк, но который можно было бы без потери наглядности (а то и сделав намного более понятным и наглядным) сократить, скажем, до одного экрана, мой выбор будет однозначным, выберу более компактный вариант.
Почему?
Я не только программист, но также еще и веду свой бизнес (фриланс - это бизнес), то есть стараюсь считать деньги, как свои, так и деньги заказчика.
Компактный небольшой кусок кода я:
а) быстрее напишу
б) его намного проще отладить, так как в нем соответственно будет меньше дефектов
в) как ни странно, в нем будет проще разобраться другим, прежде всего, потому что кода-то меньше на экране, не нужно взад-вперед пролистывать, достаточно откинуться на спинку кресла и замедитировать перед экраном
г) и т.д.
Это все выразится в том, что будет экономия времени, а соответственно и денег.
Объясню на примере. Вот пример рекомендаций с точки зрения семантики в программировании на Java:
if ("0".equals(param)) {
......return null;
}
return param;
А по мне, более логичным вариантом, и я так всегда и делаю (ух, чувствую как некоторые морщатся), было бы использовать:
return "0".equals(param) ? null : param;
Прошу прощения, я тоже отвлекся от верстки...
2195 повідомлень
#17 років тому
Понимаю и практически полностью согласен. К сожалению, пока не могу побороть свой серьезный недостаток - отвлекаюсь в работе на мелочи - не забыть добавить в форму fieldset, сделать те же "вертикально позиционированные превьюшки" и т.д., что негативно сказывается на сроках. Но именно это отвлечение на мелочи в свое время привело меня без каких-либо внутренних войн сначала к бестабличной верстке, а позже к семантике.
18 повідомлень
#17 років тому

FF 2.0+, правый нижний угол - наслоение блоков.
tvv, не поверите, как издалека видно, что Вы верстали мало, КРАЙНЕ мало, чтобы воспринимать ваши посты серъёзно...
2195 повідомлень
#17 років тому
slang, у вас плагин с баннероубивалкой? 
Но на самом деле, конечно, вот тут как раз видно, что неправильно выбрана модель разметки - правая колонка с position:absolute и с исчезновением баннера происходит то что на экране.
Новый макет полностью резиновый - то что есть править не стал.
3240 повідомлень
#17 років тому
Цитата ("slang"):tvv, не поверите, как издалека видно, что Вы верстали мало, КРАЙНЕ мало, чтобы воспринимать ваши посты серъёзно...
Издалека видно... что издалека видите - пожалуйста держите при себе, тем более что о моем опыте Вы не знаете практически ничего, так же как и я о Вашем. Если я в чем-то в своих постах по Вашему мнению не прав, из чего следует моя нижайшая квалификация и неопытность, пожалуйста напишите в чем именно я не прав, аргументируйте, как это делает Sir_Michael, вот тогда это будет ответ по существу, а не голословное беспочвенное утверждение.
К слову, к тому моменту, когда Вы только поступили в универ в 2000 году, я уже 2 года профессионально занимался в том числе и версткой, работая фултайм. Но пальцы я конечно гнуть не стану, тем более что последние годы этим занимаюсь реже чем раньше, как и писал выше.
Но даже если я бы и был полным новичком в верстке, все равно. В данном топике ТС попросил общественность высказать критику, и я высказал свою критику. Кто не воспринимает ее серьезно - пусть воспринимает несерьезно, мне то что, хотя Ваше сообщение слегка задело.
18 повідомлень
#17 років тому
Sir_Michael, он установлен у большинства пользователей ФФ, ИМХО...tvv, то, что я поступил в университет, никак не сказывается на моём опыте вёрстки, более того, кто Вам сказал, что я два года до этого ничем не занимался?
Касательно Ваших утверждений, поверстайте усиленно своими минималистическими методами под ие5, сафари2, текстовые браузеры и линуксовый софт, поймёте значение "лишних" тегов, или Вы всё также уверенны что все остальные заговор против Вас устроили и специально делают всё назло с лишними тегами?
А пост задел, потому что должен был задеть, так же как и Ваш, о том, что:
Цитата:
Где-то 15-20% используемых в верстке тегов - лишние, без них можно обойтись
поверьте, иначе вообще бы не обратил внимания на брызженье слюной...
582 повідомлення
#17 років тому
Sir_Michael, при увеличении шрифта в ИЕ и ФФ блоки тоже наезжают друг на друга (как на скриншоте)п.с.
Вообще я в шоке, от Вашего трудолюбия. ТрЫста - и не копейкой меньше.
3240 повідомлень
#17 років тому
Цитата ("slang"):поверьте, иначе вообще бы не обратил внимания на брызженье слюной...
slang, пожалуйста, старайтесь выбирать выражения, и будьте более тактичны и вежливы по отношению к другим пользователям Weblancer.net. Это я Вам уже как модератор данного ресурса говорю.
ТС создал эту тему, чтобы услышать критику. Я свое мнение высказал. Даже если оно было бы и совсем ошибочным, в чем проблема? Прокомментируйте, укажите на (по Вашему мнению) мои ошибки, но зачем сходу переходить на личности?
2195 повідомлень
#17 років тому
OxaDesign, спасибо.Если позволит заказчик, на следующей неделе выложу для критики вариант с эластичной версткой.
165 повідомлень
#17 років тому
1. Пустые <span></span> замените на <span><!-- --></span>2. В списках блока categories картинки стоит задавать не background, а через img. Так их проще менять, а скорее всего менятся будут. Это свойственно категориям.
3. Стили нужно вынести из кода в css.
4. У меня в FF блок morenews залез на фотки. Эт очень плохо!
Все кроме 4го пункта мелкие придирки. Молодцом!
2195 повідомлень
#17 років тому
adrianis, спасибо.Цитата:
1. Пустые <span></span> замените на <span><!-- --></span>
Когда-то думал об этом. Скажем, если бы это был <div> - тогда бы это было как-то так <div class="clear"><!-- --></div> а span'ы в image replacement оставляю как есть

Цитата:
2. В списках блока categories картинки стоит задавать не background, а через img. Так их проще менять, а скорее всего менятся будут. Это свойственно категориям.
Тут я поспорю

В css меняется не тяжелее чем в html:
#header .categories .map a {background:url(../images/categories/map.png) no-repeat}
Соответственно в программной части програмисту достаточно добавить или изменить класс.
Цитата:
3. Стили нужно вынести из кода в css.
А вот это не вижу - подскажите.
Цитата:
4. У меня в FF блок morenews залез на фотки. Эт очень плохо!
Знаю, ошибся, из-за абсолютного позиционирования правой колонки. В эластичном варианте исправлено - этот править уже не стал.
3240 повідомлень
#17 років тому
Sir_Michael, вопрос немного не по теме, скорее по бизнес-требованиям юзабилити. А нужна ли вообще тут резина по всей ширине? Поясню. У меня ширина экрана 1680px, и смотрится IMHO не очень хорошо, хотя еще терпимо, но если у кого-то возможно еще больше ширина будет... Может быть имело бы смысл ограничить максимальную ширину некоторым пределом? (это скорее заказчику решать, конечно)
2195 повідомлень
#17 років тому
Возможно. Этот вопрос еще не обсуждали.
18 повідомлень
#17 років тому
Цитата:Тут я поспорю Это не часть контента, а декоративное оформление. И как раз по причине, что может меняться - вынесено в css.
В css меняется не тяжелее чем в html:
Код:
#header .categories .map a {background:url(../images/categories/map.png) no-repeat}
Соответственно в программной части программисту достаточно добавить или изменить класс.
Скорее всего они будут генерироваться движком из базы, редактируемой в цмс, и не будут жёстко вписаны в шаблон. А при генерировании лучше использовать НЕ ЦСС метод, чтобы не выдумывать потом программистам велосипеды вроде "style.css.php", и не вставлять костыли типа переопределения стилей в ХТМЛ коде. Программисты - такие люди, которые не правят каждый раз руками 8)
Хотя, это, конечно же зависит от конкретного исполнения, и если портал с сапортом на простенькой ЦМС, то можно не заморачиваться.
2195 повідомлень
#17 років тому
Что для программиста сложнее - <img src="map.png" alt="" />|<img src="map-active.png" alt="" /> или <li class="map">|<li class="map-active">?Не нужно тут никаких костылей.
18 повідомлень
#17 років тому
Вы не поняли, название картинки обычно не константа, и задаётся динамически, текущим значением из базы, в первом случае, никаких сложностей, во втором же, это будет "мёртвая картинка" в шаблоне, которая уже не оживёт, если без костылей конечно...Следовательно, для программиста <li class="map">|<li class="map-active"> гораздо сложнее, чем <img src="map.png" alt="" />|<img src="map-active.png" alt="" />, если речь пойдёт о генерировании ХТМЛ, именно ХТМЛ, при статичном ЦСС, как это обычно бывает, и меняющейся картинке, т.е. её имени и пути. Можно конечно её заменять перезаписью файлов, но сложнее это объяснить потом контент-менеджеру, чем сделать через IMG. Вот о чём речь, или мы о разном?
Оффтопик
Пустые альты - дурной тон, ИМХО 8)
2195 повідомлень
#17 років тому
Видимо мы совсем о разном, потому что тут изображения категорий - исключительно декоративная часть. Смену картинок у категорий могу предположить в следующих случаях (хотя в этом проекте судя по всему подобного не будет):1 при наведении
2 категория - активная страница
И то и другое в программной части, как правило, задается сменой или заданием дополнительного класса элементу.
То есть, как бы я генерировал список категорий: если на сайте используется ЧПУ вида "/страница/", то делал бы что-то подобное:
Цитата:
<li class="{url}">
<a href="/{url}/">{category-name}</a>
</li>
<li class="{url} active">
<strong>{category-name}</strong>
</li>
А если бы это были изображения как элемент каталога, часть контента вот как фотографии - тогда разумеется было бы как img.
UPD. Все понял, вы про добавление/удаление категорий в админке. Я еще не знаю как будет реализовано тут, в моих работах подобный css (статический, не styles.php) подключается к основному через @import, а модифицируется он при создании/удалении/изменени элемента из админки - несколько строчек php кода.
Оффтопик
Когда-то был озабочен вопросом - в одной задаче был файл config.inc.php c списком начальных переменных, который инклудился к большинству скриптов.
Администратор же не был программистом. Пришлось сделать следующее (в общих чертах, чтобы была понятна идея) - каждую строчку привести к виду:
$GLOBALS='somevalue'; // А тут комментарий - описание поля.
И набросать простенький "web-интерфейс" для удобства пользователя - немного php, немного js - получил список input'ов с подробными описаниям, перемещением вверх-вниз для удобства и даже с возможностью группировки
Оказалось подобное решение с небольшими правками (уже без веб-интерфейса - просто процесс обработки файла) можно использовать и для генерации css - несколько строчек и простота интеграции в cms с незашифрованным исходным кодом.
Администратор же не был программистом. Пришлось сделать следующее (в общих чертах, чтобы была понятна идея) - каждую строчку привести к виду:
$GLOBALS='somevalue'; // А тут комментарий - описание поля.
И набросать простенький "web-интерфейс" для удобства пользователя - немного php, немного js - получил список input'ов с подробными описаниям, перемещением вверх-вниз для удобства и даже с возможностью группировки

Оказалось подобное решение с небольшими правками (уже без веб-интерфейса - просто процесс обработки файла) можно использовать и для генерации css - несколько строчек и простота интеграции в cms с незашифрованным исходным кодом.

Цитата:
Пустые альты - дурной тон, ИМХО 8)
Согласен. Пустые альты пристутствуют чаще всего когда img используется в оформлении - этого нужно избегать.
12 повідомлень
#17 років тому
Честно скажу, не вчитывался в посты выше, но:1) Код слабо читабелен. Кончено, отступы - это очень хорошо, но писать код через строчку - это чересчур. Никто не выигрывает от такого подхода. Я вот, например. никогда в списке ссылок не пишу на разных строках <li> и <a>
2) Семантически верно. Чувствуется труд верстальщика.
3) CSS код понравился. Грамотно оформлен, читать удобно и приятно.
В общем, сделано качественно.
2195 повідомлень
#17 років тому
overc, спасибо.Цитата:
1) Код слабо читабелен. Кончено, отступы - это очень хорошо, но писать код через строчку - это чересчур
Признаю, в ТОП100 я что-то совсем переборщил.
Уже задумался на досуге и решил на будущее делать так:
Если блочный элемент содержит inline-элементы с определенными классами, то допуcтимо разбивать на строки, если не содержит - разбивать скорее всего не стоит.