Да, это все так. Надо будет написать про всплывающие элементы. У меня они есть в черновике. По поводу автофокуса. Я специально подобрал пример, где он точно не навредит. Как вы сказали, он также может быть проблемой.
Я тоже так подумал, но меня смутили требования к <ident>, описанные в стандарте CSS Syntax Module Level 3. По правилам мы можем использовать символы [a-zA-Z0-9]. Поэтому я в ступоре.
"Код работает не в вакууме. На практике многое в этой статье не работает так, как написано, хотя на первый взгляд может показаться, что все ок."
Да, код работает не в вакууме. Вопросы создаются в вакууме, потому что проверятся/показывается какой-либо аспект-знание. Умение соединять разные аспекты, в частности " Сделайте им размер шрифта побольше", это отдельный навык, который не проверяется вопросами. Я постарался дать примеры кода, который максимально приближенны к практике. Например, свойством inset или margin-inline.
По поводу логических свойств. Посмотрите видео Kevin Powell или статьи Ahmad Shadeed. Они используют их так, как я написал в вопросах. То, что они могут сломать верстку при определении другого направления текста? Так люди либо это знают, либо узнают и примут решение, что с этим делать. Также существуют разработчики, которые делают проекты для микрокомпаний, у которых мультиязычность не востребована. У них ничего не сломается.
Нет единого правильного направления работы. Есть разные кейсы, к которым нужно использовать разные подходы. Статья про расширение кругозора, а не чтобы заваливать вопросами на собеседовании.
Изначально мы задаем 100%, но не больше 1024px. Значение 100% браузерами понимается тоже в px, не смотря на то, что мы используем %. Это можно посмотреть во вкладе Computed в DevTools.
Таким образом, мы говорим: пусть ширина элемента в px будет любой, но не больше 1024px. Например, браузеры рассчитали, что 100% в итоге трансформируется в 1000px. В итоге им нужно выбрать минимальное значение между 1000px и 1024px.
Если нет определенности какой путь указать, то можно не указывать href. Просто оставить:
<a>мой заказ</a>
В таком случае ссылка перестает ей быть и теряет свойства интерактивности, т.е на нее нельзя сфокусироваться, к примеру. Такое бывает в навигации, когда у ссылки убирают href, чтобы обозначить текущую страницу.
Если не известен путь и интерактивность должна присутствовать, то это только button.
Можно:
— использовать supports или отдельную версию для IE 11, но тогда раздувается код
— можно использовать PostCSS плагины, и довольствоваться ограниченными возможностями
Поэтому если есть IE11 или другие браузеры, которые не поддерживают пользовательские свойства, то лучше отложить свое желание для другого проекта
Преимущества пользовательских свойств:
— можно менять значение в медиа-запросах (пример в статье с переключением цвета и текста)
— без костылей работает calc (я помню был баг либо в Less, либо в Sass)
— работают с атрибутами (пример в статье с svg)
— меньше писать кода для состояний hover, focus и т.п
И сравнение пользовательских свойств с Sass переменным некорректно. Они могут спокойно существовать вместе
В чем же я еще не разобрался? С элементом search услышал.
В вашем примере никак. Но в мире полно ситуаций, кроме описанной вами. В них нужно придерживаться правил.
https://habr.com/ru/companies/ruvds/articles/776392/
https://habr.com/ru/companies/ruvds/articles/771082/
Да, это все так. Надо будет написать про всплывающие элементы. У меня они есть в черновике. По поводу автофокуса. Я специально подобрал пример, где он точно не навредит. Как вы сказали, он также может быть проблемой.
Я хотел максимально сохранить оригинальный код и копировал из DevTools. Там
autofocus="autofocus"Вы говорите о контексте. Да, важно уточнять его
Вот так не будет ругаться alt=""
Наверное, так и есть. Получается я отвык от таких хаков
Я тоже так подумал, но меня смутили требования к
<ident>, описанные в стандарте CSS Syntax Module Level 3. По правилам мы можем использовать символы[a-zA-Z0-9]. Поэтому я в ступоре."Код работает не в вакууме. На практике многое в этой статье не работает так, как написано, хотя на первый взгляд может показаться, что все ок."
Да, код работает не в вакууме. Вопросы создаются в вакууме, потому что проверятся/показывается какой-либо аспект-знание. Умение соединять разные аспекты, в частности " Сделайте им размер шрифта побольше", это отдельный навык, который не проверяется вопросами. Я постарался дать примеры кода, который максимально приближенны к практике. Например, свойством inset или margin-inline.
По поводу логических свойств. Посмотрите видео Kevin Powell или статьи Ahmad Shadeed. Они используют их так, как я написал в вопросах. То, что они могут сломать верстку при определении другого направления текста? Так люди либо это знают, либо узнают и примут решение, что с этим делать. Также существуют разработчики, которые делают проекты для микрокомпаний, у которых мультиязычность не востребована. У них ничего не сломается.
Нет единого правильного направления работы. Есть разные кейсы, к которым нужно использовать разные подходы. Статья про расширение кругозора, а не чтобы заваливать вопросами на собеседовании.
Изначально мы задаем 100%, но не больше 1024px. Значение 100% браузерами понимается тоже в px, не смотря на то, что мы используем %. Это можно посмотреть во вкладе Computed в DevTools.
Таким образом, мы говорим: пусть ширина элемента в px будет любой, но не больше 1024px. Например, браузеры рассчитали, что 100% в итоге трансформируется в 1000px. В итоге им нужно выбрать минимальное значение между 1000px и 1024px.
Это поведение является функцией min().
Я не смог подобрать удачный пример. А так, здорово, что вы указали. Спасибо!
Если нет определенности какой путь указать, то можно не указывать href. Просто оставить:
В таком случае ссылка перестает ей быть и теряет свойства интерактивности, т.е на нее нельзя сфокусироваться, к примеру. Такое бывает в навигации, когда у ссылки убирают href, чтобы обозначить текущую страницу.
Если не известен путь и интерактивность должна присутствовать, то это только button.
— использовать supports или отдельную версию для IE 11, но тогда раздувается код
— можно использовать PostCSS плагины, и довольствоваться ограниченными возможностями
Поэтому если есть IE11 или другие браузеры, которые не поддерживают пользовательские свойства, то лучше отложить свое желание для другого проекта
— можно менять значение в медиа-запросах (пример в статье с переключением цвета и текста)
— без костылей работает calc (я помню был баг либо в Less, либо в Sass)
— работают с атрибутами (пример в статье с svg)
— меньше писать кода для состояний hover, focus и т.п
И сравнение пользовательских свойств с Sass переменным некорректно. Они могут спокойно существовать вместе