Каковы рекомендации для тега html <base>?

Я никогда не видел, чтобы <base>HTML-теги использовались ранее. Есть ли подводные камни для его использования, что означает, что я должен избегать этого?

Тот факт, что я никогда не замечал его использования на современном производственном сайте (или на любом другом сайте), заставляет меня опасаться этого, хотя кажется, что у него могут быть полезные приложения для упрощения ссылок на моем сайте.

редактировать

После использования базового тега в течение нескольких недель я обнаружил несколько основных проблем с использованием базового тега, которые делают его гораздо менее желательным, чем он показался на первый взгляд. По сути, изменения в базовом теге href='#topic'и href=''под ним очень несовместимы с их поведением по умолчанию, и это изменение по сравнению с поведением по умолчанию может легко сделать сторонние библиотеки вне вашего контроля очень ненадежными неожиданными способами, так как они будут логически зависеть от поведения по умолчанию. Часто изменения неуловимы и приводят к неочевидным проблемам при работе с большой кодовой базой. С тех пор я создал ответ с подробным описанием проблем, с которыми столкнулся ниже. Так что проверь свои результаты перед тем, как приступить к широкому распространению <base>, - мой новый совет!

Прежде чем решить, использовать <base>тег или нет, вам необходимо понять, как он работает, для чего он может использоваться и каковы его последствия, и, наконец, перевесить преимущества / недостатки.

Этот <base>тег в основном облегчает создание относительных ссылок на языках шаблонов, так как вам не нужно беспокоиться о текущем контексте каждой ссылки.

Вы можете сделать, например,

<base href="${host}/${context}/${language}/">
...
<link rel="stylesheet" href="css/style.css" />
<script src="js/script.js"></script>
...
<a href="home">home</a>
<a href="faq">faq</a>
<a href="contact">contact</a>
...
<img src="img/logo.png" />

вместо

<link rel="stylesheet" href="/${context}/${language}/css/style.css" />
<script src="/${context}/${language}/js/script.js"></script>
...
<a href="/${context}/${language}/home">home</a>
<a href="/${context}/${language}/faq">faq</a>
<a href="/${context}/${language}/contact">contact</a>
...
<img src="/${context}/${language}/img/logo.png" />

Обратите внимание, что <base href>значение заканчивается косой чертой, иначе оно будет интерпретировано относительно последнего пути.

Что касается совместимости браузера, это вызывает только проблемы в IE. <base>Тег в HTML указано , как не имеющие конечный тег </base>, так что это законно , чтобы просто использовать <base>без закрывающего тега. Однако IE6 думает иначе , и все содержимое после в <base>теге в таком случае помещенного в качестве ребенка из <base>элемента в дереве HTML DOM. Это может вызвать на первый взгляд необъяснимые проблемы в Javascript / jQuery / CSS, то есть элементы совершенно недоступны в определенных селекторах, например html>body, до тех пор, пока вы не обнаружите в инспекторе HTML DOM, что между base(и head) должно быть (и ).

Обычное исправление IE6 использует условный комментарий IE для включения конечного тега:

<base href="http://example.com/en/"><!--[if lte IE 6]></base><![endif]-->

Если вас не волнует W3 Validator или вы уже используете HTML5, то вы можете просто закрыть его самостоятельно, так или иначе его поддержит каждый веб-браузер:

<base href="http://example.com/en/" />

Закрытие <base>тега также мгновенно устраняет безумие IE6 в WinXP SP3 для запроса <script>ресурсов с относительным URI в srcбесконечном цикле.

Другая потенциальная проблема IE проявится, когда вы используете относительный URI в <base>теге, например <base href="https://example.com/somefolder/">или <base href="https://stackoverflow.com/somefolder/">. Это не удастся в IE6 / 7/8. Это, однако, не совсем ошибка браузера; использование относительных URI в <base>теге само по себе неправильно. В спецификации HTML4 указано, что это должен быть абсолютный URI, поэтому он начинается со схемы http://or https://. Это было опущено в спецификации HTML5 . Так что, если вы используете только HTML5 и целевые HTML5-совместимые браузеры, то у вас должно быть все в порядке, если использовать относительный URI в <base>теге.

Что касается использования привязок фрагментов именованных / хеш-фрагментов, таких как привязки <a href="#anchor">строк запросов <a href="?foo=bar">и привязок фрагментов пути <a href=";foo=bar">, то с <base>тегом вы в основном объявляете все относительные ссылки, относящиеся к нему, включая такие виды привязок. Ни одна из относительных ссылок больше не относится к текущему URI запроса (как это было бы без <base>тега). Это может в первую очередь сбить с толку для начинающих. Чтобы правильно построить эти якоря, вам нужно включить URI,

