Событие submit возникает раньше, чем производится родная браузерная проверка формы (на основании атрибута required и HTML5-типов полей). Более логичным представляется обратный порядок: запускать submit-обработчик только по факту успешного прохождения родных браузерных проверок — подобно тому как клиентская проверка форм предшествует серверной. Именно так, кстати, сделано в Firefox 4 и Safari 5.
У LiveInternet есть существенный недостаток — учитываются только целые номера версий. Например, Firefox 3.0, 3.5 и 3.6 (равно как и Opera 10.0, 10.5 и 10.6) в понимании LiveInternet — одно и то же.
[мечтательно]А ведь когда-то была замечательная статистика Яндекса.[/мечтательно]
Можно долго фантазировать на тему идеального мастера добавления баг-репортов в вакууме, а можно просто взять и сделать так, как делают в цивилизованном мире. В конечном итоге это больше в ваших (компании Opera) интересах, чем в чьих-либо.
Поддержка placeholder для textarea уже стоит в задачах и будет выкачена с очередной порцией обновлений для форм.
Спасибо, Вадим.
А вот насчёт всяких псевдо-элементов, вроде текста placeholder, ошибок валидации форм и т.п. — это уже сложнее. Поле нехоженое, а бездумно принимать Webkit'овские варианты не хочется.
Ну всё ж сделать поддержку псевдокласса или псевдоэлемента -o-placeholder (по аналогии с :-moz-placeholder и ::-webkit-input-placeholder) карман не тянет. Vendor-prefix’ы как раз и гарантируют отсутствие фатальных каких-либо фатальных неустранимых последствий при обеспечении необходимой (и весьма тривиальной в данном случае) функциональности прямо здесь и сейчас. У Firefox и WebKit такая возможность есть, а значит есть возможность использовать placeholder на практике. В Opera же, в условиях невозможности задать цвет текста placeholder’а, поддержка placeholder, увы, по сути сугубо номинальная — и всего лишь из-за того, что чуток недоделали.
Что касается валидации и неправильного события — баг такой уже стоит? Если да, то я бы его продвинул. Если нет, то не мог бы ты его поставить с подробностями и сказать мне номер?
Не уверен, что на написание баг-репорта найдётся время. Проголосовать — проголосовал бы. ;-)
А поддержка placeholder в textarea (в input поддерживается, а в textarea — почему-то нет)?
А возможность задать цвет placeholder’а (в Firefox и WebKit предусмотрена, а в Opera — почему-то нет)?
А исправление бага, связанного с тем, что событие submit происходит вне зависимости от того, есть ли в форме некорректно заполненные поля (на основании атрибутов required и HTML5-типов полей)? (В результате персонально для Opera в JavaScript приходится проверять, поддерживается ли в браузере атрибут required, хотя очевидно, что проверка средствами браузера должна проходить до наступления события submit, и при наличии некорректно заполненных полей событие onsubmit наступать не должно вовсе.)
Проблема в том, что отправляя баг в бездну при помощи вашего текущего «мастера», пользователь создаёт дубликат неминуемо. В то время как в цивилизованной системе типа Bugzilla есть возможность найти существующий баг-репорт и просто проголосовать за его исправление. Число голосов — очень хороший показатель важности бага.
(Например, лично меня судьба Opera волнует не настолько, чтобы терять много времени на написание полномасштабных баг-репортов, а вот проголосовать — проголосовал бы.)
При этом чем серьёзнее пользователь (в градации от обычного пользователя до продвинутого веб-разработчика), тем закономерно серьёзнее (и априори важнее для вас как разработчика браузера) волнующие его баги, и тем выше вероятность того, что он поищет и найдёт существующий баг-репорт.
Серьёзная разработка столь масштабного продукта, как браузер, без цивилизованной системы баг-трекинга невозможна.
Публичный трекер позволяет найти уже существующий баг-репорт. Надо ли говорить, что проголосовать и/или добавить комментарий к существующему баг-репорту гораздо проще, чем писать собственный (до которого с большой вероятностью банально не дойдут руки, особенно у тех, кто ежедневно пользуется совсем другим браузером — обладающий публичным баг-трекером, кстати).
Не подскажете, когда у Opera появится, наконец, нормальная общедоступная база багов типа Bugzilla? Сейчас наверняка захлёбываетесь от дубликатов. Это же, кстати, отбивает желание писать баг-репорты как таковые.
Это «крайне мал» на самом деле несколько лет упорного труда
Несколько лет это, к сожалению, только для тормозов из CSS WG, не способных понять даже то, зачем надо добавить в спецификацию CSS подсвойства background-position-x/-y. overflow-x/-y добавили, а background-position-x/-y, видите ли, не считают оправданным. Притом, что уже существуют две независимых реализации — IE и WebKit — возьми да просто задокументируй. Теоретики.
думаю, что мое мнение разделяет большинство верстальщиков
Скромно. ;-)
Фундамент — это синтаксис. Синтаксис CSS крайне убог и лишён тех базовых возможностей, о которых идёт речь в этой теме. Объём человеческих ресурсов, необходимых для того, чтобы единожды из продумывать и сделать стандартом, крайне мал.
Скажите, современные колонки Sven (точнее одна — основная, к которой подключается вторая) по-прежнему (как и модели, скажем, 5-7-летней давности) утомительно гудят во включённом состоянии?
Событие
submitвозникает раньше, чем производится родная браузерная проверка формы (на основании атрибутаrequiredи HTML5-типов полей). Более логичным представляется обратный порядок: запускать submit-обработчик только по факту успешного прохождения родных браузерных проверок — подобно тому как клиентская проверка форм предшествует серверной. Именно так, кстати, сделано в Firefox 4 и Safari 5.[мечтательно]А ведь когда-то была замечательная статистика Яндекса.[/мечтательно]
Ну всё ж сделать поддержку псевдокласса или псевдоэлемента
-o-placeholder(по аналогии с:-moz-placeholderи::-webkit-input-placeholder) карман не тянет. Vendor-prefix’ы как раз и гарантируют отсутствие фатальных каких-либо фатальных неустранимых последствий при обеспечении необходимой (и весьма тривиальной в данном случае) функциональности прямо здесь и сейчас. У Firefox и WebKit такая возможность есть, а значит есть возможность использовать placeholder на практике. В Opera же, в условиях невозможности задать цвет текста placeholder’а, поддержка placeholder, увы, по сути сугубо номинальная — и всего лишь из-за того, что чуток недоделали.Не уверен, что на написание баг-репорта найдётся время. Проголосовать — проголосовал бы. ;-)
А возможность задать цвет placeholder’а (в Firefox и WebKit предусмотрена, а в Opera — почему-то нет)?
А исправление бага, связанного с тем, что событие submit происходит вне зависимости от того, есть ли в форме некорректно заполненные поля (на основании атрибутов required и HTML5-типов полей)? (В результате персонально для Opera в JavaScript приходится проверять, поддерживается ли в браузере атрибут required, хотя очевидно, что проверка средствами браузера должна проходить до наступления события submit, и при наличии некорректно заполненных полей событие onsubmit наступать не должно вовсе.)
в безднупри помощи вашего текущего «мастера», пользователь создаёт дубликат неминуемо. В то время как в цивилизованной системе типа Bugzilla есть возможность найти существующий баг-репорт и просто проголосовать за его исправление. Число голосов — очень хороший показатель важности бага.(Например, лично меня судьба Opera волнует не настолько, чтобы терять много времени на написание полномасштабных баг-репортов, а вот проголосовать — проголосовал бы.)
При этом чем серьёзнее пользователь (в градации от обычного пользователя до продвинутого веб-разработчика), тем закономерно серьёзнее (и априори важнее для вас как разработчика браузера) волнующие его баги, и тем выше вероятность того, что он поищет и найдёт существующий баг-репорт.
Серьёзная разработка столь масштабного продукта, как браузер, без цивилизованной системы баг-трекинга невозможна.
background-position-x/-y.overflow-x/-yдобавили, аbackground-position-x/-y, видите ли, не считают оправданным. Притом, что уже существуют две независимых реализации — IE и WebKit — возьми да просто задокументируй. Теоретики.Фундамент — это синтаксис. Синтаксис CSS крайне убог и лишён тех базовых возможностей, о которых идёт речь в этой теме. Объём человеческих ресурсов, необходимых для того, чтобы единожды из продумывать и сделать стандартом, крайне мал.