random technical notes

Несколько советов от web-программистов. Советы:

1. Используй таблицы не для вёрстки страницы, а только для отображения таблицы с данными. Все возможные способы вёрстки документа доступны нам при использовании div-ной вёрстки. Div-ная вёрстка наиболее логична и лаконична.
2. При использовании padding-top у внешнего элемента и margin-top у внутреннего, в IE срабатывает только свойство с наибольшим значением. Используй или только margin, или только padding, или делай отступы с использованием дополнительного контейнера.
3. Не используй для элементов такие свойства CSS вместе:

   ... {
   	float: left;
   	width: ... ;
   	margin-left: ... ;
   }

   или

   ... {
   	float: right;
   	width: ... ;
   	margin-right: ... ;
   }

   в этом случае IE6 будет увеличивать отступ (margin-left, margin-right) в два раза.
   Используй padding для внешнего контейнера, чтобы сдвинуть элемент. Или добавь ещё один контейнер и сдвигай его с помощью margin.

4. Если хочешь чтобы пользователь IE6 мог изменять размеры шрифта на странице, то для определения размера шрифта следует использовать относительные единицы измерения: em и %.
5. Чтобы не было проблем с языками все файлы сохраняй в кодировке UTF-8. Обязательно указывай кодировку в соответствующем meta-теге и для всех подключаемых файлов (например подключенных с помощью элементов <script>, <link>).

 Из блога seleckis.lv

1. Всегда указывайте подходящий DOCTYPE. Советую почитать эту статью, хоть ей лет и лет
2. Сбрасывайте значения по умолчанию у элементов, у разных браузеров они могут быть разными. Советую css код для сброса от Eric Meyer.
3. Очищайте плавающие блоки с помощью overflow:hidden; и задания ширины для родительского контейнера.
4. Чтобы задать нулевую высоту для элемента <div> в IE необходимо кроме свойства height:0; добавить ему свойство line-height:0;
5. Больше читайте о предметной части. Советую этот список ресурсов.

Из блога blog.sribna.com

1. Проверяйте качество верстки простым отключением CSS. Страница должна выглядеть простой, логичной и аккуратной. На ней не должно быть видно элементов оформления, но контент и навигация должны оставаться доступными, легко находиться и читаться.Другая проверка — отключение картинок при включенном CSS (те же требования по доступности). Хорошо сверстанная страница, без картинок может выглядеть даже лучше чем с картинками.
2. Очень важно владеть элементарными средствами поиска ошибок. Расскажу про свои любимые.Первый — очень быстрый способ:

   * {outline: solid 1px;}

   Второй — незаменимый способ для поиска кросс-браузерных ошибок:

   .foo {border-bottom: solid;}

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

   Третий — позволяет локализовать ошибку в CSS-файле, найти конкретное свойство, если непонятно даже где искать. Делают так: удаляю часть кода из CSS-файла. Например, ровно половину. Проверяю в браузере. Отменяю удаление. Потом удаляю другую половину. Проверяю — отменяю. Потом удаляю большими кусками, по одному. Все время проверяя, исчезла ли ошибка. Куски удаляемого кода все время уменьшаются, вплоть до отдельных правил и свойств. Иногда это единственный способ, способный помочь.

3. Если у элемента есть больше одного border-а, эффективнее и короче написать, например, не border-top и border-bottom, а так:

   border: solid #AAA; border-width: 1px 0;

   Когда border-ов три-четыре, это еще экономнее.

   Для задания разных цветов:

   border-color: red green blue gray;

4. Запомните общепринятые имена классов (id): page — обертка, содержащая все элементы на странице; wrap — обертка для основных блоков страницы; subwrap — дополнительная обертка, header — шапка; content — главная часть страницы с уникальным контентом; aside — например боковая колонка в двух- трехколоночном макет; extra — еще одна боковая колонка; nav — любой блок с навигационным меню (в шапке, в боковой колонке, в подвале); footer — подвал.В дополнение к этому известному набору я придумал имя lining — подкладка — в основном, для вложенных блоков, используемых, для задания отступов.Эти имена могут найти применение на странице любого типа, практически в любом проекте. Не нужно изобретать каждый раз велосипед, можно использовать код вторично, код понятен многим без объяснений.
5. Используйте в качестве имен элементов только классы, а не id. И вы забудете о дилемме, что писать в каждом конкретном случае: id или класс 🙂 Плюс, меньше шансов, что вы напишите два одинаковых id на странице (это невалидно). Присваивайте элементу id, только если без этого никак не обойтись, или если вас специально об этом попросили.

Из блога uggallery.audiopeace.ru

