Как найти баг в вёрстке

08 Jan, 2008

Как часто вы тратите часы чтобы понять почему же эта эта вредная навигация сползла? Этот способ позволяет найти причину практически не думая за 5 минут. Наверное почти все пользовались этим методом поиска багов в вёрстке.

Зачем

Очень много времени в верстке уходит на решение багов, и поиски их причин. Если вы чувствуете, что можете потратить более 20 минут на поиски причины — лучше смело использовать этот метод, он редко отнимает более 5-10 минут. Впрочем, менее 5 минут, он тоже редко отнимает. И это его единственный недостаток.

Когда

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

Идея

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

Принцип очень простой, чтобы найти, например, точку на отрезке:

  1. Делим отрезок пополам, определяем в какой половине содержится наша точка
  2. Повторяем процедуру для полученной половины отрезка с точкой
И так, пока не получим нужную точность.

А так это выглядит в задаче про поимку льва в пустыне:

Делим забором пустыню пополам. Затем та часть, в которой остался лев, снова перегораживается посередине, и так далее — до тех пор, пока лев не окажется в тесном загоне.

Алгоритм в приложении к вёрстке мало отличается от классики. Львом будет кусочек кода делающий глюк. Пустыней — весь код.

Суперпупералгоритм

  1. Удаляем половину или просто большой кусок HTML (CSS)
    • Если глюк остался виден, продолжаем процедуру для оставшегося кода
    • Если глюк исчез, возвращаем удалённый код и повторяем процедуру для него (удалив другую половину)
В результате останется только "глючный" HTML, обычно это пара блоков связанных с глюком. Тоже самое повторяем для CSS кода. Если в HTML еще нужно было соблюдать иерархию, то в CSS можно смело удалять по половине кода.

Таким образом, в конце у вас останется несколько строк CSS и только те блоки в HTML, которые составляют глюк. При таком количестве кода вам будет трудно не найти баг или опечатку.

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

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

Проделывать это все рекомендуется с копией кода. Чтобы можно было смело удалять и не беспокоиться.

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

В конце

Даже странно почему об этом способе так мало написано(может потому что это слишком просто?). Надеюсь кому-то он поможет, меня не раз выручал. Вдобавок, такие действия помогают начинающим лучше разобраться и прочувствовать как работает этот CSS. =) А при поиске глюка в чужом коде — это практически единственный путь.

Кстати, только с помощью этой методики удалось обнаружить странный баг с кодировкой CSS файлов.

Конечно же рад услышать Ваши способы решения своих проблем!

36 комментариев к “Как найти баг в вёрстке”

