Leaderboard

Юморну)

Большинство запросов на рецензию верстки, в разделе Обсуждение работ, в результате имеют одни и теже ответы. Более 90% будущих разработчиков на начальном этапе допускают одни и теже ошибки. Типичные ошибки Запрещено имя класса начинать с цифры, или с дефица после которого следует цифра (пруфлинк: eng рус) Рекомендации Ниже я привожу список самых распространенных ошибок. CSS Не использовать #id для описания стилей блока. Почему-то одна из самых часто встречаемых ошибок -- это использование идентификатора вместо класса, для описания силей блока. Не надо этого делать. Давай мы с тобой определимся раз и на всегда с двумя простыми решениями: .class-name -- имена класов используются для того что бы описать стили блока. В 99,9% случаев программист не будет менять установленные верстальщиком имена классов. #id -- идентификаторы используются в JavaScript для того что бы передать в скрипт элемент и использовать его. Программист имеет право изменять имя идентификатора на своё усмотрение. Возьми за правило не использовать в вёрстке #id. В 99,9% случаев ты сможешь обойтись классами. 0,01% остаётся на уникальные ситуации и вероятность того что тебе такая попадётся, сам понимаешь, очень мала. Давай человеко-понятные имена классам. Когда ты именуешь какой либо класс придерживайся простых рекомендаций: класс должен быть набран латиницей правильно: ".block-reviews" не правильно: ".блок-отзывы" имя класса должно объяснять для чего данный элемент правильно: ".link-checkout" не правильно: ".link-highlight" используй переводчик для поиска англоязычных терминов правильно: ".discount-coupon" не правильно: ".kupon-skidki" не используй сокращений. Пускай имя класса будет длинее, зато его можно прочитать правильно: ".available.in-stock", ".block-shopping-cart" не правильно: ".avail.instk", ".blk-shopCart" не начинай классы с цыфры не правильно: ".7-element" не создавай индексированные классы. Для уточнения конкретного блока используй термины. правильно: ".comment", ".comment.first", ".comment.last", ".comment.highlight" не правильно: ".comment-1", ".comment-2", ... , ".comment-N" так же данный вопрос детальнее раскрыт в этом посте не используй верхний регистр в именах классов, не используй "camelCase" правильно: ".block-layered-navigation" не правильно: ".blockLayeredNavigation" здесь я рассказываю почему не стоит использовать "camelCase". Там же присутвует альтернативная точка зрения. Не описывай стили внутри аттрибута style="". Все стили, за некоторыми редкими исключениями, которые касаются элемента должны быть описаны в CSS файле. Давать всем элементам в коде уникальные имена классов(для непосредственного описания стилей каждого элемента на странице) избыточно. Но, если тебе попался сложный проэкт, который требует такого похода, то рекомендую перед тем как приступить к работе ознакомится с методологией БЭМ и понять как, в данном случае, правильно именовать классы. не указывай размеры картинок в стилях, для этого есть атрибуты тега <img> HTML Не используй комментарии в коде (<!-- comment -->). Лучше написать чистый код и дать ему человеко-понятные классы, нежели плодить комментарии, тем более на русском языке. Не надо везде где попало использовать тег <p> -- используй <div> или <span>. Тег <p> определяет текстовый абзац, а не часть разметки. Использование тега <nav> -- если тебе надо создать одноуровневое меню, то вместо иерархии "nav>ul>li>a" достаточно (и правильнее) использовать "nav>a" Логотип и тег <h1>. Начну с того что по умолчанию не обязательно помещать логотип в заголовок. Единственное где это уместно -- на страницах без заголовка, на пример -- "Главная страница". Такие страницы, как правило не имеют заголовка и содержат только промо контент. Но надо учесть что данный вопрос, все таки, по части SEO, т.е. -- индивидуален для каждого сайта. Приёмы Если надо вывести список данных с маркером, не надо генерировать маркер на стороне сервера. Вместо того что бы выводить: <li>- Возможность уточнять вопрос;</li> <li>- Моментальная публикация;</li> <li>- Гарантия получения ответа;</li> лучше использовать псевдо-элементы. Например: li:before { display: inline-block; vertical-align: middle; content: "-"; } На заметку Не обязательно применять свойство "display: block" в паре с "float: left" и/или "position: absolute (fixed)" -- это избыточно. Подробнее в этом посте Псевдо-элементы ":before" и ":after" по умолчанию отображаются как "display: inline;" Ресурсы, на которые стоит обратить внимание В первую очередь прочитай эту тему до конца, так как другие участники любезно делятся с тобой опытом. Гражданин с забавным ником Sorax Его канал на youtube: http://www.youtube.com/user/ArtSorax Его группа с vk: https://vk.com/soraxcss Системы контроля версий: git http://githowto.com/ , svn http://svnhowto.com/ , mercurial http://mkharitonov.net/hg/help/ru/ http://webfont.ru/ -- шикарный проект со шрифтами от товарища Softlink Методологиея БЭМ -- была разработана в Яндексе. Саму методологию в полном объеме использовать есть смысл на высоконагруженных проектах с большим трафиком, но из неё можно подчерпнуть массу ценной информации и использовать в проектах средней и низкой сложности. Рекомендую ознакомится. Ресурсы, которые не рекомендуются для обучения http://evgeniypopov.com/dvd.html - видео курсы от Евгения Попова http://2develop.ru/videokurs - видео курсы от Дмитрия Валака http://srs.myrusakov.ru/list Придерживаться или нет данных рекомендаций ложится на плечи разработчика. Если есть чем дополнить - предлагайте, так как список не окончен.