<a href="${uri}#anchor">hash fragment</a>
<a href="${uri}?foo=bar">query string</a>
<a href="${uri};foo=bar">path fragment</a>

где в ${uri}основном переводится $_SERVER['REQUEST_URI']в PHP, ${pageContext.request.requestURI}JSP и #{request.requestURI}JSF. Следует отметить, что MVC-фреймворки, такие как JSF, имеют теги, уменьшающие весь этот шаблон и устраняющие необходимость <base>. Смотрите также, какой URL использовать для ссылки / перехода на другие страницы JSF .

Разбивка эффектов базового тега:

Базовый тег имеет некоторые неинтуитивные эффекты, и я рекомендую ознакомиться с результатами и проверить их самостоятельно, прежде чем полагаться на них <base>! Так как я обнаружил их после попытки использовать базовый тег для работы с локальными сайтами с разными URL-адресами и обнаружил проблемные эффекты только после того, как, к моему ужасу, я вынужден создать это резюме этих потенциальных подводных камней для других.

Я буду использовать базовый тег: в <base href="http://www.example.com/other-subdirectory/">качестве моего примера в приведенных ниже случаях и буду делать вид, что страница, на которой находится код, является http://localsite.com/original-subdirectory

Крупный:

Никакие ссылки или именованные якоря или пустые ссылки не будут указывать на исходный подкаталог, если это не указано явно: базовый тег делает все ссылки по-разному, в том числе ссылки на одну и ту же страницу на URL базового тега, например:

• <a href='#top-of-page' title='Some title'>A link to the top of the page via a named anchor</a>
  становится
  <a href='http://www.example.com/other-subdirectory/#top-of-page' title='Some title'>A link to an #named-anchor on the completely different base page</a>

• <a href='?update=1' title='Some title'>A link to this page</a>
  становится
  <a href='http://www.example.com/other-subdirectory/?update=1' title='Some title'>A link to the base tag's page instead</a>

Проделав некоторую работу, вы можете исправить эти проблемы с помощью ссылок, которыми вы управляете, явно указав, что эти ссылки ссылаются на страницу, на которой они находятся, но когда вы добавляете сторонние библиотеки в набор, основанный на стандартном поведении, это может легко вызвать большой беспорядок.

Незначительный:

Исправление IE6, требующее условных комментариев: Требует условных комментариев для ie6, чтобы не испортить иерархию dom, то есть, <base href="http://www.example.com/"><!--[if lte IE 6]></base><![endif]-->как BalusCупоминалось в его ответе выше.

В целом, основная проблема заключается в использовании хитрости, если у вас нет полного контроля над каждой ссылкой, и, как я изначально опасался, это создает больше проблем, чем стоит. Теперь я должен уйти и переписать все мои использования этого! :п

Ссылки по теме тестирования на проблемы при использовании «фрагментов» / хэшей:

http://www.w3.org/People/mimasa/test/base/

http://www.w3.org/People/mimasa/test/base/results

Редактировать Иззи: Для всех вас, сталкивающихся с той же путаницы, что и я в отношении комментариев:

Я только что проверил это сам, со следующими результатами:

• косая черта или нет, не имеет значения для приведенных здесь примеров ( #anchorи ?queryбудет просто добавлена ​​к указанному <BASE>).
• Это, однако, имеет значение для относительных ссылок: пропускает косую черту other.htmlи dir/other.htmlначинается DOCUMENT_ROOTс данного примера, /other-subdirectoryбудучи (правильно) обработанным как файл и, следовательно, опущенным.

Так что для относительных ссылок BASEхорошо работает с перемещенной страницей - в то время как якоря и ?queriesдолжны были бы явно указать имя файла (с BASEконечной косой чертой, или последний элемент, не соответствующий имени файла, в котором он используется).

Думайте об этом как о <BASE>замене полного URL-адреса самого файла (а не каталога, в котором он находится), и вы все поймете правильно. Предполагая, что файл, использованный в этом примере, был other-subdirectory/test.html(после того, как он переместился в новое местоположение), правильная спецификация должна была быть:

<base href="http://www.example.com/other-subdirectory/test.html«>

- и вуаля, всё работает , как ожидалось: #anchor, ?query, other.html, very/other.html, /completely/other.html.

Ну, подожди минутку. Я не думаю, что базовый тег заслуживает этой плохой репутации.

Хорошая особенность базового тега заключается в том, что он позволяет выполнять сложные перезаписи URL с меньшими хлопотами.

Вот пример. Вы решаете переместить http://example.com/product/category/thisproduct на http://example.com/product/thisproduct . Вы изменяете свой файл .htaccess, чтобы перезаписать первый URL-адрес вторым URL-адресом.

Установив базовый тег, вы переписываете .htaccess и все. Нет проблем. Но без базового тега все ваши относительные ссылки будут сломаны.

Перезаписи URL часто необходимы, поскольку их настройка может помочь архитектуре вашего сайта и видимости поисковой системы. Правда, вам понадобятся обходные пути для проблем "#" и "", о которых упоминали люди. Но базовый тег заслуживает места в наборе инструментов.

Чтобы решить, следует ли его использовать или нет, вы должны знать, что он делает и нужно ли это. Это уже частично изложено в этом ответе , которому я также способствовал. Но чтобы было легче понять и следовать, здесь есть второе объяснение. Для начала нам нужно понять:

Как ссылки обрабатываются браузером без <BASE>использования?

Для некоторых примеров, давайте предположим, что у нас есть эти URL:

A) http://www.example.com/index.html
B) http://www.example.com/
C) http://www.example.com/page.html
D)http://www.example.com/subdir/page.html

