Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 82
Так а что вы хотели… таки 2022 год по таймлайну — рекомендация. Может, к тому времени процент IE6 будет равен 1-3…
К 2012 году все настолько поменяется (вспомним 1997?), что эти контролы нафиг никому нужны не будут. Все будет либо на Flash, либо на Silverlight, либо (о, боже!) O3D от Google… Кто знает, что там будет? К тому же все можно сделать и так, на jQuery, ExtJS, и т.д., и т.п… Потому и не спешат.
Даже 2022… Что было в далеком 1987? На самом деле лично я не знаю что думать о полезности этих фич. С одной стороны это — да, плюс. Не надо городить сложные вещи. Вроде бы как даже много готового. Но с другой стороны — все равно все переделают под свой дизайн. И получится что проще использовать готовые Javascript фреймфорки, в которых все это есть давно. Из интересностей — поддержка тега видео. И то. Встраивай ты себе на сайт YouTube. Проблем никаких и возможностей больше. И денег не стоит. В общем, на мой взгляд, полезность всего этого под вопросом. Но опять же, это мое «имхо».
Про время это все ирония… Понятно что все сделают за пару месяцев
12 лет!!! Они там совсем охренели что ли?!!! Что можно выдумывать целых 12 лет?! Да через это время от привычного гипертекстового веба может ничего и не останется. Можно подумать, они там не язык разметки утверждают, а стандартизируют С++ или изобретают искусственный интеллект.
Вроде бы уже сто раз объяснялось что нереальный срок взят с потолка специально и никому не запрещает пользоваться (реализовывать в браузерах) уже сейчас. Должно устраивать всех, подходить всем и чтоб не надо было придумывать новый стандарт через год.
а как вы думаете, сколько ещё будут использовать xhtml1.1? сколько потом будут использовать html5? 50 лет? меньше дадите?
Ядерная война на как раз 10 лет, +пару лет на то что бы всё утряслось.
Хватит уже гонять эту глупую дату.
Само запостилось. Продолжение:
Ian Hickson объяснил, что это дата взята по максимуму и тогда все браузеры должны будут поддерживать HTML5 до буквы. А десять лет будут готовиться тесты, без которых нормально написать движок рендеринга сложно.
Вы знаете, что в HTML5 для браузеров описано огромное количество указаний, как правильно рендерить плохой HTML? Вот этим они 10 лет заниматься и будут.
Основные функции HTML5 можно и нужно использовать уже сегодня, а бразеры их должны бы начать поддерживать до 2012 года.
Ian Hickson объяснил, что это дата взята по максимуму и тогда все браузеры должны будут поддерживать HTML5 до буквы. А десять лет будут готовиться тесты, без которых нормально написать движок рендеринга сложно.
Вы знаете, что в HTML5 для браузеров описано огромное количество указаний, как правильно рендерить плохой HTML? Вот этим они 10 лет заниматься и будут.
Основные функции HTML5 можно и нужно использовать уже сегодня, а бразеры их должны бы начать поддерживать до 2012 года.
так а что вы хотели… таки спецификация css2.1 ещё не утверждена, а её во всю юзают браузеры.
Опере зачет, остальные на пересдачу!
html5 внедрят скоро, google wave разрабатывают на нем, значит к выпуску продукта, производители браузеров подтянут поддержку html5 в своих продуктах чтобы не отставать от мирового тренда
кому что) я люблю лису)
Солнце лето и трава) мы танцуем до утра)
Вид в Safari 3 под Mac OS X, отличие в закруглённом поле type=«search», ну и более внятный системный вид диапазона.
Упс.
Дак и в винде у диапазона тоже системный вид :)
А search сложно было распознать, в винде оно такое-же прямоугольное, добавил.
А search сложно было распознать, в винде оно такое-же прямоугольное, добавил.
Ну, мне кажется, что пользователи Visa/Seven и даже XP при виде такого «системного контрола» могут испугаться )
Vista *
Я тебя не понимаю :)
Ты имеешь ввиду, что у меня на скриншоте диапазон выглядит не как системный? Это не так, в моей системной теме диапазон так и выглядит. Или ты имеешь ввиду, что некоторые люди могут не понят по скриншоту, что это у меня такой системный вид? :)
Ты имеешь ввиду, что у меня на скриншоте диапазон выглядит не как системный? Это не так, в моей системной теме диапазон так и выглядит. Или ты имеешь ввиду, что некоторые люди могут не понят по скриншоту, что это у меня такой системный вид? :)
Ага, ага… есть категория дизайнеров которые будут рисовать эти контролы на свой лад…
Подписал бы инпуты
Учитывая, что каждый третий дизайнер мнит себя выдаюшимся создателем контролов и непризнанным гением гуи-инженеринга, можно смело заявить: пусть хоть завтра все браузеры будут поддерживать новые спецификации, грамандная масса контролов все также будет представлять из себя html 3.2 с ява-скрипт обвесом.
А как иначе? Все эти контролы будут выглядеть по-разному в разных браузерах. [к дизайнерам отношения не имею]
Ну я про внешний вид даже словом не обмолвился — все сказанное про функционал.
А по поводу внешнего вида — тут как раз ни каких проблем нет, поскольку контролы не обязаны выглядеть во всех браузерах одинаково и по умолчанию даже банальные кнопки и чекбоксы в каждом выглядят по-своему.
Визуализация — это уже вопрос не html'а, а css. И я подозреваю, что после устаканивания и принятия стандарта html 5 пойдет вторая волна споров и прений по поводу css, ведь каждый вендор будет пропихивать свою интерпритацию css-свойств для новых тэгов.
Короче, браузерная война не закончится никогда =)
А по поводу внешнего вида — тут как раз ни каких проблем нет, поскольку контролы не обязаны выглядеть во всех браузерах одинаково и по умолчанию даже банальные кнопки и чекбоксы в каждом выглядят по-своему.
Визуализация — это уже вопрос не html'а, а css. И я подозреваю, что после устаканивания и принятия стандарта html 5 пойдет вторая волна споров и прений по поводу css, ведь каждый вендор будет пропихивать свою интерпритацию css-свойств для новых тэгов.
Короче, браузерная война не закончится никогда =)
Функционал? Не пойму тогда связи с дизайнерами.
Мы наверно о разных вещах говорим: вы о стандартных компонентах (их поведении), к которым привыкли прользователи, а я о их внешнем виде (компонетов, сравнить например input type=file в разных браузерах сейчас).
Имхо, игнорировать эти различия дизайнер не может. Сейчас css-ом не все решается, порой проще свой контрол придумать. В будущем может и сделают «правильно»
Мы наверно о разных вещах говорим: вы о стандартных компонентах (их поведении), к которым привыкли прользователи, а я о их внешнем виде (компонетов, сравнить например input type=file в разных браузерах сейчас).
Имхо, игнорировать эти различия дизайнер не может. Сейчас css-ом не все решается, порой проще свой контрол придумать. В будущем может и сделают «правильно»
Непонятность у вас возникает из-за того, что вы почему-то разделяете функционал контрола от его дизайна. У «чистых» конролов это разделение на самом деле есть. Если дизайнер меняет контрол исключительно средставими css, то это работает. Но как вы сами выразились, одним css'ом все не решается и в дело вступает программист, реализуя задумки дизайнера (графического или интерфейсного) уже методами яваскрипата.
Возьмем самый простой пример. Вместо кнопки отправки формы дизайнер хочет сделать картинку. В этом случае, возможно, программист и не понадобится — все решается прописыванием элементарных обработчиков событий для картинки.
Другой пример: дизайнер хочет сделать поле ввода с заранее предустановленным значением (например, «введиде e-mail»), которые бы исчезало при получении полем фокуса и снова появлялось, если фокус ушел, но ничего введено не было. При чем эта «подсказка» должна отображаться серым цветом, а введенное пользователем значение — черным. Тут уже программное вмешательство более сильное.
В итоге получается, что над контролом работает и дизайнер, и программист (ну или человек, совмещающий эти две функции). В итоге мы имеем на выходе свой контрол, сильно отличающийся от оригинального. И это всего лишь простое поле ввода. Для более сложных элементов примочек и заморочек будет еще больше. И я еще даже не затронул темы клиент-сайд валидации.
Так вот своим постом я хотел сказать, что чтобы ни придумывали стандартизаторы, все равно будут дизайнеры, которые все также будут использовать старые контролы с примочками и даже на новые контролы прилепят кучу всяких примочек. И таких будет много.
Возможно, непонятность возникла из-за того, что вы под дизайнером подразумеваете чисто визуальщика, а я под понятием «дизайнер» еще подразумеваю человека, занимающегося интерфейсом =)
Возьмем самый простой пример. Вместо кнопки отправки формы дизайнер хочет сделать картинку. В этом случае, возможно, программист и не понадобится — все решается прописыванием элементарных обработчиков событий для картинки.
Другой пример: дизайнер хочет сделать поле ввода с заранее предустановленным значением (например, «введиде e-mail»), которые бы исчезало при получении полем фокуса и снова появлялось, если фокус ушел, но ничего введено не было. При чем эта «подсказка» должна отображаться серым цветом, а введенное пользователем значение — черным. Тут уже программное вмешательство более сильное.
В итоге получается, что над контролом работает и дизайнер, и программист (ну или человек, совмещающий эти две функции). В итоге мы имеем на выходе свой контрол, сильно отличающийся от оригинального. И это всего лишь простое поле ввода. Для более сложных элементов примочек и заморочек будет еще больше. И я еще даже не затронул темы клиент-сайд валидации.
Так вот своим постом я хотел сказать, что чтобы ни придумывали стандартизаторы, все равно будут дизайнеры, которые все также будут использовать старые контролы с примочками и даже на новые контролы прилепят кучу всяких примочек. И таких будет много.
Возможно, непонятность возникла из-за того, что вы под дизайнером подразумеваете чисто визуальщика, а я под понятием «дизайнер» еще подразумеваю человека, занимающегося интерфейсом =)
Жалко конечно, что браузеры пока не поддерживают такую чудесную штуковину, но например гугл давно нашёл выход из ситуации, правда для джедаев. Там много явы, и в общем-то импутовское поле выглядит мило. К примеру пользовательский поиск на ресурсах. Не пиара ради, а ознакомления для devilart.net — выкладка поиск.
>единственный браузер, поддерживающий больше одного контрола — Опера.
Safari 2 может, судя по скрину
Safari 2 может, судя по скрину
Был как-то топик, в котором предлагалось голосовать за баг связанный с загрузкой нескотльких файлов в один инпут (кстати, в опере тоже работает). Может и за этот стоит активно проголосовать.
эти зависимости — «баги» про отдельные инпуты, чтобы не мешать всё в кучу
Поспешишь — людей насмешишь (это в адрес Opera)
Нам такая поддержка контролов не нужна!
Нам такая поддержка контролов не нужна!
Конечно! Ведь Ian Hickson, автор HTML5 написал первый драфт, «Web Forms 2.0» работая в Opera!
да обвешаете жабаскриптами, все будет нормально. вебдевелоперам и прочим дизайнерам не привыкать
Идея хорошая… вот если бы её реализовали все и сразу (включая обязательный патч для всех уже вышедших IE, начиная с IE6). Если бы… Вряд ли приживётся это: вот я разработчик сайтов, я ведь не буду внедрять такие элементы управления, которые неизвестно будут ли работать в браузере у других людей или не будут.
Львиная доля компьютеров с Windows, а там по умолчанию IE. Отсюда следует, что пока
1. в новом IE не будет поддержка этого
и
2. не умрут старые версии IE (6, например) или для них не выйдут обязательные патчи
то не будут и использовать эту фичу…
Кроме того, давайте посмотрим со стороны дизайнера:
каждый браузер будет по-разному показывать это — даже сейчас в одном и том же браузере на разных системах это выглядит по-разному (я про Оперу).
дизайнеры будут всегда настаивать на применении единой схемы оформления вне зависимости от браузера…
Мне нравится jquery, поэтому я использую jquery ui. Есть еще много аналогичных средств для оформления элементов управления, написанных с применением protoype, mootools и др js-фреймворков.
Вообщем, получается, что и исходя из соображений дизайнера «всё везде одинаково», и исходя из соображений разработчика «всё везде работает», самым логичным является применение js-элементов управления.
Кстати, их сравнение было бы интересной темой…
Львиная доля компьютеров с Windows, а там по умолчанию IE. Отсюда следует, что пока
1. в новом IE не будет поддержка этого
и
2. не умрут старые версии IE (6, например) или для них не выйдут обязательные патчи
то не будут и использовать эту фичу…
Кроме того, давайте посмотрим со стороны дизайнера:
каждый браузер будет по-разному показывать это — даже сейчас в одном и том же браузере на разных системах это выглядит по-разному (я про Оперу).
дизайнеры будут всегда настаивать на применении единой схемы оформления вне зависимости от браузера…
Мне нравится jquery, поэтому я использую jquery ui. Есть еще много аналогичных средств для оформления элементов управления, написанных с применением protoype, mootools и др js-фреймворков.
Вообщем, получается, что и исходя из соображений дизайнера «всё везде одинаково», и исходя из соображений разработчика «всё везде работает», самым логичным является применение js-элементов управления.
Кстати, их сравнение было бы интересной темой…
> включая обязательный патч для всех уже вышедших IE, начиная с IE6
это как, под угрозой расстрела? :)
«обязательным патчем» для IE6 является IE8, толку, как видно из статистики, пока что не особо много.
это как, под угрозой расстрела? :)
«обязательным патчем» для IE6 является IE8, толку, как видно из статистики, пока что не особо много.
Вообщето, топик о том, что вы можете некоторые из них внедрять уже сейчас, это не доставит вам хлопот, будет удобно на браузерах, где поддерживается и никак не отразиться на тех, что не поддерживаются.
Это конечно хорошо, но всё упирается в IE. Ну потратят разработчики WebKit и Gecko время и деньги на внедрение, ну и что? Всё равно default-браузер не поддерживает. А веб-разработчики не станут тратить время и деньги на создание двух решений: под IE и под остальные.
Вообщето, топик о том, что вы можете некоторые из них внедрять уже сейчас, это не доставит вам хлопот, будет удобно на браузерах, где поддерживается и никак не отразиться на тех, что не поддерживаются.
В самом деле не доставит хлопот? Хотите сказать, что допустим поставив range не нужно делать дополнительные телодвижения для не-Opera?
Люблю себя цитировать :)
…все эти контролы созданы лишь для облегчения ввода строк… …любой из этих контролов можно использовать уже сейчас не дожидаясь поддержки всеми браузерами, в особенности url, email и search…
нет, поставив и настроив input:text для всех браузеров, не будет серьезным телодвижением заменить у него type на range для оперы и будущих версий других браузеров
Chromium (Chrome Plus) 4.0.206.0
А что делает крестик в WebKit y search? Стирает введенный текст?
Господи, внемли мольбам проектировщиков интерфейсов! Сделай так, чтобы эти чудесные штуки поддерживались всеми распространёнными браузерами, в том числе и богомерзким.
я бы это дело показал примерно так:
Понравилось, что в поле url опера не просто иконку пририсовала.
Но и внедрила функционал поиска от адресной сроки.
Но и внедрила функционал поиска от адресной сроки.
Ой беда…
Потом ведь дизайнеры начнут придумывать альтернативное оформление к этим контролам, мало им селектов и чекбоксов, и вот тогда всем верстальщикам наступит полный и окончательный…
А вообще сама статья заставила посмеяться — честно, от души, подано кратко и получилось юморно сочетание заголовка и текста
Потом ведь дизайнеры начнут придумывать альтернативное оформление к этим контролам, мало им селектов и чекбоксов, и вот тогда всем верстальщикам наступит полный и окончательный…
А вообще сама статья заставила посмеяться — честно, от души, подано кратко и получилось юморно сочетание заголовка и текста
в chromium последнем билде только слайдер появился. остальные элементы — просто строки ввода
:) Тоже улыбнуло.
Вообще очень интересно, до чего дойдут разработчки html5.
Докучи как вариант, предлагаю инпут для «капчи» :)))
Чтобы ещё такого придумать? Может быть сделать ещё «alternate» инпут в который, прописывать нужные свойства или там table :))) (Почему бы нет, радиокнопки существуют же)
Вообще очень интересно, до чего дойдут разработчки html5.
Докучи как вариант, предлагаю инпут для «капчи» :)))
Чтобы ещё такого придумать? Может быть сделать ещё «alternate» инпут в который, прописывать нужные свойства или там table :))) (Почему бы нет, радиокнопки существуют же)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Контролы форм в html 5