1.Samter | 06 Sep, 2009
пока не начал читать думал, как можно еще быстрее отловить баги в верстке. также пользуюсь этим методом. всегда помогает.
2.Нгуен Павел | 08 Jan, 2008
Данный метод далеко не всегда будет работать, т.к. при верстке (особенное если используются статьи). Дело в том, что некоторые части кода влияют на другие (причем магическим образом). Так например, я удалил однажды меню и все стало отображаться нормально. Следовательно, по данному алгоритму проблема должна быть в меню. А вот и нет, меню само по себе отображалось тоже нормально, но вместе они не контачили.
3.akella | 08 Jan, 2008
Ситуации бывают разные, и совсем выключать мозг конечно не рекомендуется. Я видимо неправильно расставил акценты - метод изначально применяется к CSS. Для HTML лишь когда причина может быть в HTML, а это очень редко(на живых сайтах уже обычно, когда глючит именно некорректный HTML). Помнить о сложных зависимостях в ХТМЛ и ЦСС стоит, но в моей практике это как то было скорее нюансами, нежели реальной проблемой. Да и вообще, такие зависимости говорят о плохом ООВ :P
4.Андрей | 08 Jan, 2008
Мой любимый способ при поимке трудноуловимого бага - снести всё, что глючит и сделать заново. Как правило, это экономит время.
5.angizij | 08 Jan, 2008
Да, я к этому методу прибегаю, когда уже ничего не помогает ) но иногда и помогает ctrl-z : отменять последние изменения пока глюк не исчезнет, а потом восстанавливать потихоньку, но уже попытаться без глюка
6.Арматурыч | 08 Jan, 2008
Примерно такой же метод, но с использованием Firebug. Включаем режим Inspect, выделяем "сломанный" фрагмент, и аккуратно поднимаемся "снизу-вверх" по элементам, заодно на ходу проверяя различные свойства css. Благо Firebug позволяет всё редактировать на ходу.
7.Slaver | 09 Jan, 2008
Самый простой и адекватный способ. Практически всегда использую и всем советую :)
8.Тормоз | 09 Jan, 2008
К счастью, постепенно метод становится нужен всё реже и реже, потому что в большинстве случаев причину глюков начинаешь понимать сразу :) Ну и вообще, глюки реже случаются, когда приходит опыт.
9.FX Poster | 09 Jan, 2008
Пользуюсь таким методом частенько. :) Еще важно то, чтобы части кода в CSS были сгруппированы по блокам (т.е. выделяем, например, меню на странице и пишем весь код для него, не разносим отдельно шрифты, layout, фенечки всякие). А то бывает, что пара правил из разных блоков дают такой эффект, а по отдельности всё нормально работает. И если эта пара правил находится в разных частях кода - то такой баг вообще фиг отловишь.
10.akira | 09 Jan, 2008
Ха, а я думал, что этот способ для гуру не подходит :) Как-то думалось, что гуру краем глазом могут определить ошибку :)
11.akella | 09 Jan, 2008
Бывают такие ошибки... =) С месяц назад был момент - час сидел злой на себя, не мог понять где перепутал правило, потом просто отключил мозг, и нашел эту строку этим методом. =) Особенно приятно что таким же методом находят корни уравнений в вычислительной математике =)
12.Sam | 09 Jan, 2008
Пользуюсь постоянно когда не получается вычислить жучков сходу.
13.Максим Покровский | 11 Jan, 2008
При чужом коде пользуюсь этим способом. Вернее пользовался, сейчас уже как-то на глазок определяешь в чем дело.
14.ganges | 09 Jan, 2008
Не пользуюсь практически со своим кодом. С чужим - обязательно, если его нельзя просто удалить. Пишу код и параллельно пошагово, практически после каждого правила, могущего повлиять на позиционирование автоматически проверяю во всех браузерах (за исключением маковских, но насчет Сафари я спокоен, если Konqueror под Linux работает правильно). Это чертовски удобно.
15.anycolor | 11 Jan, 2008
А есть другие способы? 0_0 Я если честно удивлен, всегда пользовался только этим, подсознательно даже, не зная о том, что есть такая задача ловли льва в пустыне :) Способ меня никогда не подводил. Однако я всегда сначала пытаюсь найти ошибку "логически". Когда это не получается иду уже методом "грубой силы", тоесть методом, описанным выше. Всегда работает, особенно хорошо работает, когда мозг выключен и надо только механически делать действия - вставил, вырезал, проверил..
16.akella | 11 Jan, 2008
Насчет льва в пустыне -- мне просто нравится искать аналогии идей из других сфер жизни, если бы я был музыкантом, а не математиком, я бы приплел сюда какую-то симфонию, это точно =) Это все "Гедель. Эшер. Бах" виноват. Рекомендую, хотя там много математики, но очень интересно. Да это конечно грубый метод, ты абсолютно прав, я сам его обычно применяю от безысходности, всегда ведь до последнего верю, что вот-вот придумаю как пофиксить )
17.Юрко | 11 Jan, 2008
У Вас очень красивая веб-страничка, Вам кто-то об этом говорил? Я ИДИОТ!"!!!!! УБЕЙТЕМ ЕНЯ КТО-НИБУДБЬ!!!!!АДИНАДАИН!!!!111111ЖЖАЖАЖЖАЖА
18.Eugene | 11 Jan, 2008
Сразу добавил ваш сайт в закладки. Я только начинаю изучать верстку. А прием действительно супер - давно им пользуюсь в другой деятельности:)
19.Arina | 13 Jan, 2008
С опытом пришла к таким же выводам :-)
20.Flo | 13 Jan, 2008
Безусловно, хороший способ поиска багов, сам им пользуюсь когда непонятные жучки вылазят, но все-таки есть значительный недостаток, который описал Нгуен Павел в 1м комменте. А вообще, спасибо, хорошая статья!!
21.Дмитрий | 14 Jan, 2008
Иногда, когда немогу врубить, почему тот или иной элемент оказывается не там где ты этого ожидал, расставляю бордеры, всей иерархии блока. Сразу видно, что куда и где. Особенно полезно, когда смотришь чужую вёрстку, или в старом файле надо сделать изменения.
22.Flo | 14 Jan, 2008
Дмитрий, правильнее было бы не бордеры ставить, а бэкграунды для блока, потому что бордеры искажают его размер и может поползти вся верстка.
23.Санек | 14 Jan, 2008
Я пользуюсь Firebug ( http://www.getfirebug.com/ ) для ловли багов. Тыкнул мышкой в экран - сразу попал в то место в коде, где блок описывается. Можно в этом-же окне менять свойства ксс и смотреть результат - очень помогает при подборе ширин и т.д. Один недостаток - нет такого инструмента для ИЕ. Ну кроме Internet Explorer Developer Toolbar - и то он не дотягивает до Firebug. http://www.microsoft.com/downloads/details.aspx?FamilyID=e59c3964-672d-4511-bb3e-2d5e1db91038&DisplayLang=en
24.tobto | 15 Jan, 2008
2Мой любимый способ при поимке трудноуловимого бага - снести всё, что глючит и сделать заново. Как правило, это экономит время cолидарен. бывает такой символ заползет из фотошопа, что его не найти. приходится переверстывать и, как всегда, баг исчезает, а верстка становится крепче, т.к. по пути ее немножко оптимизируешь.
25.Павел Коноплицкий | 17 Jan, 2008
Метод выручает постоянно
26.Z-Den | 23 Jan, 2008
Никогда даже в голову не приходило так искать баги, но найти-то это одно дело. В своем коде найти баг для меня не проблема. Вот для чужого кода это действительно может помочь. Нужно будет попробовать.
27.Клевый сеошник | 26 Jan, 2008
$) баги баги. Попробуем так
28.Александр | 26 Jan, 2008
в начале - так и делал, отрубаешь весь css, убираешь html пока не остается голый файлик :-) по моим ощущениям - самый логичный путь поиска багов. сейчас отладка иначе, время тратится на соображение того - что может вызвать баг и что может влиять на него - потом телепартируеюсь в то место и правлю/разбираю код. нередко выручало прописывание инлайного border:1px solid red; - делалось, чтобы выделить layout страницы и проверить ее восприятие броузером. достаточно часто выручало на чужом коде любого качества ( до знакомства с FireBug-ом )
29.Антонов Сергей | 13 Feb, 2008
я всегда тупо ручками ищу :)
30.Сергей Корниенко | 02 Apr, 2008
Хороший метод, особенно когда причина возникновения бага неочевидна. Если "сползла колонка" или что-то в этом роде, иногда хорошо также помогает простой метод сравнить количество "
31.bumbu | 07 Aug, 2008
всегда использовал этот метод когда вёрстка бесила изза свойх глюков на разных браузеров, хотя прочитав заголовок думал найду чтот супер умное, оказалось не ток я люблю простое
32.Shuvalof | 27 Mar, 2009
Я думаю, что с багами проблем нет, когда делаешь все своими кривыми руками. А многие юзают шаблоны, скрипты, где куча текстового хлама. В программировании, на сколько я знаю, есть готовые библиотеки и модули. Все это готовое, экономящее время, в итоге негативно сказывается, получается халтура на выходе. Это имхо, может я его когда-нибудь и поменяю.
33.zeitgeist | 26 Aug, 2008
Не знаю насколько актуальна эта статья, на момент написания камента, но я уже практически исключил из своей работы подобную практику, все дело в жуке :Р. Firebug рулит. А если запара в 6м ИЕ - то тогда либо описанный выше метод, либо метод взятия блоков "в бордюру", но с практикой приходит опыт, который позволяет писать и думать заранее как это будет выглядеть в ИЕ.
34.cssing :: Архив :: CSSing 2008 | 30 Dec, 2008
[...] ? ак найти баг в вёрстке — самый простой и надежный способ обнаружить ошибку в верстке [...]
35.Jman | 02 Jan, 2009
Я рисую проблемному блоку бордеры, что типа такого #idблока {background:#ebebeb;} #idблока * {border:1px #f00 dashed;} * html #idблока * {border:1px #0f0 dashed;} /*увидеть разницу в ие*/
36.Дерябин Андрей | 10 Jan, 2009
Я не верстальщик, но этим методом пользуюсь и в программировании. Это вполне обычная практика. По сути делаются "заглушки" - отключение части функционала (в данном случае - верстки) и тестируется работоспособность оставшегося функционала. Есть даже методологии тестирования, основанные на этом подходе. Так что я бы эту статью можно обобщить не только как метод поиска бага в верстке.