Комментарии 77
кастумизация — нет такого слова
Лично для меня смысл совершенно понятен. Спасибо за статью.
если уж и использовать такие слова, то хотябы писать их без ошибок — кастОмизация
Карова доёт харошее малако — тоже не лишено смысла, но ведь вы не будете так писать
не согласен. это ошибка в русском слове. а кастомизация — это больше жаргон. меня тоже немного напрягло, но не настолько чтобы троллить на эту тему.
Вас и многих других следует перевести в рид-онли за флуд. Я поражен: человек написал хорошую, понятную статью, а вы обсуждаете правило написания слова. Отпишите в личку об ошибках, человек исправит. И это будет очень хорошо с вашей стороны, что вы так поступили. Но не в комментах, это не грамота.ру.
Смесь английского с нижегородским, почти по Грибоедову :)
Тогда уж костюмизация — одевание новой шкурки (костюмов) на чекбоксы, радиобатоны.
> кастумизация — нет такого слова
На мой взгляд это вполне прижившая в среде разработчиков «русификация» от англ. customization. Правильный перевод этого термина имеет достаточно большую длину, чтобы использовать его. К тому же итак понятно что имеется ввиду.
На мой взгляд это вполне прижившая в среде разработчиков «русификация» от англ. customization. Правильный перевод этого термина имеет достаточно большую длину, чтобы использовать его. К тому же итак понятно что имеется ввиду.
кастомизация. кастомайзинг. и не только у разработчиков, но везде. Но никак не кастумизация.
«эджекс» — а не «аякс», как как произносят многие российкие разработчики. «майэскюэль», вместо «майсиквел» как произносит один мой знакомый очень уважаемый разработчик с 25 летним стажем. что это меняет то? мне теперь ему на это указывать каждый раз? привычка.
Семантически верный перевод: стилизация. Длина этого слова меньше используемого автором.
(меня тоже дико раздражают всякие кустомизации, коворкинги и краудфандинги)
(меня тоже дико раздражают всякие кустомизации, коворкинги и краудфандинги)
А opacity:0 + спрайт не работает?
Скрытые инпуты работаю в ИЕ?
само свойство hidden к сожалению нет, поэтому в css еще добавлено display: none; для данных типов input.
Тут помимо этого присутствует псевдоэлемент :before, который не работает в IE7.
Для него придется использовать expression, либо добавлять какой-нибудь пустой тег вместо :before.
Ну, и еще IE7 не поддерживает :checked и :disabled, тоже придется писать костыль…
Для него придется использовать expression, либо добавлять какой-нибудь пустой тег вместо :before.
Ну, и еще IE7 не поддерживает :checked и :disabled, тоже придется писать костыль…
НЛО прилетело и опубликовало эту надпись здесь
IE8 тоже не поддерживает :checked, :enabled и :disabled, а статистика говорит, что его доля среди российских юзеров немного больше, чем у IE9
Ок, а как вы текст будете менять в label без JS в зависимости от состояния чекбокса?
А в каком случае его нужно менять? В стандартной реализации текст в лейбле тоже не меняется.
В данном конкретном случае, мне это не нужно. Если вы имеете ввиду чекбоксы в стиле iPhone, то там тоже нет каких-то существенных проблем.
НЛО прилетело и опубликовало эту надпись здесь
Ваш способ прекрасен до того момента, как вы попробуете на ваши инпуты нажать.
Данная реализация не работоспособна. Вот это её убивает:
Данная реализация не работоспособна. Вот это её убивает:
input[type="checkbox"],
input[type="radio"] {
display:none;
}
А что в этом не так? Элементы формы не будут отсылаться при отправке на submit? Если так, то способов как их скрыть кроме display:none множество.
Все работает совершенно корректно. Такие input'ы не только нажимаются, но и без проблем отправляются в формах.
Ещё один минус текущей реализации:
Вы расчитываете на то, что сначала в HTML идёт input, а затем — label. Очень часто — наоборот. Не могли бы показать модификацию для такого случая?
Вы расчитываете на то, что сначала в HTML идёт input, а затем — label. Очень часто — наоборот. Не могли бы показать модификацию для такого случая?
А еще нередко бывает, когда input и label не идут в потоке подряд. Например, находятся в разных ячейках таблицы.
Я рассматриваю конкретный случай, взяв для этого классическую разметку как «по учебнику». Целью было показать идею, одну из многих, которая может для кого-то оказаться удобной. Для каждого случая свои инструменты. В случае если label идет впереди input возможно лучше использовать другой способ.
бессмысленно класть input в какое-то отдельное от label место, если он display: none. проблема высосана из пальца.
Важным моментом является только то, что нужно указывать id для каждого input и for для label, чтобы связать их.
Можно ведь тег input поместить внутри контейнера label и таким образом избавимся от написания
id для каждого input и for для label
Да, для radio и checkbox очень часто используют именно такую конструкцию. Но мне кажется, что в этом случае внедрить подход, который предлагает автор, на чистом CSS будет весьма сложно.
Как-то так: label > input::before
А если я кликну на зону лейбла, где инпут не дотягивается, разве произойдёт ивент?
Что значит «инпут не дотягивается»? Событие вызывается по клику на самом лейбле.
НЛО прилетело и опубликовало эту надпись здесь
Точно, забыл про всплытие.
НЛО прилетело и опубликовало эту надпись здесь
Просто, честно сказать, в первый раз узнал о конструкции инпута внутри лейбла.
НЛО прилетело и опубликовало эту надпись здесь
Мда, в статье про «Простую кастомизация Checkbox и Radio» результат оформлен картинкой :)
Работал с каким-то плагином аналогичного назначения, возникла проблема из bind на разные события. Плагин сделали, кнопки нажимаются, все счастливы, вот только не учли, что помимо картинки оно должно еще и работать.
А сами спрайты, отображающие состояние, кликабельны ведь, да? Я просто не сильно клиентский программист, поэтому интересуюсь. А рабочего примера не выложили, как раз было бы очень кстати, я бы тогда не задавал таких глупых вопросов :)
Супер. Ещё бы чтобы от клавиатуры работало, было бы здорово.
uniformjs.com --> http://opensource.audith.org/uniform/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Простая кастомизация Checkbox и Radio