Комментарии 15
.progress-value:before {
content: attr(value)'%';
}
attr() возвращает значение атрибута.
У меня вкладка с анимированным прогрессбаром отъедает одно ядро процессора. Firefox 40.0.3 на Ubuntu. В хроме 45.0.2454.85 тоже. Что-то я не хотел бы чтобы такие прогрессбары были везде.
Интересно, почему никто не против кастомизировать нативный прогресс, но многие против кастомизации нативного селекта или скроллбара?
Мне кажется, что прогрессбар предоставляет одностороннюю связь с пользователем UI, от только показывает что-то, не предлагая пользователю действий.
С другой стороны, селекты и скроллбары предполагают двустороннюю связь и взаимодействие пользователя с ними, поэтому их интерфейс должен быть как можно более привычным.
С другой стороны, селекты и скроллбары предполагают двустороннюю связь и взаимодействие пользователя с ними, поэтому их интерфейс должен быть как можно более привычным.
Бытовой расизм это. Вот и все.
при написании статьи я так и не нашел ни одной вменяемой песочницы с поддержкой LESS
Не знаю, но у меня проблем с этим никогда не было. Самое лучшее, что видел — jsbin
Не знаю, как автору, но мне кажется этот подход слишком уже огромным. Я всегда делал по старинке.
И
Также, в указанном авторе варианте шаг равен 1%, в моем же варианте минимальный шаг не ограничен.
Прошу у сообщества рассказать мне, в чем же нативный progress-bar лучше, чем метод «по старинке»?
И
element.style.width = 66 + '%' мне кажется не намного труднее, чем element.value = 66Также, в указанном авторе варианте шаг равен 1%, в моем же варианте минимальный шаг не ограничен.
Прошу у сообщества рассказать мне, в чем же нативный progress-bar лучше, чем метод «по старинке»?
По старинке нужно тянуть за собой JS + помимо progress.style.width = cur + '%'; нужно проставлять числовое значение progress.style.innerHTML = cur + '%'; если того требует дизайн, что менее приятно чем один раз поставить value.
К тому же впоследствии поле value удобнее читать, нежели ширину дива.
Если нужно отправить форму, значение value уйдет вместе с формой в отличии от style.width и так далее.
На мой взгляд нативные значения всегда проще читать чем data атрибуты, style.width и прочее.
Я не претендую на то что этот метод однозначно лучше, — просто перечисляю возможные плюсы.
К тому же впоследствии поле value удобнее читать, нежели ширину дива.
Если нужно отправить форму, значение value уйдет вместе с формой в отличии от style.width и так далее.
На мой взгляд нативные значения всегда проще читать чем data атрибуты, style.width и прочее.
Я не претендую на то что этот метод однозначно лучше, — просто перечисляю возможные плюсы.
нужно тянуть за собой JSхм, так у вас же тоже нужно тянуть JS для изменения значения прогресса?
да, с отображением процентов придется повозиться, но, можно же написать функцию, что будет делать это все сразу? Да еще и input:hidden изменять для легкого чтения.
Я нисколько не против нативных решений. Сам использую все, что только можно. Но, как по мне, нативный progress не убирает головную боль, а наоборот — добавляет ее.
Странные у вас какие-то аргументы.
Начнём с того, что прогресс-бар без javascript-обвязки совершенно бесполезен, поскольку для его работы в любом случае понадобится javascript (если только, конечно, нам не нужно отобразить простую статичную полоску, но с этим великолепно справляется и метод «по старинке» без лишнего оверинжинеринга и вообще в этом случае непонятно, зачем тут прогресс-бар?). Так что этот аргумент можно смело отбрасывать.
Для того чтобы можно было «один раз поставить value» достаточно написать простейшую функцию и звать её в случае необходимости. Или заморочиться чуть больше и сделать объект-обвязку
Гм… Скажите, а зачем вам потребовалось отправлять значение прогресс-бара вместе с формой? Прогресс-бар — это штука чисто информативная, пользователь никак не может напрямую изменить его значение, это не поле ввода, зачем его отправлять вместе с формой?
Наконец, шаг в 1% (сколько пикселей в ширину занимает 1% на современных широкоформатных мониторах?) и чрезмерное разбухание кода ну никак нельзя отнести к плюсам данного решения.
В общем, плюсов не увидел.
Начнём с того, что прогресс-бар без javascript-обвязки совершенно бесполезен, поскольку для его работы в любом случае понадобится javascript (если только, конечно, нам не нужно отобразить простую статичную полоску, но с этим великолепно справляется и метод «по старинке» без лишнего оверинжинеринга и вообще в этом случае непонятно, зачем тут прогресс-бар?). Так что этот аргумент можно смело отбрасывать.
Для того чтобы можно было «один раз поставить value» достаточно написать простейшую функцию и звать её в случае необходимости. Или заморочиться чуть больше и сделать объект-обвязку
ProgressBar с методами и свойствами по вкусу.Гм… Скажите, а зачем вам потребовалось отправлять значение прогресс-бара вместе с формой? Прогресс-бар — это штука чисто информативная, пользователь никак не может напрямую изменить его значение, это не поле ввода, зачем его отправлять вместе с формой?
Наконец, шаг в 1% (сколько пикселей в ширину занимает 1% на современных широкоформатных мониторах?) и чрезмерное разбухание кода ну никак нельзя отнести к плюсам данного решения.
В общем, плюсов не увидел.
хм, так у вас же тоже нужно тянуть JS для изменения значения прогресса?
Не совсем. Если рассматривать прогрессбар как отдельный виджет, то для его работы не нужен дополнительный JS код. Проставление значения все же относится к клиентскому коду, не имеющего отношения к «виджету».
Кстати, а ведь в HTML5 есть ещё meter. Кто-нибудь знает зачем W3C дублируют функционал progress?
Из-за семантики www.w3.org/html/wg/drafts/html/master/semantics.html
The meter element represents a scalar measurement within a known range, or a fractional value; for example disk usage, the relevance of a query result, or the fraction of a voting population to have selected a particular candidate.
The meter element should not be used to indicate progress (as in a progress bar). For that role, HTML provides a separate progress element
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кастомизация HTML5 progress element