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

8 January, 2008

XHTML/CSS, Полезности

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

Зачем

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

Когда

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

Идея

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

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

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

И так, пока не получим нужную точность.

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

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

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

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

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

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

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

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

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

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

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

В конце

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

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

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

XHTML/CSS, Полезности

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

Нгуен Павел | 1. 8 January, 2008

Данный метод далеко не всегда будет работать, т.к. при верстке (особенное если используются статьи). Дело в том, что некоторые части кода влияют на другие (причем магическим образом). Так например, я удалил однажды меню и все стало отображаться нормально. Следовательно, по данному алгоритму проблема должна быть в меню. А вот и нет, меню само по себе отображалось тоже нормально, но вместе они не контачили.

akella | 2. 8 January, 2008

Ситуации бывают разные, и совсем выключать мозг конечно не рекомендуется. Я видимо неправильно расставил акценты – метод изначально применяется к CSS. Для HTML лишь когда причина может быть в HTML, а это очень редко(на живых сайтах уже обычно, когда глючит именно некорректный HTML).

Помнить о сложных зависимостях в ХТМЛ и ЦСС стоит, но в моей практике это как то было скорее нюансами, нежели реальной проблемой. Да и вообще, такие зависимости говорят о плохом ООВ :P

Андрей | 3. 8 January, 2008

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

angizij | 4. 8 January, 2008

Да, я к этому методу прибегаю, когда уже ничего не помогает )
но иногда и помогает ctrl-z : отменять последние изменения пока глюк не исчезнет, а потом восстанавливать потихоньку, но уже попытаться без глюка

Арматурыч | 5. 8 January, 2008

Примерно такой же метод, но с использованием Firebug.
Включаем режим Inspect, выделяем “сломанный” фрагмент, и аккуратно поднимаемся “снизу-вверх” по элементам, заодно на ходу проверяя различные свойства css. Благо Firebug позволяет всё редактировать на ходу.

Slaver | 6. 9 January, 2008

Самый простой и адекватный способ. Практически всегда использую и всем советую :)

Тормоз | 7. 9 January, 2008

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

FX Poster | 8. 9 January, 2008

Пользуюсь таким методом частенько. :) Еще важно то, чтобы части кода в CSS были сгруппированы по блокам (т.е. выделяем, например, меню на странице и пишем весь код для него, не разносим отдельно шрифты, layout, фенечки всякие). А то бывает, что пара правил из разных блоков дают такой эффект, а по отдельности всё нормально работает. И если эта пара правил находится в разных частях кода – то такой баг вообще фиг отловишь.

akira | 9. 9 January, 2008

Ха, а я думал, что этот способ для гуру не подходит :)
Как-то думалось, что гуру краем глазом могут определить ошибку :)

akella | 10. 9 January, 2008

Бывают такие ошибки… =)
С месяц назад был момент – час сидел злой на себя, не мог понять где перепутал правило, потом просто отключил мозг, и нашел эту строку этим методом. =)

Особенно приятно что таким же методом находят корни уравнений в вычислительной математике =)

Sam | 11. 9 January, 2008

Пользуюсь постоянно когда не получается вычислить жучков сходу.

ganges | 12. 9 January, 2008

Не пользуюсь практически со своим кодом. С чужим – обязательно, если его нельзя просто удалить.

Пишу код и параллельно пошагово, практически после каждого правила, могущего повлиять на позиционирование автоматически проверяю во всех браузерах (за исключением маковских, но насчет Сафари я спокоен, если Konqueror под Linux работает правильно).

Это чертовски удобно.

Максим Покровский | 13. 11 January, 2008

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

anycolor | 14. 11 January, 2008

А есть другие способы? 0_0
Я если честно удивлен, всегда пользовался только этим, подсознательно даже, не зная о том, что есть такая задача ловли льва в пустыне :)

Способ меня никогда не подводил.

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

akella | 15. 11 January, 2008

