В HTML ссылки создаются при помощи тега <a>. Текст между открывающим тегом <a> и закрывающим тегом </a> становится «кликабельной» ссылкой.
Слишком громко сказано. У тэга "A" исторически сложилось два назначения
ссылка на "якорь" содержащийся на данной странице или на другую страницу, документ, файл... в таком случае элемент обязательно должен иметь атрибут "href".
собственно "якорь" на который может вести ссылка -- даже имя тэга "A" образовано от слова Anchor -- якорь. В этом случае элемент должен иметь атрибут "id" или "name" (а ссылка на якорь будет иметь вид "#somename").
В HTML5 появилось утверждение, что A-элемент без атрибута "href" выполняет роль "ссылки-заполнителя", но без помощи Javascript такая ссылка бесполезна (её не нажать до присвоения атрибута "href").
А использование A-тэга как "якоря" никуда не девалось. Хотя вместо него можно использовать любой элемент с атрибутом "id".
Значение атрибута href тега <a> должно содержать имя файла веб-страницы на которую делается ссылка...
Не обязательно. Атрибут href может ссылаться на якорь на текущей страницы с помощью атрибута href="#somename".
Вообще непонятно, зачем современный веб-сайт строить из множества дискретных файлов. Любой сложности сайт, веб-приложение, может быть построено из одной страницы, в которую интегрированы все необходимые ресурсы (картинки в base64, отдельные "страницы" как изначально не отображаемые DIV и т.п.) Разделение на дискретные файлы имеет смысл для постепенной загрузки (страница уже есть, а картинки только грузятся, например) в условиях ограниченного по полосе пропускания канала связи в основном. Если сайт большой. Типичный сайт для ардуино (управление чем-либо) прекрасно влезет в одну страницу. А нажатия кнопок в интерфейсе могут транслироваться в XHR-запросы.
Ещё дискретные файлы нужны если предполагается устаревшие варианты html, когда не доступны ни современные CSS-селекторы (они могут организовать "навигацию" по сайту состоящему из единой страницы), ни Javascript.
PS: вообще содержимое единственной страницы сайта лучше закешировать в web storage, чтоб в следующие разы загружалось быстрей. Ну разумеется с чем-то вроде номера версии. Браузер впрочем и сам кеширует, но есть нюансы. И загрузку этой страницы реализовать через маленький начальный загрузчик (который принимает через XHR или script-тэг большой файл и вставляет его в свой DOM), маленкий начальный файл браузер точно закеширует. И добавить web application manifest, тогда можно добиться, что относительно "тяжёлый" сайт запросто будет работать даже в оффлайне. Кнопки через XHR конечно нажиматься перестанут, но остальной функционал полезный для пользователей может и остаться. Так можно построить полнофункциональное веб-приложение для управления электронными приборами или вроде того.
Часто смотрю сериалы на скорости в х1,6 — х2,0 от обычной. Зависит от фильма, медленный с небольшим кол-вом действий и диалогов — можно и быстрее х2,0. Экшены медленнее. После небольшого привыкания — никаких проблем. Все хорошо усваивается, слышно. Красота: серия часовой длительностью за минут 40 без напрягов.
Думаю можно прокачивать свои скиллы «быстродействия».
В общем — ситуацию надо было спасать. Засучив рукава, мы начали с чистого листа искать решение.
Молодцы, что решение всё таки нашли. Но так как статья с меткой «tutorial», то стоит отметить, что в mysql для таких целей уже есть всё необходимое (youlose уже упоминал это). Достаточно добавить в my.cnf несколько строчек:
В файл /var/log/mysql/slow.log будут попадать запросы которые выполняются медленнее 1 секунды, а так же запросы которые не используют индексы. Кроме самих запросов там много сопутствующей информации. В mariaDB или percona информации даже больше будет
Как настроить то, Вы-Понимаете-Нас что.
Слишком громко сказано. У тэга "A" исторически сложилось два назначения
ссылка на "якорь" содержащийся на данной странице или на другую страницу, документ, файл... в таком случае элемент обязательно должен иметь атрибут "href".
собственно "якорь" на который может вести ссылка -- даже имя тэга "A" образовано от слова Anchor -- якорь. В этом случае элемент должен иметь атрибут "id" или "name" (а ссылка на якорь будет иметь вид "#somename").
В HTML5 появилось утверждение, что A-элемент без атрибута "href" выполняет роль "ссылки-заполнителя", но без помощи Javascript такая ссылка бесполезна (её не нажать до присвоения атрибута "href").
А использование A-тэга как "якоря" никуда не девалось. Хотя вместо него можно использовать любой элемент с атрибутом "id".
Не обязательно. Атрибут href может ссылаться на якорь на текущей страницы с помощью атрибута href="#somename".
Вообще непонятно, зачем современный веб-сайт строить из множества дискретных файлов. Любой сложности сайт, веб-приложение, может быть построено из одной страницы, в которую интегрированы все необходимые ресурсы (картинки в base64, отдельные "страницы" как изначально не отображаемые DIV и т.п.) Разделение на дискретные файлы имеет смысл для постепенной загрузки (страница уже есть, а картинки только грузятся, например) в условиях ограниченного по полосе пропускания канала связи в основном. Если сайт большой. Типичный сайт для ардуино (управление чем-либо) прекрасно влезет в одну страницу. А нажатия кнопок в интерфейсе могут транслироваться в XHR-запросы.
Ещё дискретные файлы нужны если предполагается устаревшие варианты html, когда не доступны ни современные CSS-селекторы (они могут организовать "навигацию" по сайту состоящему из единой страницы), ни Javascript.
PS: вообще содержимое единственной страницы сайта лучше закешировать в web storage, чтоб в следующие разы загружалось быстрей. Ну разумеется с чем-то вроде номера версии. Браузер впрочем и сам кеширует, но есть нюансы. И загрузку этой страницы реализовать через маленький начальный загрузчик (который принимает через XHR или script-тэг большой файл и вставляет его в свой DOM), маленкий начальный файл браузер точно закеширует. И добавить web application manifest, тогда можно добиться, что относительно "тяжёлый" сайт запросто будет работать даже в оффлайне. Кнопки через XHR конечно нажиматься перестанут, но остальной функционал полезный для пользователей может и остаться. Так можно построить полнофункциональное веб-приложение для управления электронными приборами или вроде того.
Не волнуйся, скоро популяризируют какой-нибудь TypeThon и будет у питонистов счастье
Можно еще добавить термины "Враг проекта" или "Менеджер вредитель", что конечно не отрицает здоровой и нездоровой конкуренции в любом коллективе.
Думаю можно прокачивать свои скиллы «быстродействия».
В файл /var/log/mysql/slow.log будут попадать запросы которые выполняются медленнее 1 секунды, а так же запросы которые не используют индексы. Кроме самих запросов там много сопутствующей информации. В mariaDB или percona информации даже больше будет
Знаете, более эффективной и честной рекламы ПО, чем ваша, я, пожалуй, и не видел.
Ну, и на правах надоевшей шутки:
А вы отправили авторам список ошибок? А проверили PVS Studio c помощью PVS Studio?