Ankhena, оно и не надо. Просто "не стоит плодить сущности без нужды". И я имел в виду не "правила по разным селекторам", а "переопределение этих правил по разным селекторам". Причём и переопределять - вполне нормальное явление (с медиа-запросами только так и происходит обычно). Просто не стоит на основе такого подхода городить систему.
godsplane, всё правильно вам Ankhena написала. Вы css-правила для одного элемента раскидываете по разным селекторам - это нерациональный подход.
Давайте я вам объясню, как человек постоянно переписывающий чужой код. Допустим, мне надо изменить стиль какого-то элемента. Первым делом я открываю веб-инспектор и смотрю какие правила применяются к этому элементу. Каким-либо образом меняю их... Оп, а правила не применились (или применились частично). Потому что начинает работать "каскад" и он тянет что-то из reset.css, normalize.css, bootstrap.css и т.п. И мне уже надо зарываться глубже по каскаду...
А когда селектор один - всё просто и наглядно.
Сбрасывайте только то, что вам действительно надо. На конкретном примере: я сброс стилей пишу самостоятельно - поля и отступы понятно. А вот ссылки, например. Стоит ли всем проставлять подчеркивание? А при ховере? А ещё есть :visited... Всё зависит от конкретного дизайна. И универсальные селекторы должны использоваться именно тогда, когда надо именно всем элементам проставить какие-то правила. А не проставить вначале, а потом каждому конкретному точечно переопределять.
Я просил конкретных примеров, а не вот этой пафосной абстракции. На больших проектах что - киш-миш с организацией кода? Тогда дело вовсе не в типизации.
Ну как бы да. Причём здесь JS, если у вас php ответ генерирует. С ajax.php и разбирайтесь.
Если нет доступа к серверу, то тогда манипуляции со строкой вам в помощь (вплоть до регулярок).
U235U235, это при условии что ожидаемая оценка не вычисляется на основе более широкой или узкой выборки (что угодно - половозрастная группа, время суток и т.п.). Условно: 70% проголосовавших - мужчины, а ожидаемая оценка рассчитывается для равновероятностых ситуаций.
Или вот совсем конкретный пример с "обратной связью" - непроголосовавшие видят текущую среднюю оценку (практически любой рейтинг в интернетах) -> и чем она точнее (больше проголосовало), тем шире диапазон ожидания (чтобы оказать влияние на среднее, пользователь склонен ставить пограничные значения).
Мне сдаётся что тут вся соль в том, что ожидание оценки зависит от того, какова средняя оценка на данный момент. Т.е. тут должна присутствовать "обратная связь" или рекурсия.
Об этом много информации в сети, можно почитать при желании. Полезно.
Я-то как раз в курсе. Мне интересно ваше обоснование))
Потому что ID атрибуты предназначены совсем для другого
Для чего?
Идентификаторов в CSS разве нет? Или, например, они не учитываются при расчёте специфичности селекторов? Да, есть какие-то общепринятые практики, но рубить с плеча "следует отказаться от стилизации элементов по ID селектору" - порождает дальнейшее непонимание того как работает каскад, специфичность и т.п.
По visibility - как по мне, это просто "огрызок" opacity. Opacity позволяет всё то, что умеет visibility и много чего ещё в придачу. Надо отключить срабатывание событий на элементе - pointer-events (опосредованно можно и через z-index) в помощь (а это далеко не всегда надо), не надо - оставляем так. Visibility может принимать только дискретные "показать/скрыть", а opacity можно менять в любых пределах, легко комбинировать с анимациями. Более того, существуют различные хаки, которые с помощью пограничных значений opacity (0.01, 0.99) помогут навести порядок с отображением (например "перебить" z-index),
В общем я не вижу ни одного аргумента за visibility, кроме экономии строчки кода, когда надо отключить срабатывание событий на скрытом элементе))
mark1505, нет.
зачем вы уже второй раз спорите насчёт этого момента, если сами обращаетесь с подобным вопросом и даже не проверили?))
translate - вырывает элемент из потока. он и так будет поверх всех остальных элементов.
вот я вам проиллюстрировал: https://codepen.io/nanto-work/pen/gOeKYXd
Нет, кулеры видеокарты включаются бесшумно.
Ну и видеокарта не даст лага в пару секунд при обращении к жёсткому диску.
Самое забавное, конечно, что я уже второй день, обмазавшись утилитами, пытаюсь выяснить в чём дело, но по закону Мерфи всё вдруг стало работать в штатном режиме.
Дмитрий, 65W - это "горячий"??
Красный центр однозначно всё обновил до чего дотянулся, я не глядя тыкнул на установку всего барахла под кодовым названием Radeon adrenaline (или что-то в этом духе) - я потом долго вычищал, пришлось даунгрейдиться, всё сносить, ставить по новой - и так пару раз. Но проблема осталась.
Оверклокинг мне сейчас совершенно без нужды - пускай по дефолту работает.
С охлаждением всё норм - там башня здоровая на процессоре, три 120мм вертушки на вдув, одна на выдув. И серьёзных нагрузок у системы практически нет.
Сата подключал по "мамкиному" мануалу, так что там тоже проблем не должно быть.
Ну и к тому же проблема возникла не сразу, и не спонтанно.
Может систему проще переустановить?
Да, на жёсткий тоже думал. Но вот какой момент, например десктопный Телеграм триггерит это "просыпание" - а он никак на HDD не завязан, все его каталоги на SSD находятся. Хотя может и просто так чекает файловую систему...
rPman, софт давным-давно есть. ГуглКамера поддерживает RAW. API дефолтной андроидной камеры поддерживает RAW. Два моих последних смартфона прекрасно умеют по дефолту(!) снимать в DNG. Предпоследний был старенький Хонор 9. Сейчас не менее старенький Samsung S8 - дефолтная камера с очень неудобным управлением (UI), но настроить позволяет практически всё - от ручного фокуса до точки экспозамера.
Меня (как, в своё время, очень сильно увлекавшегося фото - пленочным и цифровым) камера любого(!) смартфона не устраивает по ряду очень критичных моментов. Но смартфоны рвут в клочья любой девайс в истории по параметру "всегда под рукой". Так что фотофакты теперь без проблем можно фиксировать. Даже вполне художественные вещи.
Но вот лично мне банально угол основной камеры в S8 слишком велик. Мне очень неудобно компоновать на таком фокусном. Смартфоны (с "основным" шириком и "не урезанным" телевиком) - закроют 90% "фотопотребностей" не слишком искушенного в этой теме пользователя
https://developer.mozilla.org/ru/docs/Web/JavaScri...