A + B оба приводят к тому, что тот же файл ( index.html) отправляется в браузер, C, конечно, отправляет page.html, а D отправляет /subdir/page.html.

Предположим далее, что обе страницы содержат набор ссылок:

1) полностью определенные абсолютные ссылки ( http://www...)
2) локальные абсолютные ссылки ( /some/dir/page.html)
3) относительные ссылки, включая имена файлов ( dir/page.html), и
4) относительные ссылки только с «сегментами» ( #anchor, ?foo=bar).

Браузер получает страницу и отображает HTML. Если он находит какой-то URL, ему нужно знать, куда его указать. Это всегда понятно для ссылки 1), которая принимается как есть. Все остальные зависят от URL отображаемой страницы:

URL     | Link | Result
--------+------+--------------------------
A,B,C,D |    2 | http://www.example.com/some/dir/page.html
A,B,C   |    3 | http://www.example.com/dir/page.html
D       |    3 | http://www.example.com/subdir/dir/page.html
A       |    4 | http://www.example.com/index.html#anchor
B       |    4 | http://www.example.com/#anchor
C       |    4 | http://www.example.com/page.html#anchor
D       |    4 | http://www.example.com/subdir/page.html#anchor

Теперь, что меняется с <BASE> использованием?

<BASE>должен заменить URL, как он выглядит в браузере . Таким образом, он отображает все ссылки, как если бы пользователь вызвал URL, указанный в <BASE>. Что объясняет некоторую путаницу в нескольких других ответах:

• опять же, ничего не меняется для "полностью определенных абсолютных ссылок" ("тип 1")
• для локальных абсолютных ссылок целевой сервер может измениться (если указанный в <BASE>отличается от того, который вызывается изначально от пользователя)
• относительные URL-адреса становятся здесь критическими, поэтому вы должны быть особенно внимательны при настройке <BASE>:
  • лучше не устанавливать его в каталог . При этом ссылки типа «3» могут продолжать работать, но это, безусловно, нарушает ссылки типа 4 (за исключением случая В).
  • установка полного имени файла дает, в большинстве случаев, желаемые результаты.

Пример объясняет это лучше всего

Допустим, вы хотите «предварительно« оптимизировать »некоторые URL-адреса с помощью mod_rewrite:

• реальный файл: <DOCUMENT_ROOT>/some/dir/file.php?lang=en
• реальный URL: http://www.example.com/some/dir/file.php?lang=en
• удобный URL: http://www.example.com/en/file

Предположим, mod_rewriteон используется для прозрачного переписывания удобного для пользователя URL-адреса в реальный (без внешнего перенаправления, поэтому «удобный для пользователя» остается в адресной строке браузера, пока загружается реальный). Что делать сейчас?

