оцените верстку

chiffenok · November 10, 2012

Оцените, пожалуйста, верстку интернет магазина

3 страницы:

главная

каталог

товар

скрипты на верхние меню и на фильтр на странице каталога тоже делала я, знаю что не сильна в jquery но все же

gibigate · November 10, 2012

верстаю примерно также, норма

chiffenok · November 10, 2012

если вы так же верстаете то это не значит что норма )

gibigate · November 11, 2012

Ну что ж, я не хотел придиратся к мелочам. Тогда вот мои рекомендации:

1) Слишком много ненужных классов

В связи с этим огромный css файл, можно же использовать .class .childclass .childclass? Есть знаки > ~ +

Также такую верстку труднее внедрить в какой либо CMS

Вот это что такое вообще? Программист будет плакать кровью если увидит это.

.b-sub-category, .b-category__item, .b-category__link, .b-sub-category__item и т.д.

Почему не ul.class > li > ul > li ?

2) $(".i-arrow").css({"top": $( e.target ).offset().top - pad - 6 }); может так задумано, но у меня неправильно всплывают (хром)

3) margin: 0 4% 0 0;width: 200px;

Лучше не смешивать проценты с пикселями, запутаетесь

4) Насчет использования position:absolute, я лично не против их использования, но в одной из моих тем, меня наругали за их использование. Теперь не использую (в основном делаю адаптивные сайты + мультиязычные)

5) Ну и стандарт: по возможности скрипты лучше подключать в конце страницы

lexxcode · November 11, 2012

1) Слишком много ненужных классов
В связи с этим огромный css файл, можно же использовать .class .childclass .childclass? Есть знаки > ~ +
Также такую верстку труднее внедрить в какой либо CMS
Вот это что такое вообще? Программист будет плакать кровью если увидит это.
.b-sub-category, .b-category__item, .b-category__link, .b-sub-category__item и т.д.
Почему не ul.class > li > ul > li ?

Это называется верстать независимыми блоками, во-всяком случае присутствует явная попытка это сделать. Программисту ровным счетом ничего не будет. А огромный css не из-за количества классов, а по ущербности синтаксиса их написания а-ля БЭМ-style.

3) margin: 0 4% 0 0;width: 200px;
Лучше не смешивать проценты с пикселями, запутаетесь

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

4) Насчет использования position:absolute, я лично не против их использования, но в одной из моих тем, меня наругали за их использование. Теперь не использую (в основном делаю адаптивные сайты + мультиязычные)

pos:a полезная вещь, но его нужно использовать там где это действительно нужно. Не видел где вас ругали, но подозреваю обилие неоправданно абсолютно позиционированных элементов, вам на это указали. Но это не значит, что pos:a нельзя использовать вообще.

5) Ну и стандарт: по возможности скрипты лучше подключать в конце страницы

Где такой стандарт? Кто сказал, что нужно именно так? Вы знаете какие особенности подключения скриптов в head и в конце страницы?

chiffenok, у тебя <!DOCTYPE html>, а внутренности пошли отголоски от xhtml

в теге html лежит атрибут xmlns="http://www.w3.org/1999/xhtml", он там не нужен, да и смысла особо не имеет, вместо него стоит указать атрибут lang="ru"

в head <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> тоже перетерпел изменения теперь достаточно этого <meta charset="utf-8">

meta keywords и description на них практически не обращают внимания, а поскольку они даже не заполнены, то можно вообще смело кикнуть из кода.

в тегах script можно не писать type="text/javascript", так же как и в style type="text/css", но можно и оставить.

chiffenok · November 11, 2012

gibigate единственное что вам могу сказать в ответ не зря у вас отрицательная репутация... комментарии абсолютно не конструктивные из которых ни чего не понятно

у тебя <!DOCTYPE html>, а внутренности пошли отголоски от xhtml

да тут не поспоришь), но дело в том что такое было странное требование менеджера, что бы документ проходил валидацию xhtml но доктайп поставить httml5 , так что просто не будем принимать это в учет мне вот другое интересно вы написали:

Это называется верстать независимыми блоками, во-всяком случае присутствует явная попытка это сделать. Программисту ровным счетом ничего не будет. А огромный css не из-за количества классов, а по ущербности синтаксиса их написания а-ля БЭМ-style.

дело в том что я в этом деле почти самоучка(по этой статье bem, сейчас смотрю что они ее переоформили, нужно перечитать вдруг они ее дополнили) да и с помощью все того же странного менеджера, подскажите пожалуйста как это улучшить что был не а-ля ), буду очень благодарна

gibigate · November 11, 2012

Вы знаете какие особенности подключения скриптов в head и в конце страницы?

Отображение страницы быстрее

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

Потому что поплывет верстка если ширину элемента либо отступ изменить, или что либо еще. Если предполагается что будет резиновая, то %, если статичная ширина, то px(em)

pos:a полезная вещь, но его нужно использовать там где это действительно нужно. Не видел где вас ругали, но подозреваю обилие неоправданно абсолютно позиционированных элементов, вам на это указали. Но это не значит, что pos:a нельзя использовать вообще.

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

Где такой стандарт? Кто сказал, что нужно именно так?