Хочу спросить у вас, какие плагины вы считаете необходимо знать для облегчения жизни верстальщику? Уметь их настраивать и вставлять на сайте. Кто может еще что посоветовать? Есть ли какие-то ошибки в моем списке (в плане более удобных и более популярных аналогов)? Из-за глюка форума пришлось в тег цитаты засунуть.

А почему, очень интересно? СЕО? Здесь верхний регистр относиться к стилистическому оформлению, следовательно лучше указывать это в стилях, нужно отделять представление страницы от содержания. Кроме того если вам понадобится эта строка в скриптах, то вам придется приводить ее к нижнему регистру или писать ее с капсом, что не совсем удобно. Так что это очень - очень плохо и так делать не надо. И еще к примеру если у вас ссылка написана капсом и она указывает на какую то страницу, то логично предположить что имя файла с этой страницей также должно быть написано капсом, а так выходит что у вас ABOUT US указывает на about_us.html, да и вообще навигация генерируется обычно на сервере и никто ее не будет писать в верхнем регистре чтобы она подобающим образом смотрелась в документе, я так думаю. А так конечно если имеешь дело со статичной страницей то может показаться, что это совсем и не важно, да и даже проще, просто взять и прописать все заглавными буквами.

мышка, мышка, дай мне паралакс Не понимаю, зачем давать ссылку на демо, если можно дать ссылку на github, где в настоящее время лежит почти все. Кроме того, на данный момент, почти все разработчики используют bower, что делает поиск еще проще. UPD: оказывается мой модуль на втором месте по популярности =)

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

http://caniuse.com/#search=border-radius ие9+ ff4+ chrome 5+ safari 5+ ios safari 5.0+ android 2.2+ Это поддержка без префиксная. Вполне достаточно, чтобы не замарачиваться

у каждого элемента есть дефолтное отображение(display). Если вы пишете это свойстве к элементу, значит вы хотите менять дефолтное значение на другое, указание этого свойство без значения, либо не даст ничего, либо приведет к ошибке. Синтаксис css уже не помню.

А почему вы решили, что не преуспеете ни в одном направлении, если возьмётесь за оба? Я вот например дизайнер и верстальщик. Рисую сайты, потом сразу верстаю. Постоянная практика. Да и верстка то уже столько лет почти не меняется. Что на ней сидеть то? Вот другое дело JS. Так что думайте об этом меньше и развивайтесь дальше. Удачи) «Предела нет» © Морфиус

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

2Даниил Виттманн 2 и 3 способ не очень корректны

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

Кто может еще что посоветовать? Есть ли какие-то ошибки в моем списке (в плане более удобных и более популярных аналогов)? Из-за глюка форума пришлось в тег цитаты засунуть. lightslider http://sachinchoolur.github.io/lightslider/examples.html GoUP http://ryuk87.github.io/jquery-goup/ skrollr http://prinzhorn.github.io/skrollr/ bootstrap validator https://github.com/nghuuphuoc/bootstrapvalidator вообще все что нужно, можно загуглить (иногда может не получатся, значит не то ищите)

вот интересная статья, но я бы советовал работать в UTF

Так ссылке назначен onclick + return false; то есть выполнилась функция, и возврат Ложь. Это тоже самое, что назначить ей preventDefault

Сделали тяп-ляп, работает и ладно... Чтож, я только за. Чем больше таких как вы, тем ценнее такие как я

Открой консоль хрома. Набери new Image() хром тебе ответит <img> new Audio() - <audio preload="auto"></audio>

mp3 можно запустить в ИЕ8, для этого вам нужно будет воспользоваться тегом <embed>. Если вы не хотите пользоваться готовыми решениями в этой области, то вы можете написать своё решение, которое будет определять версию ИЕ и подставлять <embed> вместо <audio>.

.checkitoutWrapper .checkoutSingle .sameAsBilling .sameAsBillingOverlay vc .checkitout .reviewContainer .formList .orderComments vc .checkitout .review-container .formList .order-comments ну или: .checkitout .checkout-step .gift-messages-form .allow-gift-messages-for-order-container .form-list .field, Между словами должны быть расстояние -- это обусловлено стандартом чтения текста. Чтение текста и его идентификация: и существенно отличны. И не будем забывать что мы, как правило, не читаем слова по-буквам, и читаем целиком. В месте где ожидается пробел он отсутствует. Вместо него Большая буква, которая визуально не равнозначна пробелу. Можно еще зацепить тему и сравнить "-" и "_" но это другая тема. Так же я опущу тот фак что вероятность допустить ошибку в имени, набирая код, camelcase больше чем в camel-case. Написанный код должен быть максимально простым для восприятия любым разработчиком. аЭтоГоворитОтомЧтоКодДолженБытьМаксимальноПриближенКстандартномуВосприятию разработчиком, то бишь человеком, который каждый день, утром, днем, вечером, ночью читает текст в интернете, в метро, маршрутке, этикетках, газетах, форумах, блогах, и прочих интернетах страны который имеет стандарт написания и является родственным, в отличии от остальныхАльтернативныхПредложеныхИТобществуФорматовНаписания. ps: моё имхо, основанное на моём личном опыте, является рекомендацией и только.