6 декабря 2010 в 11:05
Интервью с Джоном Хрватином (John Hrvatin)
Как и обещали, публикуем интервью с Джоном Хрватиным, которое мы взяли во время его приезда в Москву.
Джон Хрватин (John Hrvatin) — IE9 Lead Program Manager, отвечающий за программную модель, инструменты разработчиков и поддержку стандартов в IE9.
Но, прежде всего, большое спасибо всем хабраюзерам, задававшим свои вопросы!
Q. Зачем Microsoft свой браузер?
A. У Microsoft более 1млрд. Windows-пользователей, которые более половины своего времени в Windows проводят, будучи в сети. Мы разрабатываем Windows Internet Explorer, прежде всего, именно для этих пользователей Windows, чтобы они могли получить самый лучший опыт работе в сети. При этом мы стараемся задействовать по максимуму возможности PC: от современного аппаратного обеспечения, доступного в Windows через такие технологии как Direct2D, до возможностей самой ОС, например, функций «Списки переходов» и «AeroSnap».
Q. Будут ли и дальше свежие сборки Internet Explorer (Platform Preview) выходить каждые 8 недель? Как вы оцениваете этот опыт?
A. Опыт выпуска «platform preview» версий определенно превзошел наши ожидания. Мы сильно впечатлены отзывами, которые мы получили, выпуская промежуточные версии для разработчиков — более 13000 отзывов на Microsoft Connect — мы продолжили эту практику, выпустив 28 октября IE9 Platform Preview 6 (upd: 17 ноября вышел IE9PP7). С этим обновлением разработчики, дизайнеры и наши партнеры могут подготовиться к выпуску RC-версии IE9. Мы продолжаем слушать и внимательно изучать ваши отзывы и используем их в планировании следующих выпусков.
Q. Планируете ли вы сделать автоматическое обновление браузера (независимое от Windows Update), как это сделано в других браузерах?
A. Windows Update (WU) хорошо справляется с задачей поддержания браузера в актуальном состоянии. Мы используем эту систему для доставки обновлений практически каждый месяц и она дает высокие показатели установок. Мы также используем WU для распространения новых версий, но при этом дополнительно ожидаем подтверждения со стороны пользователя, помимо подтвеждения готовности к обновлению со стороны WU, так что пользователи могут сами решить, когда они готовы перейти к новой версии. Она также интегрируется с ПО, управляющим операционной системой и используемым IT-специалистами для управления тем, как обновления IE разворачиваются в их инфраструктуре. Это особенно критично для организаций, бизнес которых зависит от работоспособности браузера.
Q. Планируется ли сделать версию IE9 для WP7? Стоит ли на телефоне ожидать поддержки html5 и других новых стандартов?
A. IE9 все еще находится в процессе разработки, WP7 в некоторых странах уже поступил в продажу и мы готовим начало продаж в других странах очень скоро. В WP7 установлена хорошая стабильная версия IE, и мы продолжим развитие IE на этой платформе.
Q. Как поставить IE9 на XP? Кроме поддержки Direct2D, что еще не позволяет сделать IE9 для XP?
A. IE9 маскимально полно использует возможности компьютера: от аппаратного ускорения с GPU до возможностей операционной системы, например, списки быстрого перехода (JumpList). Мы стремимся предоставить пользователю удобное и производительное решение для работы в интернете. Чтобы добиться этого, мы отталкиваемся от возможностей, доступных в современных операционных системах, включая поддержку Direct2D, не доступной в Windows XP. Direct2D и связанные с ним обновления графической подсистемы — основная причина, не позволяющая IE9 работать на Windows XP, но эта технология критична для IE9, чтобы в полной мере поддерживать HTML5 и не ограничивать при этом веб-разработчиков. Вы можете оценить разницу между IE9 и браузерами, не предлагающими полного аппаратного ускорения, в тестах производительности на www.ietestdrive.com.
Q. Сколько человек работает в вашей команде?
A. Мы не раскрываем эти цифры, но я могу немного рассказать о самой команде и том, как она организована. У нас есть несколько команд, специализирующихся на различной функциональности и соответственно работающих над различными частями браузера. К примеру, моя команда — это «Веб-разработка» и мы работаем над ядром платформы — HTML, DOM, в значительной степени CSS, инструментами разработчика и поддержкой стандартов. Другая команда — «Веб-графика» занимается аппаратным ускорением рендеринга, SVG, Canvas, CSS3 и др. И могу со всей уверенностью сказать, что люди, которые работают над этими задачами и всем другими возможностями браузера — это одни из самых увлеченных и талантливых людей из числа тех, с кем я когда-либо работал. К примеру, вот это главный руководитель группы веб-графики — Ted Johnson.
Q. Какие средства разработки вы используете? (компиляторы, IDE, средства анализа кода и производительности?)
A. Мы используем Visual Studio для написания кода. Мы также используем несколько утилит собственной разработки для управления процессом внесения изменений со стороны разработчиков и анализа кода, ручного тестирования и далее запуска автоматического тестирования перед подтверждением изменений в продукт. Для измерения производительности мы используем публично доступные Windows Performance Tools. В нашем блоге есть отличный пост на эту тему.
Q. Как организован ваш процесс разработки?
A. Основные шаги такие: 1) сбор данных и обратной связи как часть планирования будущих релизов, 2) разработка новых возможностей, и 3) стабилизация. Эти шаги могу накладываться друг на друга в отдельных областях (какая-то функциональность может уже разрабатываться и параллельно мы завершаем планирование в другой области), но в целом процесс выглядит именно так.
Q. Как вы отслеживаете ошибки в браузере и их исправление?
A. Мы используем внутренние инструменты для ведения базы ошибок. Внешние пользователи и партнеры могут оставлять свои пожелания и найденные ошибки через сайт MS Connect и эти сведения попадают напрямую в нашу базу.
Q. Сколько у вас внутри тестов на различные стандарты и функциональность браузера?
A. ОЧЕНЬ много :D У нас огромные наборы тестов — часть из них запускаются каждый день, часть каждую неделю и часть во время специальных этапов проверки прохождения тестов, и все это для уже проверенных функций и для каждой новой функции, которую мы добавляем. Для понимания объемов, посмотрите на CSS 2.1. Только для одного стандарта, мы отправили около 10000 публичных тестов. Это тесты, которые удовлетворяют требованиям W3C. Есть также тесты, которые проверяют взамодействие различных функций с другими частями платформы. В этой статье есть интересный фрагмент о посещении нашей тестовой лаборатории.
Q. Какими процессами в разработке обеспечивается безопасность браузера? Отсутствие ошибок, защищенность пользователя?
A. Как и во всех продуктах Microsoft, мы используем SDL. Этот процесс уже используется много лет и Microsoft опубликовала довольно много материалов, описывающих, как он работает. Я уверен — моя уверенность базируется на моем личном опыте и моих знаниях, а не количественных данных, — что наша команда инженеров по безопасности и наши действия по закрытию проблем в безопасности являются самыми лучшими.
Q. Как вы определяете, какие части html5 или css3 уже можно внедрять в браузере, а какие еще не устоялись/могут измениться и с ними нужно подождать?
A. Наш первый шаг — это всегда послушать, что говорят пользователи. Чего ожидают разработчики? В чем они заинтересованы? По тем функциям, которые внедряются в платформу и которые должны быть совместимыми, мы начинаем смотреть, что говорится в стандартах. Важно, чтобы стандарт был достаточно стабильным. Альтернативой может быть выпуск прототипов или экспериментальной поддержки функций, относительно которых разработчики не могут ожидать, что они будут работать во всех браузерах или будут также поддерживаться в будущих версиях. По тем спецификациям, которые не стабильны, мы включаемся в рабочие группы, чтобы ускорить их стабилизацию с тем, чтобы мы могли добавить их поддержку в IE и разработчики могли рассчитывать на их поддержку.
Q. Почему нельзя из Developer Tools отлаживать модальные окна (showmodaldialog) и инспектировать элементы в них?
A. Это является следствием того, как инструменты разработчика присоединяются к окну. Если быть более точным, они используют функциональность не доступную в модальном окне и мы бы не хотели утяжелять диалоговые окна, добавляя что-то к ним. Мы подумаем, как это улучшить в будущем, будет здорово, если вы оставите нам свой отзыв на Microsoft Connect. К слову, даже если что-то из отзывов на Connect не принято для внесения изменений в IE9, оно по-прежнему хранится в нашей базе и может быть отнесено к будущим версиями. Так что Connect — лучший способ донести до нас отзывы и предложения вроде этого.
Q. Планируете ли вы вы оптимизировать скорость работы DevTools на большом html-дереве? (На больших постах Хабра частенько тормозит)
A. Производительность средств разработки была одним из фокусов при разработке IE9, по сравнению с IE8 мы существенно увеличи скорость работы на больших HTML-деревьях и больших (более 20000 строчек) JavaScript-файлах. Тем не менее большие деревья и файлы всегда работают медленнее, чем маленькие. Если у вас есть примеры, которые показывают особенно плохую производительности, запостите баг на Microsoft Connect — мы посмотрим, что с этим можно сделать.
Q. Почему не исчезает рамка выделенного элемента при закрытии DevTools?
A. Похоже на баг, который хорошо бы отправить на Connect.
Q. Добавится ли возможность удалить элемент из дерева?
A. На сегодня вы можете сделать дерево полностью редактируемым и легко добавлять или удалять узлы по мере необходимости. Вы также можете использовать консоль для удаления узлов через JavaScript. У нас нет встроенной возможности удалить узел через контекстное меню по нажатию правой кнопки мыши — и это хорошо бы занести на Connect.
Q. Появится ли подсветка элемента с margin и padding (при наведении на него или выделении в html-дереве), как это сделано в firebug?
A. Вы можете использовать панель «Layout», в которой отображаются box-параметры любого выбранного элемента. Добавление подсветки на странице – хорошая идея для добавления в Connect.
Q. Можете добавить быстрое добавление нового стиля к существующему классу на вкладке HTML (хотя бы также как на вкладке CSS, через контекстное меню)?
A. Сейчас такой возможности нет, так как на вкладке HTML нет необходимого контекста относительно того, к какому CSS-файлу или блоку стилей нужно добавить соответствующее правило. Это хорошее предложение для добавления в DevTools, но лично я, если мне нужно добавить новое правило, просто добавляю inline-стиль к конкретному элементу или, если мне нужно добавить совсем новое правило, использую вкладку CSS.
Q. Почему средства разработки при отладке принудительно открепляются от окна?
A. Когда вы доходите до точки остановки (breakpoint), соответствующая вкладка замораживается. Если бы окно Dev Tools было бы частью этого окна, оно бы также приостанавливалось. Здесь также свою роль играет изоляция вкладок IE9, которая предотвращает вкладки от взаимного влияния в случае подвисания, и, возможно, хорошим выходом из этой ситуации станет перенос работы отладчика в основное окно браузера. Это как раз один из пунктов для обсуждения, к которым мы хотим вернуться в будущих релизах.
Q. Почему в средствах разработки нельзя при отладке просто выделить переменную и перетащить ее в панель просмотра (Watch), нужно копировать и вручную вставлять.
A. Просто нажмите правую кнопку мыши над переменной, которую вы хотите отслеживать, и выберете “add to watch”, чтобы добавить ее на вкладку Watch. То есть никакого copy-paste не нужно. Эта возможность работает во время отладки (нажмите “start debugging”).
Q. Планируете ли вы добавить средства проверки, как выглядит сайт с мобильных устройств? Режим браузера, user agent string, размеры окна.
A. Вы можете задать необходимые параметры UA String и размеры экрана через DevTools.
Q. Планируете ли вы добавить отображение DOM?
A. Вы можете сделать это в окне “Watch” во время отладки, просто добавив для отслеживания объект windows, document или любую другую часть DOM, в которой вы заинтересованы.
Q. В тесте производительности SunSpider IE9 показывает очень достойный результат. Почему в тестах Kraken (Mozilla), Peacekeeper, Dromaeo (Mozilla), Google V8 результат не столь впечатляющий?
A. При разработке IE9 наша основная цель — обеспечить наилучший опыт работы в вебе на Windows. Скорость, безусловно, одна из важных частей в достижении этой цели, как и, например, облегчение для разработчиков создания нового поколения веб-сайтов и приложений. Мы хотим, чтобы это все работало в реальных используемых сценариях для веб-сайтов — на стандартных паттернах веб-разработки, которые веб-разработчики уже знают и используют. Мы хотим, чтобы это работало лучше и быстрее на PC и на Windows.
Чтобы добиться этого, мы начали с анализа данных об используемых паттернах и практиках в реальных веб-сайтах: что именно они делают и как. Улучшение производительности на множестве различных сценариях в веб требует больше, чем просто оптимизации для прохождения тестов производительности. Чтобы узнать подробнее о данных, которые мы собрали, и как мы их использовали, посмотрите сессию с Jason Weber о разработке высоко-производительных веб-сайтов.
JavaScript — единственная подсистема, тестируемая в Kraken, Peacekeeper и V8 — только одна из составляющих производительности браузера. (Dromaeo тестирует JavaScript и DOM — см. этот пост в нашем блоге, чтобы узнать подробности). Наш подход к ускорению работы браузера в вебе фокусируется на использовании преимуществ того аппаратного обеспечения, которое пользователи уже имеют в своих компьютерах. К примеру, движок JavaScript в IE9 — Chakra — параллельно интерпретирует, выполняет и компилирует код, используя преимущества многоядерных процессоров (CPU). В IE9 также внесено большое архитектурное изменение по перемещению Chakra (нового движка JS) внутрь браузера вместо того, чтобы иметь движок JS, прикрученный где-то сбоку, как это реализовано во многих современных браузерах. Это сильно улучшает производительность в реальных сценариях (из указанных тестов производительности это затрагивает только Dromaeo, т.к. он также тестирует DOM), открывает возможность использовать программную модель ES5 для доступа к DOM и помогает заложить правильный фундамент для будущих HTML5-приложений.
Помимо JavaScript мы переписали движок рендеринга и отображения с тем, чтобы они могли воспользоваться преимуществами GPU. Подсистема рендеринга на некоторых веб-сайтах может иметь не меньшее влияние на производительность, чем скорость JavaScript. По существу, по нашим исследованиям некоторых топовых AJAX-вебсайтов (gmail, Hotmail, google docs and spreadsheets и т.д.) оказывается, что они тратят больше времени на рендеринг, чем на JavaScript (см. об этом в сессии, на которую я указывал выше). И эти улучшения также не учитываются в указанных тестах производительности.
Q. Планируете ли вы оптимизировать работу IE на множестве (~30) стилевых файлов? (это не в production, а при разработке, когда их удобно отлаживать и хранить отдельно, особенно, если это различные модули как в Drupal)
A. Удовлетворение этого запроса намного сложнее, чем может показаться. Мы очень аккуратно подходим к использованию памяти, поэтому мы плотно упаковываем информацию в переменные и константы. Увеличение этого лимита означает увеличение числа битов, используемых для значений, что затрагивает другую хранимую информацию в этих же константах и будет требовать выделения большего количества памяти. Конечно, это не является неразрешимой проблемой, но это не является типовым сценарием для конечных (производственных) версий сайта, поэтому мы направили имеющиеся ресурсы на решение других задач. У нас нет планов вносить изменения в этой области в IE9, однако, мы продолжаем принимать и внимательно изучаем отзывы.
Q. Как отключить советчик по производительности плагинов?
A. Если вас устраивает производительность браузера, вы можете просто выставить больший порог для срабатывания предупреждения (например, 10 секунд). Вы можете узнать подробнее об этом в этом посте.
Q. Будет ли изменена система расширений под IE9?
A. Веб-фрагменты и ускорители, добавленные в IE8, предоставляют разработчикам очень простой (HTML, CSS, JS и XML) способ создавать расширения, покрывающие самые распространенные сценарии. В IE9 мы добавили возможности кастомизации браузера через режим Pinned Sites — favicons, JumpLists, всплывающие иконки и т.д. При подготовке запуска IE9 Beta мы работали с более чем 70 партнерами и видим более 900 сайтов, которые в полной мере пользуются новой возможностью. Подробнее можно узнать здесь (на русском см. тут).
Q. Будет ли удобный фреймворк на .NETе для написаноя дополнений к IE (например, доп. Панели), или по-старинке всё делать только через COM? Сам разрабатываю сейчас ToolBar(.NET WinForms + COM), поэтому довольно животрепещущий вопрос.
A. IE9 поддерживает те же расширения, что и IE8, поэтому существующие просто продолжат работать. Однако мы не добавляли никакой новой функциональности для разработки расширений на .NET.
Q. Как поменять расположение вкладок под адресную строку? Как расположить адресную строку под вкладками?
A. Интерфейс IE9 спроектирован так, чтобы оставить только те функции браузера, которые согласуются с идеей оптимизации пространства, доступного для самих веб-сайтов. Мы внимательно изучаем данные, чтобы понять, как пользователи используют браузер, и что мы увидели, — эти данные покрывают все типы пользователей по всему миру: более 10 миллионов пользователей и сотни миллионов пользовательских сессий, — так это, что более 97% сессий в IE имеют 5 вкладок или меньше, и более 90% пользователей никогда не открывают одновременно более 8 вкладок. Есть не так много сценариев, когда нужно открыть большее количество вкладок, и в этих случаях, вы легко можете увеличить размер области под вкладки, уменьшив размер адресной строки.
Иногда мы видим довольно забавные сценарии (и это также из моего личного опыта), когда люди используют меньше вкладок в одном окне, как только они начинают использовать закрепление сайтов. Попробуйте сами: посмотрите на сайты, которые вы чаще всего открываете и просто закрепите те, которые вы всегда запускаете и в рамках которых вы обычно открываете более одной вкладки. Теперь задача управления сайтами перекладывается на средства Windows: вы можете управлять сайтами также, как вы управляете приложениям вместо того, чтобы ограничиваться возможностями вкладок браузера.
Q. Обрезанная режущая глаз кнопка Назад навсегда войдёт в релиз?
A. Интерфейс IE9 проектировался с тем, чтобы вынести на фон все второстепенные вещи, а не первое место поставить сайт и его содержимое. В этом смысле размещение сайта поверх кнопки «назад» усиливает это впечатление.
Q. Планируете ли вы добавить быстрый доступ к отключению загрузки изображений/flash, как это сделано в Opera?
A. Мы не планируем внедрять новый способ, чтобы решить эту задачу, в IE9. Но это хорошее пожелание для добавления на Connect.
Q. Когда вы обновите окно настроек? Такое ощущение, что оно уже лет 10 не менялось.
A. Наша цель — сделать так, чтобы пользователю не приходилось открывать это окно, браузер должен просто работать — и это именно то, во что мы вкладываем свои усилия. Базовые вещи, вроде изменения домашней страницы, вынесены на первую страницу и легки в использовании.
Джон Хрватин (John Hrvatin) — IE9 Lead Program Manager, отвечающий за программную модель, инструменты разработчиков и поддержку стандартов в IE9.
Но, прежде всего, большое спасибо всем хабраюзерам, задававшим свои вопросы!
Об Internet Explorer
Q. Зачем Microsoft свой браузер?
A. У Microsoft более 1млрд. Windows-пользователей, которые более половины своего времени в Windows проводят, будучи в сети. Мы разрабатываем Windows Internet Explorer, прежде всего, именно для этих пользователей Windows, чтобы они могли получить самый лучший опыт работе в сети. При этом мы стараемся задействовать по максимуму возможности PC: от современного аппаратного обеспечения, доступного в Windows через такие технологии как Direct2D, до возможностей самой ОС, например, функций «Списки переходов» и «AeroSnap».
Q. Будут ли и дальше свежие сборки Internet Explorer (Platform Preview) выходить каждые 8 недель? Как вы оцениваете этот опыт?
A. Опыт выпуска «platform preview» версий определенно превзошел наши ожидания. Мы сильно впечатлены отзывами, которые мы получили, выпуская промежуточные версии для разработчиков — более 13000 отзывов на Microsoft Connect — мы продолжили эту практику, выпустив 28 октября IE9 Platform Preview 6 (upd: 17 ноября вышел IE9PP7). С этим обновлением разработчики, дизайнеры и наши партнеры могут подготовиться к выпуску RC-версии IE9. Мы продолжаем слушать и внимательно изучать ваши отзывы и используем их в планировании следующих выпусков.
Q. Планируете ли вы сделать автоматическое обновление браузера (независимое от Windows Update), как это сделано в других браузерах?
A. Windows Update (WU) хорошо справляется с задачей поддержания браузера в актуальном состоянии. Мы используем эту систему для доставки обновлений практически каждый месяц и она дает высокие показатели установок. Мы также используем WU для распространения новых версий, но при этом дополнительно ожидаем подтверждения со стороны пользователя, помимо подтвеждения готовности к обновлению со стороны WU, так что пользователи могут сами решить, когда они готовы перейти к новой версии. Она также интегрируется с ПО, управляющим операционной системой и используемым IT-специалистами для управления тем, как обновления IE разворачиваются в их инфраструктуре. Это особенно критично для организаций, бизнес которых зависит от работоспособности браузера.
Q. Планируется ли сделать версию IE9 для WP7? Стоит ли на телефоне ожидать поддержки html5 и других новых стандартов?
A. IE9 все еще находится в процессе разработки, WP7 в некоторых странах уже поступил в продажу и мы готовим начало продаж в других странах очень скоро. В WP7 установлена хорошая стабильная версия IE, и мы продолжим развитие IE на этой платформе.
Q. Как поставить IE9 на XP? Кроме поддержки Direct2D, что еще не позволяет сделать IE9 для XP?
A. IE9 маскимально полно использует возможности компьютера: от аппаратного ускорения с GPU до возможностей операционной системы, например, списки быстрого перехода (JumpList). Мы стремимся предоставить пользователю удобное и производительное решение для работы в интернете. Чтобы добиться этого, мы отталкиваемся от возможностей, доступных в современных операционных системах, включая поддержку Direct2D, не доступной в Windows XP. Direct2D и связанные с ним обновления графической подсистемы — основная причина, не позволяющая IE9 работать на Windows XP, но эта технология критична для IE9, чтобы в полной мере поддерживать HTML5 и не ограничивать при этом веб-разработчиков. Вы можете оценить разницу между IE9 и браузерами, не предлагающими полного аппаратного ускорения, в тестах производительности на www.ietestdrive.com.
О команде
Q. Сколько человек работает в вашей команде?
A. Мы не раскрываем эти цифры, но я могу немного рассказать о самой команде и том, как она организована. У нас есть несколько команд, специализирующихся на различной функциональности и соответственно работающих над различными частями браузера. К примеру, моя команда — это «Веб-разработка» и мы работаем над ядром платформы — HTML, DOM, в значительной степени CSS, инструментами разработчика и поддержкой стандартов. Другая команда — «Веб-графика» занимается аппаратным ускорением рендеринга, SVG, Canvas, CSS3 и др. И могу со всей уверенностью сказать, что люди, которые работают над этими задачами и всем другими возможностями браузера — это одни из самых увлеченных и талантливых людей из числа тех, с кем я когда-либо работал. К примеру, вот это главный руководитель группы веб-графики — Ted Johnson.
О разработке
Q. Какие средства разработки вы используете? (компиляторы, IDE, средства анализа кода и производительности?)
A. Мы используем Visual Studio для написания кода. Мы также используем несколько утилит собственной разработки для управления процессом внесения изменений со стороны разработчиков и анализа кода, ручного тестирования и далее запуска автоматического тестирования перед подтверждением изменений в продукт. Для измерения производительности мы используем публично доступные Windows Performance Tools. В нашем блоге есть отличный пост на эту тему.
Q. Как организован ваш процесс разработки?
A. Основные шаги такие: 1) сбор данных и обратной связи как часть планирования будущих релизов, 2) разработка новых возможностей, и 3) стабилизация. Эти шаги могу накладываться друг на друга в отдельных областях (какая-то функциональность может уже разрабатываться и параллельно мы завершаем планирование в другой области), но в целом процесс выглядит именно так.
Q. Как вы отслеживаете ошибки в браузере и их исправление?
A. Мы используем внутренние инструменты для ведения базы ошибок. Внешние пользователи и партнеры могут оставлять свои пожелания и найденные ошибки через сайт MS Connect и эти сведения попадают напрямую в нашу базу.
Q. Сколько у вас внутри тестов на различные стандарты и функциональность браузера?
A. ОЧЕНЬ много :D У нас огромные наборы тестов — часть из них запускаются каждый день, часть каждую неделю и часть во время специальных этапов проверки прохождения тестов, и все это для уже проверенных функций и для каждой новой функции, которую мы добавляем. Для понимания объемов, посмотрите на CSS 2.1. Только для одного стандарта, мы отправили около 10000 публичных тестов. Это тесты, которые удовлетворяют требованиям W3C. Есть также тесты, которые проверяют взамодействие различных функций с другими частями платформы. В этой статье есть интересный фрагмент о посещении нашей тестовой лаборатории.
Q. Какими процессами в разработке обеспечивается безопасность браузера? Отсутствие ошибок, защищенность пользователя?
A. Как и во всех продуктах Microsoft, мы используем SDL. Этот процесс уже используется много лет и Microsoft опубликовала довольно много материалов, описывающих, как он работает. Я уверен — моя уверенность базируется на моем личном опыте и моих знаниях, а не количественных данных, — что наша команда инженеров по безопасности и наши действия по закрытию проблем в безопасности являются самыми лучшими.
О стандартах
Q. Как вы определяете, какие части html5 или css3 уже можно внедрять в браузере, а какие еще не устоялись/могут измениться и с ними нужно подождать?
A. Наш первый шаг — это всегда послушать, что говорят пользователи. Чего ожидают разработчики? В чем они заинтересованы? По тем функциям, которые внедряются в платформу и которые должны быть совместимыми, мы начинаем смотреть, что говорится в стандартах. Важно, чтобы стандарт был достаточно стабильным. Альтернативой может быть выпуск прототипов или экспериментальной поддержки функций, относительно которых разработчики не могут ожидать, что они будут работать во всех браузерах или будут также поддерживаться в будущих версиях. По тем спецификациям, которые не стабильны, мы включаемся в рабочие группы, чтобы ускорить их стабилизацию с тем, чтобы мы могли добавить их поддержку в IE и разработчики могли рассчитывать на их поддержку.
О Developer Tools (F12)
Q. Почему нельзя из Developer Tools отлаживать модальные окна (showmodaldialog) и инспектировать элементы в них?
A. Это является следствием того, как инструменты разработчика присоединяются к окну. Если быть более точным, они используют функциональность не доступную в модальном окне и мы бы не хотели утяжелять диалоговые окна, добавляя что-то к ним. Мы подумаем, как это улучшить в будущем, будет здорово, если вы оставите нам свой отзыв на Microsoft Connect. К слову, даже если что-то из отзывов на Connect не принято для внесения изменений в IE9, оно по-прежнему хранится в нашей базе и может быть отнесено к будущим версиями. Так что Connect — лучший способ донести до нас отзывы и предложения вроде этого.
Q. Планируете ли вы вы оптимизировать скорость работы DevTools на большом html-дереве? (На больших постах Хабра частенько тормозит)
A. Производительность средств разработки была одним из фокусов при разработке IE9, по сравнению с IE8 мы существенно увеличи скорость работы на больших HTML-деревьях и больших (более 20000 строчек) JavaScript-файлах. Тем не менее большие деревья и файлы всегда работают медленнее, чем маленькие. Если у вас есть примеры, которые показывают особенно плохую производительности, запостите баг на Microsoft Connect — мы посмотрим, что с этим можно сделать.
Q. Почему не исчезает рамка выделенного элемента при закрытии DevTools?
A. Похоже на баг, который хорошо бы отправить на Connect.
Q. Добавится ли возможность удалить элемент из дерева?
A. На сегодня вы можете сделать дерево полностью редактируемым и легко добавлять или удалять узлы по мере необходимости. Вы также можете использовать консоль для удаления узлов через JavaScript. У нас нет встроенной возможности удалить узел через контекстное меню по нажатию правой кнопки мыши — и это хорошо бы занести на Connect.
Q. Появится ли подсветка элемента с margin и padding (при наведении на него или выделении в html-дереве), как это сделано в firebug?
A. Вы можете использовать панель «Layout», в которой отображаются box-параметры любого выбранного элемента. Добавление подсветки на странице – хорошая идея для добавления в Connect.
Q. Можете добавить быстрое добавление нового стиля к существующему классу на вкладке HTML (хотя бы также как на вкладке CSS, через контекстное меню)?
A. Сейчас такой возможности нет, так как на вкладке HTML нет необходимого контекста относительно того, к какому CSS-файлу или блоку стилей нужно добавить соответствующее правило. Это хорошее предложение для добавления в DevTools, но лично я, если мне нужно добавить новое правило, просто добавляю inline-стиль к конкретному элементу или, если мне нужно добавить совсем новое правило, использую вкладку CSS.
Q. Почему средства разработки при отладке принудительно открепляются от окна?
A. Когда вы доходите до точки остановки (breakpoint), соответствующая вкладка замораживается. Если бы окно Dev Tools было бы частью этого окна, оно бы также приостанавливалось. Здесь также свою роль играет изоляция вкладок IE9, которая предотвращает вкладки от взаимного влияния в случае подвисания, и, возможно, хорошим выходом из этой ситуации станет перенос работы отладчика в основное окно браузера. Это как раз один из пунктов для обсуждения, к которым мы хотим вернуться в будущих релизах.
Q. Почему в средствах разработки нельзя при отладке просто выделить переменную и перетащить ее в панель просмотра (Watch), нужно копировать и вручную вставлять.
A. Просто нажмите правую кнопку мыши над переменной, которую вы хотите отслеживать, и выберете “add to watch”, чтобы добавить ее на вкладку Watch. То есть никакого copy-paste не нужно. Эта возможность работает во время отладки (нажмите “start debugging”).
Q. Планируете ли вы добавить средства проверки, как выглядит сайт с мобильных устройств? Режим браузера, user agent string, размеры окна.
A. Вы можете задать необходимые параметры UA String и размеры экрана через DevTools.
Q. Планируете ли вы добавить отображение DOM?
A. Вы можете сделать это в окне “Watch” во время отладки, просто добавив для отслеживания объект windows, document или любую другую часть DOM, в которой вы заинтересованы.
О производительности
Q. В тесте производительности SunSpider IE9 показывает очень достойный результат. Почему в тестах Kraken (Mozilla), Peacekeeper, Dromaeo (Mozilla), Google V8 результат не столь впечатляющий?
A. При разработке IE9 наша основная цель — обеспечить наилучший опыт работы в вебе на Windows. Скорость, безусловно, одна из важных частей в достижении этой цели, как и, например, облегчение для разработчиков создания нового поколения веб-сайтов и приложений. Мы хотим, чтобы это все работало в реальных используемых сценариях для веб-сайтов — на стандартных паттернах веб-разработки, которые веб-разработчики уже знают и используют. Мы хотим, чтобы это работало лучше и быстрее на PC и на Windows.
Чтобы добиться этого, мы начали с анализа данных об используемых паттернах и практиках в реальных веб-сайтах: что именно они делают и как. Улучшение производительности на множестве различных сценариях в веб требует больше, чем просто оптимизации для прохождения тестов производительности. Чтобы узнать подробнее о данных, которые мы собрали, и как мы их использовали, посмотрите сессию с Jason Weber о разработке высоко-производительных веб-сайтов.
JavaScript — единственная подсистема, тестируемая в Kraken, Peacekeeper и V8 — только одна из составляющих производительности браузера. (Dromaeo тестирует JavaScript и DOM — см. этот пост в нашем блоге, чтобы узнать подробности). Наш подход к ускорению работы браузера в вебе фокусируется на использовании преимуществ того аппаратного обеспечения, которое пользователи уже имеют в своих компьютерах. К примеру, движок JavaScript в IE9 — Chakra — параллельно интерпретирует, выполняет и компилирует код, используя преимущества многоядерных процессоров (CPU). В IE9 также внесено большое архитектурное изменение по перемещению Chakra (нового движка JS) внутрь браузера вместо того, чтобы иметь движок JS, прикрученный где-то сбоку, как это реализовано во многих современных браузерах. Это сильно улучшает производительность в реальных сценариях (из указанных тестов производительности это затрагивает только Dromaeo, т.к. он также тестирует DOM), открывает возможность использовать программную модель ES5 для доступа к DOM и помогает заложить правильный фундамент для будущих HTML5-приложений.
Помимо JavaScript мы переписали движок рендеринга и отображения с тем, чтобы они могли воспользоваться преимуществами GPU. Подсистема рендеринга на некоторых веб-сайтах может иметь не меньшее влияние на производительность, чем скорость JavaScript. По существу, по нашим исследованиям некоторых топовых AJAX-вебсайтов (gmail, Hotmail, google docs and spreadsheets и т.д.) оказывается, что они тратят больше времени на рендеринг, чем на JavaScript (см. об этом в сессии, на которую я указывал выше). И эти улучшения также не учитываются в указанных тестах производительности.
Q. Планируете ли вы оптимизировать работу IE на множестве (~30) стилевых файлов? (это не в production, а при разработке, когда их удобно отлаживать и хранить отдельно, особенно, если это различные модули как в Drupal)
A. Удовлетворение этого запроса намного сложнее, чем может показаться. Мы очень аккуратно подходим к использованию памяти, поэтому мы плотно упаковываем информацию в переменные и константы. Увеличение этого лимита означает увеличение числа битов, используемых для значений, что затрагивает другую хранимую информацию в этих же константах и будет требовать выделения большего количества памяти. Конечно, это не является неразрешимой проблемой, но это не является типовым сценарием для конечных (производственных) версий сайта, поэтому мы направили имеющиеся ресурсы на решение других задач. У нас нет планов вносить изменения в этой области в IE9, однако, мы продолжаем принимать и внимательно изучаем отзывы.
Q. Как отключить советчик по производительности плагинов?
A. Если вас устраивает производительность браузера, вы можете просто выставить больший порог для срабатывания предупреждения (например, 10 секунд). Вы можете узнать подробнее об этом в этом посте.
О расширениях
Q. Будет ли изменена система расширений под IE9?
A. Веб-фрагменты и ускорители, добавленные в IE8, предоставляют разработчикам очень простой (HTML, CSS, JS и XML) способ создавать расширения, покрывающие самые распространенные сценарии. В IE9 мы добавили возможности кастомизации браузера через режим Pinned Sites — favicons, JumpLists, всплывающие иконки и т.д. При подготовке запуска IE9 Beta мы работали с более чем 70 партнерами и видим более 900 сайтов, которые в полной мере пользуются новой возможностью. Подробнее можно узнать здесь (на русском см. тут).
Q. Будет ли удобный фреймворк на .NETе для написаноя дополнений к IE (например, доп. Панели), или по-старинке всё делать только через COM? Сам разрабатываю сейчас ToolBar(.NET WinForms + COM), поэтому довольно животрепещущий вопрос.
A. IE9 поддерживает те же расширения, что и IE8, поэтому существующие просто продолжат работать. Однако мы не добавляли никакой новой функциональности для разработки расширений на .NET.
Об интерфейсе
Q. Как поменять расположение вкладок под адресную строку? Как расположить адресную строку под вкладками?
A. Интерфейс IE9 спроектирован так, чтобы оставить только те функции браузера, которые согласуются с идеей оптимизации пространства, доступного для самих веб-сайтов. Мы внимательно изучаем данные, чтобы понять, как пользователи используют браузер, и что мы увидели, — эти данные покрывают все типы пользователей по всему миру: более 10 миллионов пользователей и сотни миллионов пользовательских сессий, — так это, что более 97% сессий в IE имеют 5 вкладок или меньше, и более 90% пользователей никогда не открывают одновременно более 8 вкладок. Есть не так много сценариев, когда нужно открыть большее количество вкладок, и в этих случаях, вы легко можете увеличить размер области под вкладки, уменьшив размер адресной строки.
Иногда мы видим довольно забавные сценарии (и это также из моего личного опыта), когда люди используют меньше вкладок в одном окне, как только они начинают использовать закрепление сайтов. Попробуйте сами: посмотрите на сайты, которые вы чаще всего открываете и просто закрепите те, которые вы всегда запускаете и в рамках которых вы обычно открываете более одной вкладки. Теперь задача управления сайтами перекладывается на средства Windows: вы можете управлять сайтами также, как вы управляете приложениям вместо того, чтобы ограничиваться возможностями вкладок браузера.
Q. Обрезанная режущая глаз кнопка Назад навсегда войдёт в релиз?
A. Интерфейс IE9 проектировался с тем, чтобы вынести на фон все второстепенные вещи, а не первое место поставить сайт и его содержимое. В этом смысле размещение сайта поверх кнопки «назад» усиливает это впечатление.
Q. Планируете ли вы добавить быстрый доступ к отключению загрузки изображений/flash, как это сделано в Opera?
A. Мы не планируем внедрять новый способ, чтобы решить эту задачу, в IE9. Но это хорошее пожелание для добавления на Connect.
Q. Когда вы обновите окно настроек? Такое ощущение, что оно уже лет 10 не менялось.
A. Наша цель — сделать так, чтобы пользователю не приходилось открывать это окно, браузер должен просто работать — и это именно то, во что мы вкладываем свои усилия. Базовые вещи, вроде изменения домашней страницы, вынесены на первую страницу и легки в использовании.
Комментарии 132
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.