нормального способа оформлять range через css на данный момент не существует. мало того, что у каждого браузера свои нестандартные и несовместимые селекторы, так ещё и в вебкитах тупо нету отдельного селектора для закрашенной части рельса слева от позунка. народ для этой цели извращается с тенями, но это более или менее сносно работает только в случаях когда ширина ползунка и рельса совпадает. дополнительно осложняется это всё тем, что отдельные части рейнджа - это и так псевдоэлементы, и у них нету никаких ::before и ::after.
сейчас задача сделать такой контрол, как на этой картинке, на чистом цсс - это уровень тестового задания сеньёр веб-технологу. и в прод это выпускать будет страшно, потому что хрупко и при обновлении браузера может сломаться.
Ankhena, вообще-то можно и с ховером. правда разметку придётся изменить слегка.
рекомендовать кому-либо такое в любом случае нельзя, потому что всё завязано на вычисление ширины через calc, что само по себе неверно.
а вот насчёт того, чем правильно такие штуки верстать - это вопрос холиварный на самом деле.
там, где карточки - это основной контент (страница каталога и так далее), наверное правильнее секциями. и тут наверное можно роль секции повесить на текст, а заголовок прописать ему в aria-labeledby.
а если это какие-то дополнительные карточки (что вероятнее, судя по описанию в вопросе "карточки стоят в ряд"), то семантически правильнее их делать в виде списка определений (dl/dt/dd) и там display: contents вообще не нужен.
Ankhena, вы бы почитали что именно там написано, перед тем как громкие заявления делать. у вопрошавшего никаких унаследованных ролей ни на переставляемых дивках нет, ни у контейнера в котором они переставляются, так что никаких коллизий там быть не может.
ну и прямо скажем, пример, который они там приводят, высосан из пальца - никто так не делает. а если и приспичит кому, так он завсегда может роли руками прописать.
почему? в разметке порядок элементов не менялся, читалки продолжают читать карточки по порядку, сначала заголовок, потом текст. во всяком случае микрософтовский narrator точно так делает.
у вас полностью различное поведение в зависимости от типа параметра, причём вы его ещё и в рантайме выбираете. вам наверное проще было бы сделать два разных класса
хорошо компилировать под vliw человечество ещё не научилось. но неэффективный бэкенд для lcc думаю вполне реально прикрутить.
а на какой плиске и плате оно крутится? что там из периферии есть? есть ли эмулятор на писюке?
совсем самопал со своей системой команд (не из заготовок от производителя или опенсорнсных) - это сурово. у меня давно были идеи, с которыми хотелось поэкспериментировать на софткор процессоре, но руки осилить всякие верилоги-вхдлы так и не дошли. вроде появился какой-то чизел, который на скале (её я знаю), но не думаю что им реально пользоваться без глубокого понимания того, что он из этого нагенерит. если есть желание пообсуждать (а может и попробовать чего сделать) - пишите. специально в профиль добавил контакты, потом снесу.
Максим Ленский, как-то сложно там всё. можно же куда проще - нарисовать круг достаточно толстой обводкой (вдвое больше радиуса круга). тогда не придётся считать руками точки на дуге и всё остальное... более того, можно заранее посчитать размеры, чтобы длина окружности равнялась сотне, потом растянуть в цсс, и тогда в рантайме вообще ничего считать не придётся - заполненность будет задаваться сразу в процентах.
о, блин. не доглядел что у RAX7 примерно так и сделано. мне почему-то сначала показалось что он на clip-path делает.
в смысле изменение размера приводит к неработоспособности? разумеется.
редакторы .net IL умеют корректировать смещения ссылок после изменения констант. я сто лет назад пользовался штукой под названием Dile, но наверняка на эту тему появилось куча инструментов новее.
