Возможна ли настоящая отладка HTML?
Я уже довольно давно работаю веб-разработчиком, и что помогло мне в обучении, так это визуальное представление того, что происходит.
Это причина для таких инструментов, как Aardvark, Web developer, Firebug и многих других.
Но когда я увидел Видео с Gecko Reflow, они просто взорвали мой мозг.
Тогда мой вопрос: можно ли по-настоящему отлаживать html (шаг за шагом по каждому элементу)? Или приблизиться к этому?
Я много делал, чтобы использовать Aardvark и удалять элементы, но у Aardvark есть проблемы с "фоном" и элементами того же размера, и с невозможностью нацелить их.
ОБНОВЛЕНИЕ: я пытался написать хорошее обновление для этого вопроса, так как оно заставило меня больше думать об этом. Но поскольку английский не является моим основным языком, это было непросто.
В последние годы перед браузерами стояла задача обеспечить совместимость со стандартами. По мере приближения к этой цели именно мы должны думать о том, что мы действительно можем создать, когда совместимость с браузером минимальна, и если есть методы, которые мы можем использовать, чтобы ускорить рендеринг страницы.
Мы можем думать о прошедших десятилетиях как о первых годах HTML / CSS, когда главной целью было просто заставить это работать. Теперь нам следует искать методы, ускоряющие текущий процесс. Пример этого - на видео выше, где движок Gecko дважды выполняет код. Это почему? И есть ли другие случаи, когда он делает ненужные вещи (даже если они работают и совместимы)
Это то, что явно необходимо протестировать для подтверждения, отсюда и мой первоначальный вопрос об истинном отладчике.
Ух ты. На Gecko Reflow приятно смотреть.
Хе-хе, спасибо, у меня отвисла челюсть, когда я посмотрела эти видео.
Я думаю, это было бы здорово. HTML-рендеринг для меня - такой черный ящик, и хотя я не знаю, насколько это действительно поможет мне выполнить мою работу, заглянуть под капот было бы здорово, чтобы понять, как все происходит!
Похоже, вас беспокоит эффективность CSS, поскольку он влияет на рендеринг страницы, а не HTML.
@Paul с идеей CSS3 и его уровнем сложности, настоящая отладка HTML Render была бы прекрасной идеей.
Ответы 5
ок - серьезный ответ.
Судя по комментариям на сайтах, на которые я перешел по этой ссылке, я думаю, что мы с вами знаем, что, вероятно, их нет. В этих обсуждениях много умных парней и блогеров, и все они указывают на «нет, это все умные 4 доллара!», Которые не помогут нам в понимании рендеринга.
Однако я думаю, что ваш вопрос, возможно, захочет подчеркнуть, что рендеринг на уровне браузера очень интересен.
Позвольте мне просто выбросить это там. Как вы думаете, установка body { overflow: scroll; } по умолчанию может немного ускорить нас ???
Да, я знал, что на создание видеоролика у профессионалов ушло время, но он помог в обсуждении того, какие инструменты мы должны использовать, чтобы создавать лучшее для Интернета в кратчайшие сроки, и чтобы помочь нам сделать лучшее лучше со временем.
Что касается вашего вопроса о переполнении: прокрутка, я просто не знаю, в настоящее время мы говорим о различиях в миллисекундах, было бы интересно увидеть на очень тяжелой странице html / css (т.е. изображение, сделанное из тегов div и цвета фона), если время рендеринга быстрее.
Вдобавок к этому <code> {overflow: scroll;} </code> стоит мне полосы пропускания, а мои пользователи просто этого не стоят. Я уже думал об этом больше времени, чем они того стоят ... :-)
Мои 0,02 доллара:
«Настоящая» отладка HTML в том смысле, о котором вы говорите, технически невозможна, потому что пользовательские агенты HTML (веб-браузеры) не обязаны отображать элементы HTML в определенном порядке, и нет ничего похожего на атомарную единицу. исполнения как «заявление».
Например, при рендеринге таблицы должен ли пользовательский агент зарезервировать место для каждого <tr> перед рендерингом своего дочернего <td>s (в ширину)? Или он должен отображать каждый дочерний элемент <td> и каждый дочерний элемент <td>s и так далее (в глубину)? На практике пользовательские агенты делают всевозможные догадки, чтобы попытаться отобразить страницы как можно быстрее. Другими словами, не будет никакой гарантии, что порядок отладки будет соответствовать фактическому порядку рендеринга, и не должно быть.
HTML можно рассматривать как декларативный язык в этом смысле, поскольку он определяет, что должно быть сделано (страница, отображаемая в соответствии со спецификацией), но не совсем точно, как это делать (в каком именно порядке отображать элементы на экране). В общем, лучше всего предположить, что все происходит сразу, хотя W3C дает несколько советов при ускорении рендеринга <table> зависит от того, как пользовательские агенты должен визуализируют элементы <table>.
IMO, панель инструментов веб-разработчика и Firebug - лучшее, что у нас есть, где мы можем редактировать / отключать определенные элементы HTML и правила CSS.
Хорошо сформулированная поездка. Это очень интересная тема (просто если посмотреть, сколько раз она была отмечена как избранная), но я думаю, что вопрос не такой серьезный, как количество вопросов, которые он действительно поднимает. @ Ólafur, можешь ли ты расширить вопрос? Я бы хотел, чтобы у этого было немного больше пробега.
Отличный ответ. Я думаю, что вы имеете в виду, что HTML декларативен, а не императивен.
Лично я считаю, что пока ваш HTML соответствует спецификации W3C, разве это не имеет значения? Следует разработать свой HTML в соответствии со спецификациями и позволить браузерам беспокоиться о своих ошибках (которые в наши дни довольно редки), а не сосредотачиваться на старых ошибках браузеров прошлого.
Плагин HTML Validator для Firefox (также известный как Tidy) - это все, что нужно любому веб-разработчику, чтобы увидеть, правильна ли его разметка, что не так, а где нет.
Даже если бы вы могли выполнить настоящую отладку, каждый браузер анализирует HTML по-своему, поэтому, даже если вы можете пройти через Firefox, чтобы увидеть, как возникает ошибка рендеринга, это не поможет вам с IE или Safari / Chrome вообще, потому что они выполняют синтаксический анализ. по-своему. Это не похоже на PHP, .NET или Java, где парсинг кода одинаков для всех, отладка здесь имеет смысл.
"... пока ваш HTML соответствует спецификации W3C, разве это не имеет значения? Нужно разработать свой HTML в соответствии со спецификацией и позволить браузерам беспокоиться о своих ошибках (которые в наши дни довольно редки), чем сосредоточиться на старых ошибки браузера прошлого ". Вы, сэр, с таким ответом не занимаетесь веб-дизайном.
Then my question is, is it possible to truly debug html (step through each element)? Or come close to it?
Вы, вероятно, могли бы пройти процесс рендеринга страницы, запустив Firefox под gdb, или изменить браузер с открытым исходным кодом, чтобы в нем была кнопка «шаг», но я действительно сомневаюсь, что это принесет что-то полезное.
CSS не так уж сложен, все в основном представляет собой коробку с шириной / высотой / отступом / полем. Проблема с веб-разработкой (в частности, CSS) заключается в том, что каждый браузер реализует рендеринг немного по-разному (некоторые более по-другому, чем другие) ..
Если вы хотите знать порядок рендеринга, чтобы ускорить загрузку вашей страницы, я бы сказал, что вы делаете это неправильно. Браузер, отображающий страницу, вероятно, составляет 5% времени загрузки, остальное - время генерации страницы и задержка в сети.
Вы могли бы сократить время загрузки страницы на 2 мс, переупорядочив некоторые теги и используя другой метод позиционирования CSS ... или вы можете уменьшить время генерации страницы на 200 мс за счет кэширования и половину задержки сети, установив второй веб-сервер поближе. ваших пользователей ... Лучшее сжатие вашего логотипа или минимизация вашего javascript, скорее всего, улучшат время загрузки (повсеместно, во всех браузерах!)
В принципе, если вас беспокоит время загрузки, есть более подходящие места для много. Если вас беспокоит, как отображается страница, Firebug (-Lite) и http://browsershots.org (или одна или две виртуальные машины) - это все, что вам нужно!
Я согласен с вашим заявлением о скорости, но я говорю о таких вещах, как двойная загрузка, которая происходит в видео на всех сайтах, кроме сайта Google. Вероятно, есть вещи, которые мы делаем, которые, по нашему мнению, хороши, но выполняются таким образом, что на самом деле это больнее, чем нужно (даже если это быстро), и их можно исправить с небольшим изменением (стандартным способом W3C). без отладчика мы остаемся без понятия. Кодирование, как будто завтра нет.
Это своего рода моя точка зрения - я вообще сомневаюсь, что проблема с двойной загрузкой - это проблема. При загрузке википедии время рендеринга страницы в основном мгновенное (но на больших страницах вы видите, что контент «медленно» появляется, поскольку он загружается по сети). Я считаю, что ваша реакция на перекомпоновку видео - ипохондрия веб-разработчиков!
По сути, я хочу сказать, что задержка в сети по-прежнему является узким местом, и, вероятно, всегда будет ... Нет никакого смысла беспокоиться о "двойной загрузке" в движке Geckos, особенно до тех пор, пока все браузеры не будут одинаково отображать базовый CSS!
По моему профессиональному мнению, действительно существует только один эффективный инструмент для факторинга / оценки / отладки в среде html: Итератор WebDev
Забавно, вы должны ссылаться на это :)
+1 только за то, что показал мне это. Я не могу ответить на ваш вопрос, но если я смогу понять это, я буду полностью в долгу. Лучший пост по HTML, который я видел на SO ...