Комментарии 68
просто и смпатично
Очень хорошо
Для type=«password» еще было бы не плохо тип поля менять.
хватаем текст мышкой, перетаскиваем в такое поле и получаем фейл
сабмитим форму в лэйблами вместо значений и получаем мусор вместо данных, который мы уже не сможем отличить от невведённого значения
а в поля с паролем браузер не сможет подставить значение так как оно не пусто
да что там, для других полей автозаполнение тоже не сработает
формально никто не мешает подставить значения с таймаутом в полсекунды (от загрузки документа). В этом случае браузер может автоматически заполнить поля.
и будет что-то вроде:
код не проверил, т.к. это экспромт и лишь идея, да и наверняка это можно реализовать лучше.
и будет что-то вроде:
$(document).load(function(){setTimeout($(".defValue").filter("[value='']").val($(this).attr("title")),500)});
и <input class="defValue" ... title="my default value" />
код не проверил, т.к. это экспромт и лишь идея, да и наверняка это можно реализовать лучше.
WebKit стандартно поддерживает атрибут «placeholder» в полях input. Оперу — не уверен, но вроде тоже.
В общем, я бы цеплялся на этот атрибут, а не на title + не использовал javascript в тех браузерах, где он не нужен.
Ну и да, все новое — хорошо забытое старое: habrahabr.ru/blogs/jquery/74760/
В общем, я бы цеплялся на этот атрибут, а не на title + не использовал javascript в тех браузерах, где он не нужен.
Ну и да, все новое — хорошо забытое старое: habrahabr.ru/blogs/jquery/74760/
мне кажется проще разместить label слоем ниже прозрачного поля ввода и потом просто оперировать его видимостью.
Примерно такая реализация: drupal.ru/node/36081
Примерно такая реализация: drupal.ru/node/36081
Отличная статья, спасибо, давно искал варианты наподобие этого, но никак не мог придумать. Буду теперь использовать.
по поводу «хранилища» — что мешает к инпуту добавить атрибут default_value=«бла-бла-бла»?
и значение по умолчанию лучше не заносить в value — ибо при сабмите геморой будет. как тут уже писали — отдельным слоем его выводить. плюс этот слой спозиционировать как-будто это сам инпут
и значение по умолчанию лучше не заносить в value — ибо при сабмите геморой будет. как тут уже писали — отдельным слоем его выводить. плюс этот слой спозиционировать как-будто это сам инпут
Мой вариант: немного модифицированый jquery.placeholder для нормальной работы с :password.
dl.dropbox.com/u/1506064/jquery.placeholder.js.txt
Пример:
<input type='text' name='login' id='login' placeholder='логин' />
<input type='password' name='password' id='password' placeholder='пароль' />
<script type='text/javascript'>
$(function() {
$('input[placeholder]').placeholder();
});
</script>
dl.dropbox.com/u/1506064/jquery.placeholder.js.txt
Пример:
<input type='text' name='login' id='login' placeholder='логин' />
<input type='password' name='password' id='password' placeholder='пароль' />
<script type='text/javascript'>
$(function() {
$('input[placeholder]').placeholder();
});
</script>
Так как обработкой focus-а занимается код который выполнится только после полной загрузки страницы, то если человек «ткнет» в контрол во время загрузки — текст останется там.
Поэтому совсем правильно было бы присваивать value для инпута в том же скрипте, который навешивает обработчиков для событий.
Поэтому совсем правильно было бы присваивать value для инпута в том же скрипте, который навешивает обработчиков для событий.
Для Mootools есть OverText
«Вэб». FFFUUUUUUU-
Для «хранения» информации можно использовать метод jQuery .data() и привязать к нужному полю необходимую информацию и соответственно выводить в любой момент… Но это всё-таки JS.
Более изящный вариант — наложить поверх инпутов и прочего элемент label с необходимым нам текстом и прикрутить парочку событий для корректной работы(скрывать когда нужно, передавать фокус при клике инпутам...). Данный рецепт есть в книжке Джонаттана Чаффера и Карла Шведберга «Изучаем jQuery 1.3», думаю не стоит изобретать велосипед :)
Более изящный вариант — наложить поверх инпутов и прочего элемент label с необходимым нам текстом и прикрутить парочку событий для корректной работы(скрывать когда нужно, передавать фокус при клике инпутам...). Данный рецепт есть в книжке Джонаттана Чаффера и Карла Шведберга «Изучаем jQuery 1.3», думаю не стоит изобретать велосипед :)
Уважаемые индусы^W разработчики. При реализации плейсхолдеров надо учитывать следующие аспекты: 1) очистка полей перед сабмитом формы 2) хранить флаг, показывающий, что находится в поле — текст плейсхоледра или введенное пользователем значение, чтобы их различать 3) учитывать возможности автозаполнения форм браузерами.
И да, тянуть 100 Кб jQuery ради такой мелочи как-то неблагодарно.
И да, тянуть 100 Кб jQuery ради такой мелочи как-то неблагодарно.
Даже если бы нужно было всё сделать в вашем стиле, я бы сделал так:
Не понимаю, зачем усложнять простые вещи, самим создавать проблему, а потом решать её.
Ну, это чисто моё мнение.
Не понимаю, зачем усложнять простые вещи, самим создавать проблему, а потом решать её.
Ну, это чисто моё мнение.
мне больше интересно почему у этого банального и кривого решения столько плюсов
да вы злой просто!
нет, это я ещё добрый }:-]
Мне все равно, честно говоря злой вы или еще добрый. Мне просто не нравится, когда предлагаешь способ для «убирания текста при нажатии на поле», а ниже идут комментарии про то, что не реализована поддержка паролей, что обработать форму тяжело, что надо писать костыли, что без джикваери это нихрена не работает, что завтрак не готовит и так далее.
Такое ощущение, что публика ждет готового комбайна с огромным количеством кода, который выполнит каждую их прихоть. А тут сразу кидаются на то, что юзабилити/дизайн не тот, чего-то не хватает, «а вы не подумали». Ну так вы и думайте, у вас же есть голова! Я не решаю чужих проблем, которые находятся у вас в головах.
Если вы понимаете суть вещей, то пишите по существу. Плюсы ставят люди, которым нравится идея, а не то, что я спас им жизнь. И им необязательно ее использовать.
Такое ощущение, что публика ждет готового комбайна с огромным количеством кода, который выполнит каждую их прихоть. А тут сразу кидаются на то, что юзабилити/дизайн не тот, чего-то не хватает, «а вы не подумали». Ну так вы и думайте, у вас же есть голова! Я не решаю чужих проблем, которые находятся у вас в головах.
Если вы понимаете суть вещей, то пишите по существу. Плюсы ставят люди, которым нравится идея, а не то, что я спас им жизнь. И им необязательно ее использовать.
публика ждёт _решения_. решение — это ответы на все встающие в таких ситуациях вопросы. это не обязательно прямо код, но уж точно не замалчивание проблем.
Вы мне предлагаете написать дисклеймер с текстом «приведенный пример не решает вопрос сбора данных на серверной стороне»? Я об этом замалчиваю? Нет, это вы просто на этом акцентируете внимание. Это не входит в рамки поднятой темы, точно также, как и вопросы «сложностей». По мере возможности я отвечаю, там где у меня есть экспертиза.
решение — это решение задачи, а не «ответ на все вопросы»
в этом топике автор представил нам свою идею* с примером реализации, а не готовое «сделай мне заебись».
нормальные разработчики могут либо воспринять идею, либо отвергнуть, а «публика» со своими «возникающими вопросами» может выйти на улицу, подышать свежим воздухом,…
извините.
____________________
* — пускай она и боян
в этом топике автор представил нам свою идею* с примером реализации, а не готовое «сделай мне заебись».
нормальные разработчики могут либо воспринять идею, либо отвергнуть, а «публика» со своими «возникающими вопросами» может выйти на улицу, подышать свежим воздухом,…
извините.
____________________
* — пускай она и боян
какая тут нафиг идея? это первое что приходит на ум любому программисту использующему жэкуэри. только те, кто по сообразительнее видят в нём проблемы и ищут другие решения, а некоторые катают статью про это великое изобретение
Я поздравляю вас, вы не такой как все и знаете больше, чем кто-либо, о всем, что здесь говорится. И я также стараюсь не для вас — не для людей, которые всё знают. Выше вас спрашивали о том, как решить задачу, а вы предложили изменить условия задачи. Вас же не просили менять условия задачи, верно?
Предлагаю закрыть полемику с моей полной капитуляцией. Это бессмысленный диалог. Я не фанатик
Предлагаю закрыть полемику с моей полной капитуляцией. Это бессмысленный диалог. Я не фанатик
С месяц назад пытался решить эту проблему, наткнулся на плагин, уже готовый, для jQuery.
Так что если бы вы хотели именно решить проблему, а не тратить время и изобретать велосипеды, вы бы за 2 минуты нашли уже готовое
Так что если бы вы хотели именно решить проблему, а не тратить время и изобретать велосипеды, вы бы за 2 минуты нашли уже готовое
Неужели никто не знает:
/* fix for safari & chrome */
$("input[type='text'], textarea").mouseup(function(e){
e.preventDefault();
});
$("input[type='text'], textarea")
.focus(function(e) {
if($(this).val() == $(this).attr("defaultValue")) $(this).val('');
})
.blur(function(e) {
if($(this).val() == "") $(this).val($(this).attr("defaultValue"));
});
Примеры (я понимаю, что это всего-лишь примеры) форм — отвратительные.
Увидев такую форму, да ещё с курсивным подчёркнутым текстом, имитирующим ссылку, вместо положенной кнопки, не то что заполнять не стал бы — на сайт больше бы не вернулся.
Значения в роли заголовков полей хороши для небольших форм, где они позволяют сэкономить место, не сильно ухудшив юзабилити.
Однако даже на форме, приведённой в пример, такое решение уже не уместно и будет только мешать.
Ещё больше будет мешать всплывающий title.
Подумайте, что будет при отключенном Javascript.
Подумайте, как поведут себя устройства не имеющие over-события в привычном понимании, те же touchscreen-устройства.
> Я показал подход к решению задачи.
Лично я не вижу задачи и её решения.
Вижу попытку усложнения жизни себе и пользователям там, где этого можно не делать.
Увидев такую форму, да ещё с курсивным подчёркнутым текстом, имитирующим ссылку, вместо положенной кнопки, не то что заполнять не стал бы — на сайт больше бы не вернулся.
Значения в роли заголовков полей хороши для небольших форм, где они позволяют сэкономить место, не сильно ухудшив юзабилити.
Однако даже на форме, приведённой в пример, такое решение уже не уместно и будет только мешать.
Ещё больше будет мешать всплывающий title.
Подумайте, что будет при отключенном Javascript.
Подумайте, как поведут себя устройства не имеющие over-события в привычном понимании, те же touchscreen-устройства.
> Я показал подход к решению задачи.
Лично я не вижу задачи и её решения.
Вижу попытку усложнения жизни себе и пользователям там, где этого можно не делать.
Подсказки — это не значения по умолчанию;)
Например вбил в поиск jQuery hints: remysharp.com/2007/01/25/jquery-tutorial-text-box-hints/
Например вбил в поиск jQuery hints: remysharp.com/2007/01/25/jquery-tutorial-text-box-hints/
$() — это конструктор, не нужно его запускать по несколько раз на строчку
Вот ещё одно решение — forum.artof.ru/showthread.php?p=1581
согласен!
Еще один вариант — www.csskarma.com/lab/plugin_slidinglabels/
Решение красивое (хранить значение в title), НО — тултипы это плохо. Потому, что на тачскринах нет тултипов. И реально задалбывает работать на iPad/iPhone/Android-устройствах в приложениях, где много инфы уведено как раз в тултипы.
Вышеупомянутый jquery.example делает то же самое плюс:
+ добавляет класс example на который можно повесить color: gray; — теким образом, то что по дефолту вписано, будет иметь другой цвет.
+ вытирает из формы свои значения в момент субмита. Иначе Вам в форму обратной связи будет постоянно ссыпаться: «сообщение» от «имя фамилия» ответить на «электронную почту».
+ добавляет класс example на который можно повесить color: gray; — теким образом, то что по дефолту вписано, будет иметь другой цвет.
+ вытирает из формы свои значения в момент субмита. Иначе Вам в форму обратной связи будет постоянно ссыпаться: «сообщение» от «имя фамилия» ответить на «электронную почту».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Снова про формы: значения по умолчанию