Comments 28
Радует поддержка File API.
Очень хорошо, что имеется локализованное руководство.
Очень хорошо, что имеется локализованное руководство.
А вот то, что поставить можно только на Windows 8 Preview — совсем нездорово
Новые возможности это конечно хорошо, но вот 9-тка при 30-40 табах открытых практически неработоспособна. Будет нормально 10 сохранять приемлемую отзывчивость работы?
У меня работает нормально, но при условии, что табы разнесены по нескольким окнам. Если в одном окне больше 20 табов открыто, то тоже начинает тормозить.
С учетом того, что каждая таба — свой процесс, думаю, что проблема в том процессе, который отвечает за координацию табов и управление окном браузера.
С учетом того, что каждая таба — свой процесс, думаю, что проблема в том процессе, который отвечает за координацию табов и управление окном браузера.
Кстати нет никакой информации о том измелился ли API для разработки addon или их выпилили вообще. Стив Синофски сказал что ничего стороннего работать не будет в Metro режиме, но в обычном я так понимаю для совместимости будут работать старый функционал.
Так вот что я вам скажу ребята, ваш COM API возможно для 90-х и был шагом вперёд, но в 2011-м разработка addon для IE занимает в 3-5 больше времени чем что-то похожее под Firefox/Chrome.
Я могу только пожелать чтобы IE умер, а Майкрософт занималась развитием операционки, ОфисаЮ, студии, потому что тот пи… ц которій приходится поддерживать думаю надоел уже не только мне.
Так вот что я вам скажу ребята, ваш COM API возможно для 90-х и был шагом вперёд, но в 2011-м разработка addon для IE занимает в 3-5 больше времени чем что-то похожее под Firefox/Chrome.
Я могу только пожелать чтобы IE умер, а Майкрософт занималась развитием операционки, ОфисаЮ, студии, потому что тот пи… ц которій приходится поддерживать думаю надоел уже не только мне.
Может кто нибудь объяснит мне в конце концов, в чем же, собственно, преимущество NPAPI перед COM?
Он, я так понимаю, о расширениях на javascript которые могут быть написаны за полчаса, а не плагинах типо flash
Тулбар для Firefox делается за час. Работа с DOM на возможна в JavaScript. В IE как-будто тоже, но вот что-бы прокидывать данные с открытой страницы в расширение нужен COM.
И кстати для моего расширения в Firefox мне не нужны вызовы из C/C++, потому что запустить приложение/прочитать реестр я могу прямо из JavaScript. И проблема не столько в COM хрен с ним потрачу больше времени но сделаю, а в убогости API, чтобы сохранить страницу полностью нужно ешё Web Cache API подключать. В результате за две недели реализована подержка нужного функционала на Firefox причём за счёт расшаривания функционала покрыли и Windows и Mac, еще неделя пртирование на Chrome и боле 6 НЕДЕЛЬ на IE и полно багов потому что ч'рт побери в XP, Vista, Windows 7 по разному работает Wow3264, а ещё 9-й IE имеет свои соображения насчёт того как грузить ваше расширение, а 7-ой, 8-ой другие.
IE дружелюбный для разработчик, а хрен вам. И ничерта в этом направлении не ведётся. Похороните к этот чёртов браузер и допиливайте офис, винду, студию, действительно хорошие продукты.
И кстати для моего расширения в Firefox мне не нужны вызовы из C/C++, потому что запустить приложение/прочитать реестр я могу прямо из JavaScript. И проблема не столько в COM хрен с ним потрачу больше времени но сделаю, а в убогости API, чтобы сохранить страницу полностью нужно ешё Web Cache API подключать. В результате за две недели реализована подержка нужного функционала на Firefox причём за счёт расшаривания функционала покрыли и Windows и Mac, еще неделя пртирование на Chrome и боле 6 НЕДЕЛЬ на IE и полно багов потому что ч'рт побери в XP, Vista, Windows 7 по разному работает Wow3264, а ещё 9-й IE имеет свои соображения насчёт того как грузить ваше расширение, а 7-ой, 8-ой другие.
IE дружелюбный для разработчик, а хрен вам. И ничерта в этом направлении не ведётся. Похороните к этот чёртов браузер и допиливайте офис, винду, студию, действительно хорошие продукты.
Тулбар для IE делается минут за 5 (весь код генерируется студией). Писать в реестр из JScript Вы можете и в IE (если зона доверия позволяет) — да-да, через COM.
Насчет прокидывания данных через COM чего то я не понял. MSHTML-овый DOM это И ЕСТЬ набор COM-объектов. Не нужно ничего «прокидывать» — ими нужно просто пользоваться НАПРЯМУЮ.
Что до убогости API — не могу ничего сказать — не углублялся. Но отсутствие нужных интерфейсов это, как Вы уже отметили, проблема не объектного фреймворка.
Напомню, что Вы начали с утверждения, что COM устарел и настолько фундаментально испорчен, что остается только его выбросить. Кроме того, неясно зачем хоронить IE, если вся проблема в «убогости API».
Насчет прокидывания данных через COM чего то я не понял. MSHTML-овый DOM это И ЕСТЬ набор COM-объектов. Не нужно ничего «прокидывать» — ими нужно просто пользоваться НАПРЯМУЮ.
Что до убогости API — не могу ничего сказать — не углублялся. Но отсутствие нужных интерфейсов это, как Вы уже отметили, проблема не объектного фреймворка.
Напомню, что Вы начали с утверждения, что COM устарел и настолько фундаментально испорчен, что остается только его выбросить. Кроме того, неясно зачем хоронить IE, если вся проблема в «убогости API».
Может я чего не понимаю, но покажете мне студию которая без сторонних расширений сгенерирует вам тулбар за 5 минут? Мягко говоря вы заблуждаетесь.
MSHTML — DOM хорошо давайте попробуем сохранить всю страницу, ой блин а нам нужен ещё IPersist и ещё все ресурсы страницы(картинки, скрипты, стили) давайте рекурсивно по DOM-у находите ссілки на внешние ресурсы и если не хотите качать заново(а если заново то подтягивайте куки из пользовательской сесии) то исспользуйте web cache api, который очень С-шный API. Когда всё это собрать вместе получается гремучая смесь.
COM в составе Windows почти с её сотворения он не может устареть. Только с времён IE5 в внутреннем API нечего не меняется. Он каков был таков и остался. Устареть может програмная модель IE, сегодня другие требования к програмному интерфейсу выдвигаются, да взять тот же .NET. Для Firefox/Chrome уже школьник может писать расширения. Неужели за 10 лет нельзя было ничего улучшить? Была попытка с SPicIE, но её она не получила достаточной поддержки, Microsoft-у стало неинтересно и забросили.
" Что до убогости API — не могу ничего сказать — не углублялся. Но отсутствие нужных интерфейсов это, как Вы уже отметили, проблема не объектного фреймворка." — Если инструмент не позволяет решить задачу с приемлемой затратой ресурсов может к чёрту этот инструмент. Да вот проблема сидит на разных версиях IE до 40% пользователей так что приходится жрать кактус.
— Кроме того, неясно зачем хоронить IE, если вся проблема в «убогости API». —
И никто ничего с этой убогостью делать не собирается, нам дадут красивую обёртку, а всередине останется то же убожество.
MSHTML — DOM хорошо давайте попробуем сохранить всю страницу, ой блин а нам нужен ещё IPersist и ещё все ресурсы страницы(картинки, скрипты, стили) давайте рекурсивно по DOM-у находите ссілки на внешние ресурсы и если не хотите качать заново(а если заново то подтягивайте куки из пользовательской сесии) то исспользуйте web cache api, который очень С-шный API. Когда всё это собрать вместе получается гремучая смесь.
COM в составе Windows почти с её сотворения он не может устареть. Только с времён IE5 в внутреннем API нечего не меняется. Он каков был таков и остался. Устареть может програмная модель IE, сегодня другие требования к програмному интерфейсу выдвигаются, да взять тот же .NET. Для Firefox/Chrome уже школьник может писать расширения. Неужели за 10 лет нельзя было ничего улучшить? Была попытка с SPicIE, но её она не получила достаточной поддержки, Microsoft-у стало неинтересно и забросили.
" Что до убогости API — не могу ничего сказать — не углублялся. Но отсутствие нужных интерфейсов это, как Вы уже отметили, проблема не объектного фреймворка." — Если инструмент не позволяет решить задачу с приемлемой затратой ресурсов может к чёрту этот инструмент. Да вот проблема сидит на разных версиях IE до 40% пользователей так что приходится жрать кактус.
— Кроме того, неясно зачем хоронить IE, если вся проблема в «убогости API». —
И никто ничего с этой убогостью делать не собирается, нам дадут красивую обёртку, а всередине останется то же убожество.
Full disclosure: для большей части моего браузинга, я использую Хром со все увеличивающейся долей IE9 (и 10 — у меня есть таблетка и хром там, откровенно говоря, сосет невероятно).
Если бы вообще генерировалось автоматически, это было бы «5 секунд», а не «5 минут». Вообще, тулбары я не писал а писал BHO, но бегло просмотрев документацию, существенных отличий не вижу. Вот пошаговый пример создания BHO за 5 минут и да, практически вся обвязка генерируется автоматически.
Даже если нет другого пути (мне лень пытаться разбираться, тем более, что Вы сказали, что потратили на это полтора месяца) — это не вопрос «убогости» COM и даже не вопрос «убогости» IE — все сводится к доступному API (IE то страницы сохранять умеет, просто не предоставляет эту возможность «наружу»).
Вот опять Вы сравниваете «расширения» с плагинами. Расширения вполне себе реализуются как еще один уровень абстракции над плагинами (если не ошибаюсь та же жирная обезьяна была реализована в виде плагина). И лично мне COM нравится гораздо больше, чем NPAPI. Другое дело, что они не реализованы «из коробки» (но реализовано другое). Можно говорить (и поспорить) об «убогости» станадртной ПОСТАВКИ, но никаких свидетельств «убогости» платформы.
Да ради бога, вот только если уж взялись назначать виновных — назначайте их правильно. Лично меня совершенно не волнуют проблемы написания тулбаров (я терпеть не могу даже те, что уже есть — не говоря уж о новых). Это же, похоже, относится к тем 40% пользователей IE, которых Вы упомянули. Более того, есть у меня подозрение, что Хромом/Файрфоксом в подавляющем большинстве случаев пользуются не из-за легкости создания тулбаров.
Мне кажется Вы уже имеете «вывод» (IE — убожество и должен умереть) и пытаетесь подтягивать под него «факты». Ничего, что внутри файрфокса фактически то же самое «убожество» (IUnknown переименован в nsISupports и вместо ProgID используются ContractID, но архитектурно они идентичны)? Более того, одно время у файрфокса были XPCOM-овые плагины, которые позже заменили на более примитивные NPAPI. Ничего, что Вас всю дорогу не устраивала именно «некрасивость» обертки и НИ ОДНОГО аргумента против собственно COM (и IE) Вы так и не выдали?
Может я чего не понимаю, но покажете мне студию которая без сторонних расширений сгенерирует вам тулбар за 5 минут?
Если бы вообще генерировалось автоматически, это было бы «5 секунд», а не «5 минут». Вообще, тулбары я не писал а писал BHO, но бегло просмотрев документацию, существенных отличий не вижу. Вот пошаговый пример создания BHO за 5 минут и да, практически вся обвязка генерируется автоматически.
MSHTML — DOM хорошо давайте попробуем сохранить всю страницу, ой блин а нам нужен ещё IPersist и ещё все ресурсы страницы
Даже если нет другого пути (мне лень пытаться разбираться, тем более, что Вы сказали, что потратили на это полтора месяца) — это не вопрос «убогости» COM и даже не вопрос «убогости» IE — все сводится к доступному API (IE то страницы сохранять умеет, просто не предоставляет эту возможность «наружу»).
Для Firefox/Chrome уже школьник может писать расширения.
Вот опять Вы сравниваете «расширения» с плагинами. Расширения вполне себе реализуются как еще один уровень абстракции над плагинами (если не ошибаюсь та же жирная обезьяна была реализована в виде плагина). И лично мне COM нравится гораздо больше, чем NPAPI. Другое дело, что они не реализованы «из коробки» (но реализовано другое). Можно говорить (и поспорить) об «убогости» станадртной ПОСТАВКИ, но никаких свидетельств «убогости» платформы.
Если инструмент не позволяет решить задачу с приемлемой затратой ресурсов может к чёрту этот инструмент.
Да ради бога, вот только если уж взялись назначать виновных — назначайте их правильно. Лично меня совершенно не волнуют проблемы написания тулбаров (я терпеть не могу даже те, что уже есть — не говоря уж о новых). Это же, похоже, относится к тем 40% пользователей IE, которых Вы упомянули. Более того, есть у меня подозрение, что Хромом/Файрфоксом в подавляющем большинстве случаев пользуются не из-за легкости создания тулбаров.
И никто ничего с этой убогостью делать не собирается, нам дадут красивую обёртку, а всередине останется то же убожество.
Мне кажется Вы уже имеете «вывод» (IE — убожество и должен умереть) и пытаетесь подтягивать под него «факты». Ничего, что внутри файрфокса фактически то же самое «убожество» (IUnknown переименован в nsISupports и вместо ProgID используются ContractID, но архитектурно они идентичны)? Более того, одно время у файрфокса были XPCOM-овые плагины, которые позже заменили на более примитивные NPAPI. Ничего, что Вас всю дорогу не устраивала именно «некрасивость» обертки и НИ ОДНОГО аргумента против собственно COM (и IE) Вы так и не выдали?
Простите, но что за название функции «msElementsFromRect»? Опять плодим «свои» стандарты?
нет, это вендор-префикс, вы же знаете про всякие -moz-, -webkit-, -o-? В функциях JS тоже самое. В будущем функция будет называться ElementsFromRect.
А почему бы сразу не сделать ElementsFromRect, чтобы потом не требовалось переписывать код? Сейчас это больше походит на ситуацию, при которой для одних браузеров нужно использовать одни функции, для других — другие, несмотря на полную идентичность задачи и отдаваемого результата.
Другими словами, Microsoft сами делят все браузеры на нормальные и на IE. Не все ещё наелись кроссбраузерной поддержкой за последние 10 лет?
Другими словами, Microsoft сами делят все браузеры на нормальные и на IE. Не все ещё наелись кроссбраузерной поддержкой за последние 10 лет?
Потому что нет стандарта ElementsFromRect. И если в других браузерах потом его реализуют иначе, и функция будет возвращать иные значения, вы будете очень расстроены, и будете очень ругать IE, потому что эта функция там работает «не так».
Префиксы для нестандартных функций и свойств CSS — правильный путь.
Префиксы для нестандартных функций и свойств CSS — правильный путь.
Если нет стандарта, то что эта функция делает в IE? Если стандарт является черновым и очень хочется реализовать его часть, то в случае с необновляемым IE, нужно реализовывать сразу итоговую функцию с полным пониманием того, что этой версией будут пользоваться ещё несколько лет.
Если стандарт, выйдя из драфта, изменится уже после выхода стабильной версии IE — никто не будет ничего переделывать, потому как будут гипотетические пользователи данного функционала. Получается, что окончательное название функции будет только в следующей версии, а это означает, что в течение нескольких лет, разработчики будут вынуждены отделять IE от не-IE, как и раньше, как и сейчас.
Если стандарт, выйдя из драфта, изменится уже после выхода стабильной версии IE — никто не будет ничего переделывать, потому как будут гипотетические пользователи данного функционала. Получается, что окончательное название функции будет только в следующей версии, а это означает, что в течение нескольких лет, разработчики будут вынуждены отделять IE от не-IE, как и раньше, как и сейчас.
Не понимаю, что вы предлагаете:
1. Убрать msElementsFromRect, лишив программистов нового нужного функицонала
2. Назвать ее ElementsFromRect, и войти в риск осказаться несовместимым со всеми браузерами, повторив ошибки IE6, когда одни и те же вещи работают по-разному
Не используйте эту функцию, если она вам по каким-то причинам не нравится. Майкрософт дает возможность использовать нестандартный функционал тем, кому он нужен, не нарушая совместимости. Функции ElementsFromRect нет, может появится в будущем, а может и нет. Есть ноу-хау Майкрософта, msElementsFromRect, для тех, кому не хватает стандартизированного функционала.
Наличие CSS-префиксов -ms, -moz и прочих, вас тоже смущает? А они не раз меня спасали, когда, вроде, одно и то же свойство работает по-разному в разных браузерах, потому что в стандарте это не прописано, и значения приходилось задавать разные.
1. Убрать msElementsFromRect, лишив программистов нового нужного функицонала
2. Назвать ее ElementsFromRect, и войти в риск осказаться несовместимым со всеми браузерами, повторив ошибки IE6, когда одни и те же вещи работают по-разному
Не используйте эту функцию, если она вам по каким-то причинам не нравится. Майкрософт дает возможность использовать нестандартный функционал тем, кому он нужен, не нарушая совместимости. Функции ElementsFromRect нет, может появится в будущем, а может и нет. Есть ноу-хау Майкрософта, msElementsFromRect, для тех, кому не хватает стандартизированного функционала.
Наличие CSS-префиксов -ms, -moz и прочих, вас тоже смущает? А они не раз меня спасали, когда, вроде, одно и то же свойство работает по-разному в разных браузерах, потому что в стандарте это не прописано, и значения приходилось задавать разные.
Нет в стандарте, значит и не должно быть в браузере. Логично, вроде. Нет? В противном случае, мы просто увеличиваем количество животных в нашем, и без того полном, зоопарке.
Наличие CSS-префиксов меня тоже смущает, как, думаю, и вас.
Мы с вами говорим сейчас не о том, как есть, а о том, как следовало бы быть. Так вот, следовало бы, чтобы:
1) стандарт чётко описывал то, что может быть и как оно должно работать. Сейчас, вроде, к этому и стремятся, но с такими усилиями, как сейчас, мы с вами будем ещё лет 5 поддерживать кучу разношёрстных «стандартов».
2) разработчики браузеров не прыгали выше головы, реализуя свои стандарты, а работали в команде над созданием и реализацией общих стандартов.
Наличие CSS-префиксов меня тоже смущает, как, думаю, и вас.
Мы с вами говорим сейчас не о том, как есть, а о том, как следовало бы быть. Так вот, следовало бы, чтобы:
1) стандарт чётко описывал то, что может быть и как оно должно работать. Сейчас, вроде, к этому и стремятся, но с такими усилиями, как сейчас, мы с вами будем ещё лет 5 поддерживать кучу разношёрстных «стандартов».
2) разработчики браузеров не прыгали выше головы, реализуя свои стандарты, а работали в команде над созданием и реализацией общих стандартов.
Ну вы же понимаете, что стандартизация — это процесс. В случае с W3C спецификация проходит стадии от Working Draft до W3C Recommendation.
На одном из промежуточных этапов — Candidate Recommendation — консорциум ожидает, что вендоры начнут реализовывать предложенный стандарт. Если окажется, что какие-то аспекты реализации трудно выполнимы или сильно бьют по производительности, или, например, в процессе работы возникают новые идеи для API, то вендор может внести свои предложения. Предложения собираются, унифицируются, и на базе них составляется новая редакция стандарта — Proposed Recommendation.
Таким образом у вендора может сложиться ситуация, когда в процессе работы над стандартом возниктнет две частично несовместимые реализации. Поэтому, чтобы различить их, для разработчиков вводят префиксы. Иначе возникла бы ситуация, при которой браузер заявляет о поддержке стандарта, веб-разработчики начинают использовать это API, а затем при переходе от CR к PR все приложения, написанные на старом API сломались в один день.
Поверьте, подобный сценарий не нужен никому. Поэтому и делают две версии API — с префиксом и без. Чтобы с одной стороны, получить представление о том, как API будет использоваться, а с другой — не сломать приложения тех разработчиков, которые рискнули и решили использовать новое API.
Если б префиксов не было, веб-разработчики боялись бы использовать новое API, зная, что в какой-то момент их приложения могут сломаться.
На одном из промежуточных этапов — Candidate Recommendation — консорциум ожидает, что вендоры начнут реализовывать предложенный стандарт. Если окажется, что какие-то аспекты реализации трудно выполнимы или сильно бьют по производительности, или, например, в процессе работы возникают новые идеи для API, то вендор может внести свои предложения. Предложения собираются, унифицируются, и на базе них составляется новая редакция стандарта — Proposed Recommendation.
Таким образом у вендора может сложиться ситуация, когда в процессе работы над стандартом возниктнет две частично несовместимые реализации. Поэтому, чтобы различить их, для разработчиков вводят префиксы. Иначе возникла бы ситуация, при которой браузер заявляет о поддержке стандарта, веб-разработчики начинают использовать это API, а затем при переходе от CR к PR все приложения, написанные на старом API сломались в один день.
Поверьте, подобный сценарий не нужен никому. Поэтому и делают две версии API — с префиксом и без. Чтобы с одной стороны, получить представление о том, как API будет использоваться, а с другой — не сломать приложения тех разработчиков, которые рискнули и решили использовать новое API.
Если б префиксов не было, веб-разработчики боялись бы использовать новое API, зная, что в какой-то момент их приложения могут сломаться.
Я понимаю, что это процесс и должно пройти какое-то время между этапами утверждения стандарта. Для таких целей, в мире десктопных программ, обычно выпускается специальная девелоперская версия со всеми непроверенными плюшками (да хоть с префиксами в названиях функций). Ну вот кто мешал сделать отдельную ветку для IE, в которой разработчики могли бы играться с этой злосчастной функцией (всё равно она больше нигде не будет работать с таким названием)?
Насколько я понимаю, она скорее всего попадёт в релиз именно в таком виде, как есть сейчас, а это, как мы помним, ни к чему хорошему не приводит.
А вообще, наверное, я лучше заткнусь со своим перфекционизмом, раз в данном кругу, это не вызывает одобрения.
Насколько я понимаю, она скорее всего попадёт в релиз именно в таком виде, как есть сейчас, а это, как мы помним, ни к чему хорошему не приводит.
А вообще, наверное, я лучше заткнусь со своим перфекционизмом, раз в данном кругу, это не вызывает одобрения.
это не совсем ноу-хау Microsoft, это общий стандат, который обсуждается в рамках комитетов по стандартизации, например вот тут обсуждение по данным функциям в web-kit
О чем тут говорить — будет стандарт на ElementsFromRect, будет и такая функция, работающая именно так, как описано в стандарте. А пока стандарта нет, есть ее майкрософтовская реализация, которая работает так, как кажется логичным майкрософту, и называется, соотвественно иначе, чтобы не было путаницы.
стандарт есть и он обсуждается, имена утверждаются и так далее, как и в случае с префиксами в CSS пользователи должны явно понимать где утвержденное наименование стандарта, а где вещи, которые могут и будут меняться.
Sign up to leave a comment.
Субтитры в HTML5 Video, CORS, FileAPI Writer и другие новинки в новом превью Internet Explorer 10