«security by obscurity» это ведь просто дополнительная мера. Во многих случаях, при относительно небольших усилиях можно уменьшить вероятность взлома в разы.
Простой пример, проекты с закрытым исходном кодом намного трудней взломать.
Но они используют одинаковый подход к рендерингу веб-страниц, а бОльшая часть кода внутри проекта остаётся такой же.
Blink ответвился от Webkit в 2013 г. Конечно, они вероятно копируют друг у друга фичи, но за с 7 лет параллельной разработки, я думаю, всё-таки бОльшая часть кода у них теперь должна отличаться.
И ещё проблемы с семантикой и доступностью разметки.
Табы и переключатели на спанах. В SVG иконках неправильные `aria-*` аттрибуты. Фокус на кнопках никак не отображается.
Суть в том, что можно вообще не монтировать файловые системы, а использовать синхронизацию через FTP/SFTP. В этом случае и IDE и приложение работают в своих «родных» файловых системах, и соответсвенно издержки производительности равны нулю. При этом не важно, где именно запущено приложение. Это может быть WSL с Докером или без, Virtual Box, удалённый Линукс сервер в облаке и т.д. Синхронизация может происходить автоматически при сохранении локального файла. В случае локальной сети, деплой изменённого файла занимает 20 — 100 мс. Этого достаточно, чтобы приложение обновилось пока вы переключаетесь между окном IDE и браузера. Единственное не удобство это первоначальный деплой большого проекта. Загружать тысячи файлов через SFTP это долго. Поэтому, лучше файлы проекта выкачать прямо на удалённом сервере, например через Гит.
Помимо проблем с Windows, есть много других поводов использовать удалённый серевер для локальной разработки. Например, «тяжелые» проекты, которым требуется несколько сотен ГБ на локальном диске, или проекты со сложной инфраструктурой. Вместо того, чтобы объяснять верстальщику как поднять проект в Docker на WSL, можно просто дать ему SSH доступ к удалённому dev серверу. По сути локальная машина превращается в тонкий клиент. Все что нужно иметь в ней это браузер, терминал, IDE и Гит. Даже PHP не нужен. Все инструменты типа Composer и npm запускаются на удалённой машине. Xdebug настраивается примерно так же как описано в этой статье.
Когда в линуксовом терминале набираешь explorer.exe создаётся ощущение что этот мир где то свернул не туда. Линукс запущенный через WSL, это не тот Линукс к которому вы могли привыкнуть. Например, в нём нет systemd и Docker нужно ставить через десктопное Windows приложение. У WSL есть только два приемущества по сравнению с Virtual Box / VMware, экономия памяти и быстрый запуск. Если для вас это не критично, то намного проще и удобней использовать виртульные машины.
правила/рекомендации в данном контексте, это ерунда
title на картинке абсолютно безполезнен для людей. Трудно придумать случай когда он может быть нужен. В большинстве случаев это будет просто лишняя раздражающая всплывашка, сообщающая что собака на картинке это собака. Для качественного описания картинки лучше использовать figcaption. Если интерфейс или контент вашего сайта требует наличие аттрибута title, то им будет трудно пользоваться пользователям тачкскринов, которых сейчас большинство…
Проблема в том, что для разработчиков, особенно работающих с СЕО, авторитет у Яндекса выше чем у авторов HTML спецификаций. Поэтому, они ведутся на такую вот ерунду.
Для каждой картинки стоит указать уникальный title. Оставлять атрибут title пустым нежелательно.
Ну и вордпресс конечно, конечно тут в отличился.
WordPress по умолчанию устанавливает название файла в поле «Заголовок», которое соответствует атрибуту title, а поле «Атрибут alt» оставляет пустым.
Зачем такие сложности? Имена файлов для людей которые управляют этими файлами. alt аттрибут для пользователей сайта.
см. выше коментарий про транслит и скринридеры. Так же нужно учесть что имена файлов должны быть уникальными в пределах директории.
Understanding something — типичный заголовок обучающей статьи на английском языке. Не стоит переводить его дословно, потому что на русском это звучит очень неестественно. Лучше придумать новый заголовок для статьи исходя из её содержимого. Например, «Разбираемся с JIT в PHP 8».
Особенно когда пользователь заходит на сайт с древнего ноутбука или телефона, с 5% зарядки и медленным интернет соединением.
Простой пример, проекты с закрытым исходном кодом намного трудней взломать.
Табы и переключатели на спанах. В SVG иконках неправильные `aria-*` аттрибуты. Фокус на кнопках никак не отображается.
10000000 => 10_000_000
www.jetbrains.com/help/phpstorm/deployment-in-PhpStorm.html
Суть в том, что можно вообще не монтировать файловые системы, а использовать синхронизацию через FTP/SFTP. В этом случае и IDE и приложение работают в своих «родных» файловых системах, и соответсвенно издержки производительности равны нулю. При этом не важно, где именно запущено приложение. Это может быть WSL с Докером или без, Virtual Box, удалённый Линукс сервер в облаке и т.д. Синхронизация может происходить автоматически при сохранении локального файла. В случае локальной сети, деплой изменённого файла занимает 20 — 100 мс. Этого достаточно, чтобы приложение обновилось пока вы переключаетесь между окном IDE и браузера. Единственное не удобство это первоначальный деплой большого проекта. Загружать тысячи файлов через SFTP это долго. Поэтому, лучше файлы проекта выкачать прямо на удалённом сервере, например через Гит.
Помимо проблем с Windows, есть много других поводов использовать удалённый серевер для локальной разработки. Например, «тяжелые» проекты, которым требуется несколько сотен ГБ на локальном диске, или проекты со сложной инфраструктурой. Вместо того, чтобы объяснять верстальщику как поднять проект в Docker на WSL, можно просто дать ему SSH доступ к удалённому dev серверу. По сути локальная машина превращается в тонкий клиент. Все что нужно иметь в ней это браузер, терминал, IDE и Гит. Даже PHP не нужен. Все инструменты типа Composer и npm запускаются на удалённой машине. Xdebug настраивается примерно так же как описано в этой статье.
explorer.exeсоздаётся ощущение что этот мир где то свернул не туда. Линукс запущенный через WSL, это не тот Линукс к которому вы могли привыкнуть. Например, в нём нет systemd и Docker нужно ставить через десктопное Windows приложение. У WSL есть только два приемущества по сравнению с Virtual Box / VMware, экономия памяти и быстрый запуск. Если для вас это не критично, то намного проще и удобней использовать виртульные машины.media("within", "md")иmedia("within", "lg")сработают при ширине экрана 768px?titleна картинке абсолютно безполезнен для людей. Трудно придумать случай когда он может быть нужен. В большинстве случаев это будет просто лишняя раздражающая всплывашка, сообщающая что собака на картинке это собака. Для качественного описания картинки лучше использоватьfigcaption. Если интерфейс или контент вашего сайта требует наличие аттрибутаtitle, то им будет трудно пользоваться пользователям тачкскринов, которых сейчас большинство…Ну прочие accessibility concerns
Нет.
Ну и вордпресс конечно, конечно тут в отличился.
см. выше коментарий про транслит и скринридеры. Так же нужно учесть что имена файлов должны быть уникальными в пределах директории.
В вашем примере название файла написано транслитом, которые не поддерживается в скинридерах (как минимум в NVDA).
git merge -caniuse.com/#feat=css-display-contents