Насчет льва в пустыне — мне просто нравится искать аналогии идей из других сфер жизни, если бы я был музыкантом, а не математиком, я бы приплел сюда какую-то симфонию, это точно =) Это все “Гедель. Эшер. Бах” виноват. Рекомендую, хотя там много математики, но очень интересно.

Да это конечно грубый метод, ты абсолютно прав, я сам его обычно применяю от безысходности, всегда ведь до последнего верю, что вот-вот придумаю как пофиксить )

Юрко | 16. 11 January, 2008

У Вас очень красивая веб-страничка, Вам кто-то об этом говорил?

Я ИДИОТ!”!!!!! УБЕЙТЕМ ЕНЯ КТО-НИБУДБЬ!!!!!АДИНАДАИН!!!!111111ЖЖАЖАЖЖАЖА

Eugene | 17. 11 January, 2008

Сразу добавил ваш сайт в закладки. Я только начинаю изучать верстку. А прием действительно супер – давно им пользуюсь в другой деятельности:)

Arina | 18. 13 January, 2008

С опытом пришла к таким же выводам :-)

Flo | 19. 13 January, 2008

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

А вообще, спасибо, хорошая статья!!

Дмитрий | 20. 14 January, 2008

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

Flo | 21. 14 January, 2008

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

Санек | 22. 14 January, 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

tobto | 23. 15 January, 2008

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

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

Павел Коноплицкий | 24. 17 January, 2008

Метод выручает постоянно

Z-Den | 25. 23 January, 2008

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

Клевый сеошник | 26. 26 January, 2008

$) баги баги. Попробуем так

Александр | 27. 26 January, 2008

в начале – так и делал, отрубаешь весь css, убираешь html пока не остается голый файлик :-) по моим ощущениям – самый логичный путь поиска багов.

сейчас отладка иначе, время тратится на соображение того – что может вызвать баг и что может влиять на него – потом телепартируеюсь в то место и правлю/разбираю код.
нередко выручало прописывание инлайного border:1px solid red; – делалось, чтобы выделить layout страницы и проверить ее восприятие броузером. достаточно часто выручало на чужом коде любого качества ( до знакомства с FireBug-ом )

Антонов Сергей | 28. 13 February, 2008

я всегда тупо ручками ищу :)

Сергей Корниенко | 29. 2 April, 2008

Хороший метод, особенно когда причина возникновения бага неочевидна.
Если “сползла колонка” или что-то в этом роде, иногда хорошо также помогает простой метод сравнить количество “

bumbu | 30. 7 August, 2008

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

zeitgeist | 31. 26 August, 2008

Не знаю насколько актуальна эта статья, на момент написания камента, но я уже практически исключил из своей работы подобную практику, все дело в жуке :Р. Firebug рулит. А если запара в 6м ИЕ – то тогда либо описанный выше метод, либо метод взятия блоков “в бордюру”, но с практикой приходит опыт, который позволяет писать и думать заранее как это будет выглядеть в ИЕ.

cssing :: Архив :: CSSing 2008 | 32. 30 December, 2008

[…] ? ак найти баг в вёрстке — самый простой и надежный способ обнаружить ошибку в верстке […]

Jman | 33. 2 January, 2009

Я рисую проблемному блоку бордеры, что типа такого
#idблока {background:#ebebeb;}
#idблока * {border:1px #f00 dashed;}
* html #idблока * {border:1px #0f0 dashed;} /*увидеть разницу в ие*/

Дерябин Андрей | 34. 10 January, 2009

Я не верстальщик, но этим методом пользуюсь и в программировании. Это вполне обычная практика. По сути делаются “заглушки” – отключение части функционала (в данном случае – верстки) и тестируется работоспособность оставшегося функционала. Есть даже методологии тестирования, основанные на этом подходе. Так что я бы эту статью можно обобщить не только как метод поиска бага в верстке.

Shuvalof | 35. 27 March, 2009

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

Это имхо, может я его когда-нибудь и поменяю.

Samter | 36. 6 September, 2009

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

Оставить комментарий