ну тут вы просто придираетесь к словам, как я и писал выше, если поместить снизу, то структура быстрее грузится и отображается(чем например загрузить 100500 скриптов и потом генерировать структуру), иллюзия быстрого сайта. Бывает что надо загрузить в начале документа, не спорю, но в данном конкретном случае в скрипте стоит запись $(document).ready(function() { который все равно ждет полной загрузки документа.

Программисту ровным счетом ничего не будет.

Попробуйте это меню(которая генерируется из админки) натянуть например на вордпресс, вам все равно придется изменять стили.

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

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

Да и когда есть less, sass + семантика пропадает. Мое мнение, нафиг такой гемор

lexxcode · November 11, 2012

дело в том что я в этом деле почти самоучка(по этой статье bem, сейчас смотрю что они ее переоформили, нужно перечитать вдруг они ее дополнили) да и с помощью все того же странного менеджера, подскажите пожалуйста как это улучшить что был не а-ля ), буду очень благодарна

Предлагаю лучше ознакомиться с темой там было оооочень много обсуждений БЭМ.

Отображение страницы быстрее

ну тут вы просто придираетесь к словам, как я и писал выше, если поместить снизу, то структура быстрее грузится и отображается(чем например загрузить 100500 скриптов и потом генерировать структуру), иллюзия быстрого сайта. Бывает что надо загрузить в начале документа, не спорю, но в данном конкретном случае в скрипте стоит запись $(document).ready(function() { который все равно ждет полной загрузки документа.

Тесты, тесты и еще раз тесты!

Скрипты подключенные в head загрузятся и подключаться раньше чем те которые подключены в конце страницы, следовательно им останется только дождаться готовности DOM. Но это все только слова, нужны тесты, для того чтобы говорить, что быстрее. А так же это вопрос удобства, что тоже не мало важно, одним удобнее в head подключать, другим в конце страницы. Но! нет стандарта, что в head неправильно, а в конце страницы правильно, так же само и наоборот.

Попробуйте это меню(которая генерируется из админки) натянуть например на вордпресс, вам все равно придется изменять стили.

Обыкновенное меню. Тот же wp позволяет соорудить любое меню

Как называется сейчас вспомнил, но про это читал еще год назад на яндексе, да и думаю такой подход удобен для огромных сайтов, где работают не один верстальщик.
Да и когда есть less, sass + семантика пропадает. Мое мнение, нафиг такой гемор

В данном случае, вопрос не в целесообразности применения данного подхода, это другая тема, а в том, что вы накинулись с криками "Вот это что такое вообще? Программист будет плакать кровью если увидит это"

chiffenok · November 11, 2012

я хотела не много вклинится

Мое мнение, нафиг такой гемор

ну это всего лишь мнение, это требевоние менеджера

Попробуйте это меню(которая генерируется из админки) натянуть например на вордпресс, вам все равно придется изменять стили.

собствено то что я верстаю и так натягивается на цмс , токо это не вордпрес

ну и собственно это все не по теме, я просила оценить верстку

Viper · November 12, 2012

Тесты, тесты и еще раз тесты!
Скрипты подключенные в head загрузятся и подключаться раньше чем те которые подключены в конце страницы, следовательно им останется только дождаться готовности DOM. Но это все только слова, нужны тесты, для того чтобы говорить, что быстрее. А так же это вопрос удобства, что тоже не мало важно, одним удобнее в head подключать, другим в конце страницы. Но! нет стандарта, что в head неправильно, а в конце страницы правильно, так же само и наоборот.

По этому поводу хотелось бы дополнить: в конец body стоит подключать в том случае, если скрипты являются маловажным дополнением, относительно контента(DOM структуры) - рекомендуется в большинстве случаях. В head - когда скрипты являются основой страницы, например, js карты, ИМХО.

chiffenok · November 12, 2012

По этому поводу хотелось бы дополнить: в конец body стоит подключать в том случае, если скрипты являются маловажным дополнением, относительно контента(DOM структуры) - рекомендуется в большинстве случаях. В head - когда скрипты являются основой страницы, например, js карты, ИМХО.

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

Viper · November 12, 2012

мое имхо то что в head удобнее тем что когда работаешь в панели разработчика это более наглядно

Ну если ты разрабатываешь сайт для себя, а не для пользователей...

и по той же причине удобно что бы скрипты были в одном месте подключены

а так они будут не в одном месте?) Те же скрипты будут перед закрывающим </body>

chiffenok · November 12, 2012

что извините рядовой пользователь полезет в код что ле? alexriz, по-моему уже нормально оспорил что вы скрипты можно и там и там располагать, вопрос зависит от конкретных ситуаций, мне по требованием нужно в head располагать и да мне так удобнее

название темы помоему было оцените верстку, а не разведите спор где лучше крепить скрипты

Viper · November 12, 2012

что извините рядовой пользователь полезет в код что ле?

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

alexriz, по-моему уже нормально оспорил что вы скрипты можно и там и там располагать, вопрос зависит от конкретных ситуаций, мне по требованием нужно в head располагать

А кто оспаривал, что скрипты нельзя помещать в <head>? Или я говорил, что скрипты Именно ты должен был подключать в <body>? Укажи, пожалуйста, где я такое утверждал. Возможно, тебе следует перечитать еще разок мои комментарии.

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

Kray Storm · November 12, 2012

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

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

Простите, что влезаю в вашу творческую дискуссию...

Вопрос не в качестве критики, а именно для понимания.

А что мешает помещать такие "не срочные" скрипты "где удобно" - т.е. в <head> и использовать, например, атрибут <script defer>, который "придержит" скрипт до загрузки страницы?

Есть ли какие-то практические противопоказания?

Viper · November 12, 2012

А что мешает помещать такие "не срочные" скрипты "где удобно" - т.е. в <head> и использовать, например, атрибут <script defer>, который "придержит" скрипт до загрузки страницы?
Есть ли какие-то практические противопоказания?

Основное это: _http://caniuse.com/script-defer

Плюс небольшие(ИМХО) нюансы которые стоит соблюдать/понимать при использовании defer, которые тоже становились причиной отказаться от этого атрибута.

Tsybin · November 14, 2012

Элементы меню и разделы при масштабирование плывут и ведут себя очень странно. А так вроде всё вполне хорошо!

Sign In

оцените верстку

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Обсуждения

Important Information