- HTML и CSS
- CSS3 shape-outside или обтекание картинки текстом
- Маштабируемый фон background css
- CSS выравнивание по вертикали
- Хранение картинок в css с помощью base64
- Как сделать ссылку, якорь?
- CSS3 для Internet Explirer 6 и старше
- Вёрстка для мобильных устройств
- Растягиваем html на всю страницу
- Таблица цветов CSS
- Выравнивание тега LI в контенте
- Оооох какой прекрасный box-sizing
- Делаем таблицу при помощи div и css
- Как сделать кросбраузерный linear-gradient без особых усилий
- CSS прозрачность для всех
- CSS для печати @media print
- Выравнивание блоков с помощью css {display: inline-block}
- Замечательное значение inherit
- Тень блочных элементов в CSS3
- Обводка текста с помощью CSS
- Полезные html символы
- Хаки или CSS для Internet Explorer-ов
- Делаем трёхуровневое меню на css
- jQuery, javaScript
- Устанавливаем на Яндекс Карте свою картинку вместо стандартной метки
- Адаптивные фотогалереи, слайдеры, карусели для сайта
- Узнаём координаты для установки скрипта Яндекс Карт
- Собственный фильтр для селекторов. Выбираем случайный элемент на jQuery
- closeClick true fancyBox 2, closeClick :true
- jquery ui slider, дробные числа, float values
- Парсер параметров из адресной строки jQuery
- Подсказки по javascript
- Выпадающее горизонтальное меню
- Работа с объектами в JavaScript: теория и практика
- Работа с массивами в jquery
- PHP
- Регулярные выражения онлайн
- Как определить путь к файлу текущего класса
- PHP скрипт для поиска. Удаление вируса с сайта
- UMI-CMS
- UMI CMS rel canonical
- UMI CMS API Шаблоны данных Добавить префикс к полю
- UMI CMS API Шаблоны данных Вывести текст из подсказки
- Если надо в UMI CMS открыть доступ к файлу в корне сайта htaccess
- Как перенести контент со старой UMI на новую UMI CMS с помощью umiDump
- Отправка письма с вложением UMI CMS API
- Как вывести из набор изображений одну картинку UMI CMS API (или случайную)
- UMI CMS Основные поля для отправки формы в модуле Конструктор форм
- Функции API UMI CMS для добавления, редактирования, удаления объектов каталога
- Функции API UMI CMS для добавления, редактирования, удаления объектов каталога
- UMI CMS Фильтрация спама на сайте
- Работа с набором изображений (multiple_image) TPL в UMI.CMS
- UMI CMS Ошибка "I expect value in request for param"
- UMI.CMS USEL кириллица не работает
- UMI Добавление дополнительных настроик на примере модуля catalog
- Подключение шаблонов в UMI.CMS в TPL шаблонизаторе
- UMI.CMS - забыл пароль администратора. Как восстановить?
- UMI Selector USEL фильтрация в PHP
- Передать в xslt xpath в запросе знак амперсанда
- Работа с system makeThumbnail
- Вывести названия методов в UMI
- UMI CMS API загрузка модуля
- UMI CMS карта сайта с помощью Usel
- UMI выгрузка из 1C поиск страницы копии, удаление копии
- Как в UMI.CMS изменить адрес домена в sitemap.xml и robots.txt. Изменить HTTP на HTTPS
- Вывод баннеров/слайдера в umi xslt
- UMI.CMS нет вкладок в админке
- XSLT вывод ссылки в которой присутствует знак амперсанда &
- UMI CMS Выгрузка из 1С нужно чтобы название товара (страницы каталога) не менялось
- Как в UMI поставить всем страницам галку на просмотр гостю
- Как узнать у страницы id шаблона данных через api?
- UMI.CMS работа с debug config.ini фильтрация по IP
- Как задать заголовок H1 (header) на странице созданного метода UMI CMS
- Выводим случайную статью в UMI CMS с помощью usel в tpl
- UMI.CMS Открыть закрытые поля в шаблонах данных ?skip-lock=1
- Как отредактировать облако тегов
- Как узнать позицию страницы среди соседних страниц в UMI
- umi cms usel вывод страниц каталога c фильтрацией
- Вывод справочника при помощи usel
- Как в umi узнать umiHierarchyElement из id umiObject
- Карта сайта на UMI CMS с помощью кастомного метода
- Редирект со страницы на страницу
- Создание, обслуживание, поддержка сайта
- Как удалить в картинке jpg, jpeg, gif? eval или base64_decode
- Основные технические ошибки, допускаемые при создании сайта
- Как выбрать домен?
- Хостинг, что это и для чего он нужен
- htaccess редиректы
- Наполнение сайта
- Цены на разработку сайта в Петербурге
- Какова может быть стоимость поддержки сайта?
- Важные мелочи!
- Каким должен быть сайт по версии яндекса
- 5 советов верстальщику
- Копирайтинг, seo, продвижение
- Ранжирование сайтов в поисковиках, выдача поисковых систем, поисковый алгоритм, поисковое ранжирование сайта
- Что нужно делать чтобы сайт был на первых местах?
- Копирайтинг - что это?
- Добавить сайты в индекс поисковых систем, регистрация в поисковиках
- Почему сайт не может приносить прибыль сразу?
- Почему следует вкладывать деньги в сайт?
- SEO статья о SEO-копирайтинге (seo copyrighting, seo copywriting). Кто seo копирайтер, что такое seo текст сайта, как помогают seo статьи и зачем нужна оптимизация?
- Как верстать сайт для SEO?
- Контекстная реклама
5 советов верстальщику
1. Не ищите лёгких путей при решении проблем.
Довольно часто при возникновении очередного бага в определённом браузере хочется проблему решить как можно скорее и такая возможность представляется. Самый банальный пример: какой-то блок сдвигается на несколько пикселей в IE, - можно ведь в стиле для IE (или хаке) подвинуть его обратно и не заморачиваться. Желание вполне естественное - сроки, как всегда, поджимают, результат в конце такой же, да и спасибо тебе за дополнительно потраченные усилия не сказали бы - оплата осталась бы такой же.
Ошибочность такого подхода заключается в том, что проблема решается без чёткого понимания того, почему она произошла. Что в свою очередь ведёт к ее появлению вновь и вновь в будущем. Желание достичь немедленного результата легко и просто выливается в потерю эффективности во всех последующих проектах. К тому же, такое отношение к делу тормозит ваше профессиональное развитие в данной области, что в долгосрочной перспективе куда важнее, чем результат текущего проекта.
Если же отложить результат и потратить время на то, чтобы действительно разобраться, почему именно так произошло, в каких еще случаях появляется этот баг, какие вообще есть способы его решения (все, а не один), в сотнях подобных ситуаций в дальнейшем этот баг (во всех его проявлениях, а не только в этом конкретном) скорей всего просто не возникнет, потому что вы обладаете нужными знаниями для его легкого предотвращения. А если и возникнет - его можно будет моментально решить. С опытом при таком подходе начинаешь писать код, который сходу работает во всех браузерах, практически на автомате, не задумываясь - спросите у знакомых гуру, они подтвердят.
То же касается выбора решений. Не копируйте слепо кусок кода после того, как вы нашли решение Гуглом - уделите пару минут, чтобы найти и объяснение того, почему это работает.
И еще - это всё не значит, что вам придётся нарушать сроки ради профессионального развития. Просто научитесь учитывать это время при соглашении сроков с заказчиком.
2. Не бойтесь пробовать новые решения.
На каждую отдельную задачу в вёрстке существует множество способов ее решения. У каждого свои достоинства и недостатки, случаи, где они подходят прекрасно и те, где не годятся совсем. Если вы просто любитель, - можете остановиться на том, что вас устраивает. Но если вы профессионал, вы должны знать и уметь применить их все.
Если в решении конкретной задачи (например, image replacement или multi-column layout) вас устроил один конкретный метод - не останавливайтесь на нём. Продолжайте пробовать другие. Читайте в блогах о новых и применяйте их тоже. Вы получите ценный опыт и обретёте в своём деле гибкость. А гибкость - умение адаптироваться к меняющимся условиям - крайне важное профессиональное качество, которое в конечном счёте выиграет вам немало времени.
В частности, кстати, это касается выбора JavaScript-фреймворка. Холивары по этому поводу разводят аматоры - хороший front-end программист же легко сможет применить любой из них, поскольку благодаря своему опыту знает особенности каждого и принципы, по которым они создаются и работают. (Еще стоит заметить отдельно от совета, что конкретно в этом вопросе намного важнее понимать сам язык программирования JavaScript - он куда мощнее и интереснее, чем кажется на первый взгляд.)
3. Не подчиняйтесь инструментам. Пользуйтесь ими.
Возьмём в качестве примера web-стандарты и семантику. Это не нерушимые заповеди, - это инструменты, созданные для конкретных целей. Если вы ими одержимы только потому, что об этом вам твердят коллеги, - не разобравшись досконально, зачем, чему и в каком случае необходимо соответствовать - вы не сможете их правильно применить на практике.
Скажем, человек сделал многоуровневые выпадающие меню CSS-only и хвалится тем, что это сделало меню доступным (accessible) - теперь им смогут воспользоваться люди с отключённым джаваскриптом и пользователи screen reader'ов. При этом он не осознаёт, что скринридеры вопреки распространённому мифу вполне поддерживают JavaScript и на CSS тоже в определённых случаях реагируют (например, многие из них не видят элементов, скрытых с помощью "display: none"), и что этим решением не смогут воспользоваться как пользователи скринридеров, так и все другие люди, осуществляющие навигацию не с помощью мыши (например, только с клавиатуры) - все решения CSS-only dropwdown menu жёстко завязаны на события мыши. Мало того - отсутствие задержки при появлении и исчезании меню доставит немало хлопот людям с плохим зрением или нарушениями двигательной функции (например, болезнью Паркинсона) - фиг наведёшь на нужный пункт. Вот вам и доступность.
Обратный пример: разработчик тратит кучу времени на то, чтобы сделать навороченное веб-2.0-приложение идеальным с точки зрения семантики, не понимая, что для людей с отключённым CSS или JavaScript оно вообще никогда не будет представлять никакой пользы в виду его специфики, а поисковикам закрыт доступ на индексирование потому, что страницы доступны только зарегистрированным пользователям.
Еще пример: валидация HTML/CSS. Сама по себе валидность согласно определённому Doctype'у не приносит никакой пользы проекту, не делает его более доступным и семантичным и вообще ничего не говорит о качестве вёрстки. Это просто инструмент, и им нужно уметь пользоваться, а не слепо подчиняться. Скажем, лично я свои проекты привожу в соответствие с XHTML 1.0 Strict, но не потому, что это круто, возвышает меня над другими разработчиками и даёт хороший повод для критики, а просто потому, что лично мне так удобно по определённым соображениям (а вот Ване Сагалаеву такой вариант не нравится и он тоже совершенно прав). К сожалению, очень часто наблюдаю обратное. К слову: статья на эту тему.
Вникайте в суть инструментов, которыми пользуетесь. Знайте, когда нужно их применить, а когда - не нужно. Если применяете - знайте хорошо, зачем.
4. Не допускайте односторонней связи с людьми, с которыми работаете.
Если ваш заказчик (или начальник, или менеджер) предъявляет совершенно дурацкое требование, не нужно выполнять его, сцепя зубы и матерясь под нос. Потратьте время на аргументированное объяснение того, почему данное решение неэффективно.
Конечно, в такой ситуации легче всего просто подумать, что заказчик - идиот, и прекратить дискуссию, но такое отношение не принесёт пользы ни вам, ни заказчику, ни выполняемому проекту. Будьте выше этого. Смотрите в первую очередь на себя, а потом уже на других. В данном случае это означает прежде всего подумать, что было не так в вашей аргументации и как ее можно сделать более убедительной. Даже если он после выслушивания ваших аргументов решит поступить по-своему, то будет это делать с осознанием всех последствий, к тому же доверие и уважение к вам как к специалисту возрастёт - в любом случае выигрывают обе стороны.
В случае вёрстки то же касается дизайнеров. Хороший дизайнер должен знать как сложности в вёрстке определённых вещей, так и возможности Web, которые он может использовать. Поэтому когда вы как верстальщик активно взаимодействуете с дизайнерами, а не просто верстаете что нарисуют, профессионально растёте вы оба, и проект вместе с вами в конечном счёте только выигрывает.
5. Умейте находить побольше хорошего в выбранном деле и уделяйте ему основное внимание.
Человек может достичь по-настоящему значимых результатов только в тех делах, которые действительно любит, которыми увлечён и занимается со всей душой. Ищите в своей работе вещи, которые по-настоящему увлекают, и занимайтесь ими, не смотря ни на что. Если вас по-настоящему прёт писать ультра-семантичный до самых мелочей код даже там, где он совсем не нужен по многим соображениям - пишите. Если страшно нравятся экстремальные эксперименты с CSS, за которые начальник вас всё время пинает - всё равно дерзайте. Потеря энтузиазма означает в конечном счёте потерю квалификации. Наличие - постоянное самосовершенствование и великолепные результаты.
Спасибо за внимание. :)
Источник: хабра