1. При ограничении максимальной ширины макета полезно задавать max-width в единицах em (к минимальной ширине это не относится, она обычно задаётся в пикселах). Это позволяет сделать более-менее постоянной длину строки текста в символах по достижении максимальной ширины даже при изменении размера шрифта средствами браузера. Для IE6, не поддерживающего max-width, имеет смысл ограничиться JavaScript-эмуляцией только минимальной ширины макета.
2. Для элементов в области контента — главным образом, абзацев — полезно задавать только нижнее поле (margin) (например, 1em), верхнее поле при этом обнулив. Это позволяет избежать проблем с кроссбраузерным отображением обтекаемых элементов (в частности, изображений) в том, что касается визуального совпадения верхних кромок текста абзаца и элемента, им обтекаемого.
3. Чтобы внушить IE5/5.5, что он поддерживает свойство padding для строчных элементов, достаточно включить для соответствующего строчного элемента свойство hasLayout, например, при помощи такого правила:

   * HTML #mnu A {height: 1px; }

   Если, конечно, браузеры линейки IE5.x (суммарная доля которых в рунете, согласно статистике, составляет в настоящий момент менее процента) для вас по-прежнему имеют какое-то значение.

4. Правила, специфичные для IE5/6, но не нужные для IE7, нередко имеет смысл прятать при помощи условных комментариев в отдельный css-файл, чтобы страница загружалась быстрее не только в нормальных браузерах, но даже в IE7, которому, как ни крути, скоро будет принадлежать основная доля среди браузеров. Более того, такой подход потенциально позволяет избавиться от хаков вовсе (в подавляющем большинстве случаев специфичные для IE5 и IE6 правила можно без проблем объединить) — это может быть полезным, в частности, при динамической генерации таблиц стилей на серверной стороне.
5. Если для вёрстки макета принципиально необходимо поменять элементы местами таким образом, что реализовать это средствами CSS невозможно либо корректность отображения страницы при этом начинает сильно зависеть от размера шрифта или количества текста в соответствующих блоках, лучше прибегнуть к JavaScript и просто переместить соответствующие элементы в нужные позиции DOM-дерева сразу после окончания загрузки HTML-документа. При этом для редких случаев отключения JavaScript, когда блоки переставлены не будут, можно просто предусмотреть дополнительный приемлемый вариант оформления. Например, поменять порядок следования двух абзацев можно следующим образом:

   <p id="first">первый абзац</p>
<p id="second">второй абзац</p>
<script type="text/javascript">
var a = document.getElementById('first');
var b = document.getElementById('second');
a.parentNode.insertBefore(b, a);
</script>

Из блога tanalin

1. Откажитесь от хаков
   Думайте о будущем: каждый хак рано или поздно может сказаться и вылезти в новых браузерах. Если хак неизбежен — используйте условные комментарии и выносите хаки в отдельные файлы (например для IE 6). Каждый хак должен быть как грех — используйте их, но помните, что за каждый хак вы будете лизать горячую сковородку в аду 😉
2. Начинайте верстку с голого HTML
   Лучше всего — в целях семантики — начать с неоформленного (X)HTML, не добавляя ни строчки CSS (как бы рука не тянулась к оформлению — сложно, знаю). В этом случае вы сможете добиться наиболее чистого и правильного кода, который после уже начнете оформлять. Это будет соответствовать генеральной задумке веб-стандартов.
3. Относительные размеры шрифтов
   По возможности не используйте фиксированные размеры шрифтов. Чтобы получить наиболее постоянные пропорции во всех браузерах можете задавать font-size: 62.5% для body, а затем задавать размеры элементов при помощи процентов. Например, font-size: 120% будет равен 12 пикселям, а font-size: 80% — 8 пикселям во всех браузерах.
4. Проверка сайтов в нескольких браузерах
   Начиная верстать, постоянно проверяйте макет в Firefox и Опере. На более поздних этапах можете подключить Safari и IE 7. IE 6 подключайте только когда макет будет сверстан и надо будет исправлять отдельные баги. Этот подход может показаться спорным, но если вы сразу начнете верстать «под IE6», то вас может унести далеко и надолго.
   Если вы работаете в Windows, то скачайте MultiIE. Если вы на другой платформе — ставьте VirtualBox и тестируйте. Слава богу, что Сафари теперь есть и для Windows.
5. Выставьте в своем браузере другой фоновый цвет
   Этот совет мне давно хотелось бы дать всем верстальщикам. Как часто видишь хороший сайт, в стилях которого не прописан фоновый цвет страницы, что приводит к поломке всего дизайна. Для того, чтобы не забывать это делать, я выставляю в Опере светло-серый цвет фона по умолчанию и сразу вижу, когда я забыл прописать background-color.

Из блога www.aether.ru

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, за которые начальник вас всё время пинает – всё равно дерзайте. Потеря энтузиазма означает в конечном счёте потерю квалификации. Наличие – постоянное самосовершенствование и великолепные результаты.

Из блога habrahabr.ru/blogs/webdev