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

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

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


Изменить

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

Ответ 1

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

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

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

Главный:

Никакие ссылки или именованные якоря или пустые hrefs не укажут на исходный подкаталог, если только это не сделано явным: базовый тег делает все ссылки по-разному, включая ссылки на привязку на одной странице к 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 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


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

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

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

Таким образом, для относительных ссылок 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.

Ответ 2

Прежде чем решить, следует ли использовать тэг <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, что должен быть basehead) между ними.

Общее исправление 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="//example.com/somefolder/"> или <base href="/somefolder/">. Это провалится в IE6/7/8. Это, однако, не совсем ошибка браузера; использование относительных URI в теге <base> происходит именно по своей собственной ошибке. спецификация HTML4 заявила, что она должна быть абсолютным URI, таким образом, начиная с схемы http:// или 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>. См. Также a.o. Какой URL-адрес использовать для связи/перехода на другие страницы JSF.

Ответ 3

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

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

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

С базовым тегом на месте, вы переписываете.htaccess и это. Нет проблем. Но без базового тега все ваши относительные ссылки сломаются.

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

Ответ 4

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

Как используются ссылки, обработанные браузером без <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-адрес, ему нужно знать, куда его указывать. Это всегда понятно для Link 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" (за исключением "case B" ).
    • установить его в полное имя файла, в большинстве случаев дает желаемые результаты.

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

Предположим, что вы хотите "убрать" некоторые URL-адреса, используя mod_rewrite:

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

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

  • no <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=
  • ...

Ответ 5

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

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

http://drupal.org/node/13148

Ответ 6

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

Ответ 7

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

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

Ответ 8

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

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

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

Ответ 9

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

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

<a href="#foo">

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

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

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

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

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

Ответ 10

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

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

Ответ 11

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

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

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

Ответ 12

также есть сайт, на котором используется базовый тег, и описанная проблема. (после обновления 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-tabs-with-the-base-tag/

Ответ 13

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

Ответ 14

Одна вещь, о которой нужно помнить:

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

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

Ответ 15

Я нашел способ использовать ссылки <base> и anchor. Вы можете использовать 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>

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

Ответ 16

Пример базового 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, мы можем избежать repeat в базовую папку:

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

So that a win.. yet pages too-often contain urls to diff bases And the current web supports only one base href per page, so the win is quickly lost as bases that aint base∙hrefed repeats, eg:

<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>


Заключение

(Базовая цель может быть полезна.) База href бесполезна как:

  • страница равно WET, поскольку:
    • база по умолчанию [– родительская папка] & rlhar; (за исключением ненужных/редких исключений & Cscr; 1 и & Cscr; 2).
    • текущий web & rlhar; несколько базовых hrefs неподдерживаемых.

Похожие