Проблема в том, что должно все работать без плагинов, мало какие(читай: никакие) заказчики будут требовать от посетителей устанавливать специальный плагин чтобы увидеть сайт. Поэтому exCanvas, реализованный как загружаемый js модуль, является в этом плане более приемлимым.
А для всего остального придется пользовать флэш, который хоть и работает через плагины, но у компании ушли годы и миллионы долларов, чтобы этот плгин стал повсеместным. А кто потратит время и деньги на ваш?
Косяк от этого не зависит. Когда в той же ситуации scrollWidth имеет нормальное значение как во всех браузерах, а scrollHeight нет, это никак не связано ни с доктипом ни бордер боксом.
Извиняюсь, вы внимательно прочитали? Я ни слова не сказал про отображение. Меня, как программиста, беспокоят косяки в програмной части. С отображением статических страничек у Оперы давно все в порядке. Проблемы с динамической сменой контента. Ну и вот местами со значениями свойств.
Вставьте на страничку вызов скрипта — alert( document.getElementsByTagName('div')[0].scrollHeight) и вы увидите разницу.
Для контесктного меню вам нужен тест или сами сможете нарисовать? Вызов event.preventDefault() должен отменять действие по-умолчанию. Фактически контекстное меню, которое им является, не должно показываться, что и происходит например в ФФ, но не в Опере. Максимум что они смогли сделать — опцию в настройках, чтобы скрипт вообще мог события от правой кнопки мыши( на Маке по другому) получать, но правильно отрабатывать дальше — не смогли.
Часть этих багов у них в базе — я им отправлял тесты и репорты. Один из моих репортов был пофиксен.
Есть у меня два конкретных очень простых теста, где Опера и только Опера косячит, могу выложить, если интересно. Есть два теста на которых у Оперы есть проблема, которые выложить абстрактно куда-то не могу, так как они используют фреймворк компании. На самом деле моя компания в контакте с разработчиками браузеров. И по тому как Опера реагирует, но не фиксят, я делаю не очень хорошие выводы о команде и/или руководстве. Мозилла в этом плане намного отзывчивее.
Ну вот на затравку простой тест: <div style="width:300px;height:300px;overflow:auto;"><div style="width:400px;height:300px;">xxx</div></div>
Вопрос какой будет scrollHeight у первого DIV? Ответ — 300px у всех, кроме Оперы. У нее будет на ширину скроллбара увеличен. Причем с scrollWidth такого косяка нет.
эпиграф:… вам шашечки или ехать?..
Удручает то, что Опера занимается только фишечками, да рюшечками, и не фиксят известные баги в ядре, которое обрабатывает html. Такое впечатление, что у них некому это делать. Слышал, что ребята, которые изначально движок разработали, давно уже срулили из Оперы в Мозиллу.
Тем что она есть не только в Опере. Речь идет не про любимый/нелюбимый отладчик/среду разработки. Тут как говорится на вкус и цвет — товарищей нет, а про то что это тулза одна работает под всеми основными браузерами. И, по крайней мере, отладочная печать типа console.log, console.warn, console.dir… будет видна в любом браузере. Плюс можно посмотреть какой там HTML нагенерился. А то помнится бывали веселости с IE при создании таблиц. Ну и консоль в которой можно JS код погонять, посмотреть текущее состояние переменных.
ЗЫ. Никто не утверждает что эта тулза вершина средств разработки :-)
вся прелесть как раз в использовании унифицированного одного инструмента на всех браузерах — написал отладочный код и он везде работает, а не переписывать под каждый браузер еще и отладку.
Я в курсе что есть DragonFly, в курсе и про сафари, но каждый инструмент имеет свой API.
Поиск по тегу firebug не привел к упоминанию об обновлении firebug-lite. А это обновление функциональности значительное, по сравнению с начальной версией этой тулзы.
Как я уехал работать в Амстердам у меня написано тут — tedbeer.net/wp/gollandiya/
Понятно уже прошло почти 2 года, что-то лучше узнал и на какие-то вещи смотрю по-другому.
Конкретно по дизайну — у меня на экране узенькая полоска текста ~460 пикселов где-то в первой трети экрана и 1000 пикселов пустого белого пространства. По-моему давно прошли уже времена, когда верстка под 640х480 была актуальна.
200 строк это не много, я сейчас заканчиваю грид, который может работать и с HTML сгенеренным на сервере и с данными - JSON/XML. 250строк на 35 столбцов рендерится 2-6 секунд(Safari/IE6-8/FF2-3) на средненьком одноядерном компе, нормально скролится, изменение размера столбцов, скрытие, перемена столбцов местами и пр, выбор строк, удаление, редактирование, поддержка клавиатуры. Даже с 5000 строк можно нормально работать, только начальный рендеринг занимает 10-40 секунд. В дальнейшем будет реализована подгрузка данных, так что последнее станет не так актуально. API - стандартный DOM - свойства, аттрибуты, события, можно прицеплять свои обработчики событий, свои редакторы. По поводу расширения/сужения функциональности тоже нет проблем - во фреймворке для которого делается грид есть наследование и расширение классов.
После прочтения статьи осталось впечатление, что для фреймворка (Backbase - backbase.com) для которого я работаю, это все пройденный давно этап.
Фреймворк делается совместимым с новой версией браузера ДО выхода браузера в свет, а не после. Тестируется с бета версиями браузеров. И нормальное явление, что браузеры(беты) косячат, тогда ДО выхода в свет сообщается им об ошибке, вместе с тестом и ошибки устраняются ( хотя Опера бывает игнорирует, в отличие от остальных)
А для всего остального придется пользовать флэш, который хоть и работает через плагины, но у компании ушли годы и миллионы долларов, чтобы этот плгин стал повсеместным. А кто потратит время и деньги на ваш?
Вставьте на страничку вызов скрипта — alert( document.getElementsByTagName('div')[0].scrollHeight) и вы увидите разницу.
my.opera.com/community/forums/topic.dml? id=227959
Есть у меня два конкретных очень простых теста, где Опера и только Опера косячит, могу выложить, если интересно. Есть два теста на которых у Оперы есть проблема, которые выложить абстрактно куда-то не могу, так как они используют фреймворк компании. На самом деле моя компания в контакте с разработчиками браузеров. И по тому как Опера реагирует, но не фиксят, я делаю не очень хорошие выводы о команде и/или руководстве. Мозилла в этом плане намного отзывчивее.
Ну вот на затравку простой тест:
<div style="width:300px;height:300px;overflow:auto;"><div style="width:400px;height:300px;">xxx</div></div>Вопрос какой будет scrollHeight у первого DIV? Ответ — 300px у всех, кроме Оперы. У нее будет на ширину скроллбара увеличен. Причем с scrollWidth такого косяка нет.
Удручает то, что Опера занимается только фишечками, да рюшечками, и не фиксят известные баги в ядре, которое обрабатывает html. Такое впечатление, что у них некому это делать. Слышал, что ребята, которые изначально движок разработали, давно уже срулили из Оперы в Мозиллу.
ЗЫ. Никто не утверждает что эта тулза вершина средств разработки :-)
Я в курсе что есть DragonFly, в курсе и про сафари, но каждый инструмент имеет свой API.
Понятно уже прошло почти 2 года, что-то лучше узнал и на какие-то вещи смотрю по-другому.
После прочтения статьи осталось впечатление, что для фреймворка (Backbase - backbase.com) для которого я работаю, это все пройденный давно этап.
Фреймворк делается совместимым с новой версией браузера ДО выхода браузера в свет, а не после. Тестируется с бета версиями браузеров. И нормальное явление, что браузеры(беты) косячат, тогда ДО выхода в свет сообщается им об ошибке, вместе с тестом и ошибки устраняются ( хотя Опера бывает игнорирует, в отличие от остальных)