• не <BASE>указано: ломает все относительные ссылки (как они будут основаны http://www.example.com/en/fileсейчас)
• <BASE HREF='http://www.example.com/some/dir>Абсолютно неправильно. dirбудет считаться файловой частью указанного URL, поэтому все относительные ссылки будут битыми.
• <BASE HREF='http://www.example.com/some/dir/>Уже лучше. Но относительные ссылки типа 4 по-прежнему не работают (за исключением случая B).
• <BASE HREF='http://www.example.com/some/dir/file.php>: Точно. Все должно работать с этим.

Последнее примечание

Имейте в виду, что это относится ко всем URL-адресам в вашем документе:

• <A HREF=
• <IMG SRC=
• <SCRIPT SRC=
• ...

Изначально Drupal полагался на этот <base>тег, а затем принял решение не использовать его из-за проблем с HTTP-сканерами и кешами.

Я вообще не люблю размещать ссылки. Но этим действительно стоит поделиться, так как он может помочь тем, кто ищет подробности реального опыта с <base>тегом:

http://drupal.org/node/13148

Облегчает просмотр страниц в автономном режиме; Вы можете поместить полный URL-адрес в базовый тег, и тогда ваши удаленные ресурсы будут загружены правильно.

Хеш "#" в настоящее время работает для ссылок перехода вместе с базовым элементом, но только в последних версиях Google Chrome и Firefox, а не IE9.

IE9, кажется, заставляет страницу быть перезагруженной, никуда не переходя. Если вы используете переходные ссылки на внешней стороне iframe, при этом направляя фрейм для загрузки переходных ссылок на отдельной странице внутри фрейма, вместо этого вы получите вторую копию страницы переходных ссылок, загруженную внутри фрейма.

Это, вероятно, не очень популярно, потому что это не известно. Я бы не боялся использовать его, так как все основные браузеры поддерживают его.

Если ваш сайт использует AJAX, вы должны убедиться, что все ваши страницы настроены правильно, иначе вы можете получить ссылки, которые не могут быть разрешены.

Только не используйте targetатрибут на странице HTML 4.01 Strict.

В случае изображений SVG, встроенных в страницу, при использовании baseтега возникает еще одна важная проблема :

Поскольку с baseтэгом (как уже отмечалось выше) вы фактически теряете возможность использовать относительные хеш-URL-адреса, как в

<a href="#foo">

потому что они будут сопоставлены с базовым URL, а не с местоположением текущего документа, и, следовательно, больше не будут относительными. Таким образом, вам нужно будет добавить путь к текущему документу к таким ссылкам, как в

<a href="https://stackoverflow.com/path/to/this/page/name.html#foo">

Таким образом, один из, казалось бы, положительных аспектов baseтега (который заключается в удалении длинных префиксов URL-адресов от тега привязки и получении более хороших, более коротких привязок) полностью отрицательно сказывается на локальных URL-адресах хэша.

Это особенно раздражает, когда вы вставляете SVG на вашу страницу, будь то статический SVG или динамически генерируемый SVG, потому что в SVG может быть много таких ссылок, и они все сломаются, как только baseтег будет использован, для большинства, но не для всех пользователей. реализации агента (Chrome по крайней мере все еще работает в этих сценариях на момент написания).

Если вы используете систему шаблонов или другую цепочку инструментов, которая обрабатывает / генерирует ваши страницы, я бы всегда пытался избавиться от baseтега, потому что, на мой взгляд, он приносит больше проблем в таблицу, чем решает.

Кроме того, вы должны помнить, что если вы запускаете свой веб-сервер с нестандартным портом, вам нужно также указать номер порта в base href:

<base href="//localhost:1234" />  // from base url
<base href="../" />  // for one step above

Я никогда не видел смысла в его использовании. Обеспечивает очень небольшое преимущество и может даже усложнить использование.

Если у вас нет сотен или тысяч ссылок, все на один и тот же подкаталог. Тогда это может сэкономить вам несколько байтов пропускной способности.

В качестве запоздалой мысли я, кажется, вспоминаю, что была некоторая проблема с тегом в IE6. Вы можете разместить их в любом месте тела, перенаправляя разные части сайта в разные места. Это было исправлено в IE7, который сломал много сайтов.

также есть сайт, где используется базовый тег, и описанная проблема возникла. (после обновления jquery) смог исправить это, добавив URL-адреса вкладок:

<li><a href="{$smarty.server.REQUEST_URI}#tab_1"></li>

это делает их "местными"

ссылки, которые я использовал:

http://bugs.jqueryui.com/ticket/7822 http://htmlhelp.com/reference/html40/head/base.html http://tjvantoll.com/2013/02/17/using-jquery-ui- вкладки-с основанием тег /

Работая с AngularJS, тег BASE молча сломал $ cookieStore, и мне потребовалось некоторое время, чтобы понять, почему мое приложение больше не может писать куки. Имейте в виду...

Имейте в виду одну вещь:

Если вы разрабатываете веб-страницу для отображения в UIWebView на iOS, то вам нужно использовать тег BASE. Это просто не будет работать иначе. Будь то JavaScript, CSS, изображения - ни одно из них не будет работать с относительными ссылками в UIWebView, если не указан тег BASE.

Я был пойман этим раньше, пока не узнал.

Я нашел способ использовать <base>и привязывать ссылки на основе. Вы можете использовать JavaScript, чтобы ссылки #contactработали так, как они должны. Я использовал его на некоторых страницах параллакса, и он работает для меня.

<base href="http://www.mywebsite.com/templates/"><!--[if lte IE 6]></base><![endif]-->

...content...

<script>
var link='',pathname = window.location.href;
$('a').each(function(){
    link = $(this).attr('href');
    if(link[0]=="#"){
        $(this).attr('href', pathname + link);
    }
});
</script>

Вы должны использовать в конце страницы

Моя рекомендация НЕ использовать этот <base>элемент в управлении путями URL . Почему?

Он просто меняет одну проблему на другую. Без базового элемента вы можете использовать любую понравившуюся вам систему путей для своих относительных путей и ссылок, не опасаясь, что они сломаются. В ту минуту, когда вы устанавливаете базовый элемент на путь, на котором вы «заблокированы», чтобы создать все ваши URL для работы с этим путем, и теперь вам нужно будет изменить ВСЕ пути, чтобы они работали с базовым путем. Плохая идея!

Это означает, что теперь вы должны писать ДОЛГОЕ пути и отслеживать, где каждый путь относительно этой базы. Хуже ..... при использовании <base>элемента, который они рекомендуют, вы используете полный базовый путь для поддержки старых браузеров (" https://www.example.com/ "), так что теперь вы жестко закодировали свой домен в свой страница или сделал все ваши ссылки зависимыми от действительного пути к домену.

С другой стороны, как только вы снова удаляете базовый путь со своего веб-сайта, вы снова можете использовать более короткие относительные пути, которые могут быть полностью определены, использовать абсолютные пути из корня или использовать пути, которые действительно относятся к файл и папка, в которой вы находитесь. Это гораздо более гибкий. И лучше всего фрагменты типа "#hello" работают правильно без каких-либо дополнительных исправлений. Опять же, люди создают проблемы, которых не существует.

Кроме того, приведенный выше аргумент о том, что ваши базовые URL-адреса используются для переноса папок веб-страниц в новые местоположения подпапок, сегодня не имеет большого значения, поскольку большинство современных серверов позволяют быстро настроить любую подпапку в качестве новой корневой папки приложения в любом домене. Определение или «корень» веб-приложения теперь не ограничены ни папками, ни доменами.

Кажется глупым весь этот спор. Поэтому я говорю: оставьте базовый URL-адрес и поддержите более старую систему путей по умолчанию сервер-клиент, которая ее не использует.

Примечание. Если проблема заключается в том, что вы управляете путями из-за какой-то новой системы API, решение простое ... будьте последовательны в том, как вы направляете все свои URL и ссылки в своем API. Не полагайтесь на поддержку браузером базовых или HTML5 или более новых цирковых трюков, как это делают дети из JavaScript. Просто укажите все свои теги привязки, и у вас никогда не возникнет проблем. Более того, ваше веб-приложение мгновенно переносится на новые серверы независимо от используемых систем маршрутизации.

Что старое, то снова новое! Основной элемент явно заключается в попытке найти решение проблемы, которой никогда не было в мире Интернета 20 лет назад, а тем более сегодня.

Пример базы href

Скажите типичную страницу со ссылками:

<a href=home>home</a> <a href=faq>faq</a> <a href=etc>etc</a>

.и ссылки на папку diff:

..<a href=../p2/home>Portal2home</a> <a href=../p2/faq>p2faq</a> <a href=../p2/etc>p2etc</a>..

С помощью base href мы можем избежать повторения базовой папки:

<base href=../p2/>
<a href=home>Portal2-Home</a> <a href=faq>P2FAQ</a> <a href=contact>P2Contact</a>

Так что это выигрыш ... но страницы слишком часто содержат URL для различий баз И текущая сеть поддерживает только один базовый href на страницу , поэтому выигрыш быстро теряется в качестве баз, которые не повторяет база - hrefed, например:

<a href=../p1/home>home</a> <a href=../p1/faq>faq</a> <a href=../p1/etc>etc</a>
<!--.. <../p1/> basepath is repeated -->

<base href=../p2>
<a href=home>Portal2-Home</a> <a href=faq>P2FAQ</a> <a href=contact>P2Contact</a>

( Base target может быть полезен.) Base href бесполезен, так как:

• страница одинаково влажная, так как:
  • база по умолчанию [папка-родитель] ⇌ идеально (за исключением ненужных / редких исключений 𝒞1 и 𝒞2 ).
  • текущая сеть, несколько базовых ссылок не поддерживаются .

связанные с

• сравнение с базой переписывания Apache