Які рекомендації щодо тегу html <base>?


462

Я ніколи раніше не бачив <base>тегів HTML, які фактично використовувались. Чи є підводні камені його використання, це означає, що я повинен уникати цього?

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


Редагувати

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


12
Він часто використовується в кешованих версіях результатів пошукових систем, щоб підтримувати посилання.
Gumbo

11
Просто зауважте: базовий тег також взаємодіє з простими якорями, тому якщо ви використовуєте базу, те, що раніше було лише прив’язкою до місця на сторінці, <a href='#anchor1'>Anchor1</a>буде використовувати і базовий тег, що переосмислює поведінку за замовчуванням щодо посилання на поточну сторінку як основа. Тож на це, безумовно, варто дивитися (хоча це можна виправити, використовуючи інший базовий тег на сторінках, які використовують багато якорів).
Kzqai

1
Якщо ви не задоволені прийнятою відповіддю, чому б вам не прийняти її та не призначити її знову?
Попс

1
Не знав, що це варіант, але так, не хочу відштовхуватися (якщо це навіть дає мені бали), але я думаю, що в остаточному аналізі недоліки переважують переваги, і хочу виділити це.
Kzqai

2
Зазвичай ви не переглядаєте вихідний код кожного головного веб-сайту, на який ви переходите. Я вважаю, що більше людей використовують, <base>ніж ви могли подумати.
Mathias Lykkegaard Lorenzen

Відповіді:


259

Перш ніж вирішити, використовувати <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 або коли ви вже користуєтеся HTML5, то можете просто закрити його, кожен веб-браузер підтримує його все одно:

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

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

Інша потенційна проблема IE виявиться, коли ви використовуєте відносний URI в <base>тезі, наприклад, <base href="https://stackoverflow.com//example.com/somefolder/">або <base href="https://stackoverflow.com/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>. Дивіться також ао Яку URL-адресу використовувати для посилання / навігації на інші сторінки JSF .


BalusC, Приблизно в той же час , коли я писав відповідь тут stackoverflow.com/a/46539210/632951 були більш 10+ корисні коментарів на цю тему , що публікується кілька авторів в протягом 8 років , що деталізують інформацію про <бази>. Будь-яка ідея, до якої посилаються коментарі, була переміщена?
Pacerier

162

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

Здається, базовий тег має деякі неінтуїтивні ефекти, і я рекомендую ознайомитись з результатами та перевірити їх на собі, перш ніж покластися <base>! Так як я виявив їх після того, як намагався використовувати базовий тег для обробки локальних ділянок з різними адресами і тільки з'ясували проблемні наслідки після, на мій жах, я змушений створювати цю зведення цих потенційних пасток для інших.

Я буду використовувати базовий тег: <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's page instead</a>

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

Незначні:

Виправлення IE6, що вимагає умовних коментарів: Потрібні умовні коментарі для ie6, щоб уникнути викручування ієрархії дому, тобто <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.


27

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

Приємна річ про базовий тег - це те, що він дозволяє робити складні переписування URL-адрес з меншими клопотами.

Ось приклад. Ви вирішили перейти http://example.com/product/category/thisproduct на http://example.com/product/thisproduct . Ви змінюєте .htaccess-файл, щоб переписати першу URL-адресу на другу.

З базовим тегом на місці, ви робите перезапис .htaccess і все. Нема проблем. Але без базового тегу всі ваші відносні зв’язки будуть розірвані.

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


10
На мій погляд, проблема полягає в тому, що це підтверджує майбутнє. Якщо ви використовуєте базовий тег на сторінці, на всі інші бібліотеки, які взаємодіють зі сторінкою, впливатиме базовий тег, включаючи сторонні бібліотеки, які можуть покладатися на поведінку за темою гострого якоря або хешів за замовчуванням.
Kzqai

4
@Kzqai, +1 Добре, але є багато веб-сайтів, які не використовують недосконалі бібліотеки. Проблема не в базовому href, а в бібліотеці, і це потрібно виправити там.
Pacerier

2
@Pacerier, я б сказав, що проблема справді полягає в базовому href. А точніше, проблема полягає в тому, що браузери не здаються достатньо розумними, щоб просто не впливати на href, які починаються з #. Я спробував це виправити за допомогою JavaScript, і це спричинило проблеми з бібліотеками, що використовують href='#'посилання (наприклад, завантажувальна програма). Звинувачуючи бібліотеки, це як звинувачувати їх у всьому іншому, що не вдається з HTML. Це застарілий інструмент для сучасної роботи, простий як.
Deji

2
"робити складні переписування URL-адрес із меншими клопотами." - Хоча, у цьому випадку baseтег, ймовірно, є вирішенням того, що в першу чергу немає (правильно) використаних кореневих URL-адрес (або навіть абсолютних URL-адрес).
MrWhite

@Deji, Коли я писав "проблема", я маю на увазі "помилка". Так, саме існування базового href - це справді "проблема", але у наведеному вище випадку я кажу, що помилка не з базовим href. (Проте не думайте жодного разу, що я підтримую використання базового href. Дійсно, моя позиція полягає в тому, що базовий href в його поточній версії марний : stackoverflow.com/a/46539210/632951 . Найкращий шлях вперед - це знецінити його або включити кілька базові hrefs, оскільки це корисно лише тоді, коли можна використовувати декілька)
Pacerier

22

Щоб вирішити, чи слід його використовувати чи ні, ви повинні знати про те, що він робить і чи потрібно. Це частково окреслено у цій відповіді , до якої я також сприяв. Але щоб було легше зрозуміти та слідувати, тут друге пояснення. Спочатку нам потрібно зрозуміти:

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

Для деяких прикладів припустимо, що у нас є такі URL-адреси:

А) http://www.example.com/index.html
В ) В http://www.example.com/
) http://www.example.com/page.html
Г)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" (крім "випадку B")
    • встановити його на повністю кваліфіковане ім’я файлу , у більшості випадків дає бажані результати.

Приклад пояснює це найкраще

Скажіть, що ви хочете "вподобати" деяку 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=

посилаючись на вашу останню примітку ... мені цікаво .. чи це також змінює спосіб інтерпретації запиту jQuery ajax. Це інакше, ніж<SCRIPT SRC=
bkwdesign

@bkwdesign Я не використовую jQuery, але я вважаю, що так.
Іззі

@Izzy, Re "приклад" Насправді , якщо ви вподобали </some/dir/file.php?lang=en> до </en / file>, вам також захочеться вподобати </ some / dir / page2? Lang = en> та </ some / dir / script> to </ en / page2> та </ en / script>. Таким чином, ваші відносні шляхи працюватимуть так само, як і слід .
Печер'є

як би <BASE HREF='http://www.example.com/some/dir/file.php>працювати з "тип 4"? хіба це не так, як " example.com/some/dir/file.php?foo=bar " замість example.com/subdir/page.html?foo=bar
ANewGuyInTown

@ANewGuyInTown Так, і саме це має бути - як у моєму прикладі http://www.example.com/some/dir/file.php"справжнє місцезнаходження" (див. "Приклад пояснює це найкраще"), і передача лише фрагмента ( #anchor) може бути вирішена лише там.
Іззі

12

Drupal спочатку покладався на <base>тег, а згодом прийняв рішення не використовувати через проблеми із сканерами та кешами HTTP.

Я взагалі не люблю публікувати посилання. Але це дійсно варто поділитися, оскільки це може принести користь тим, хто шукає подробиці реального досвіду з <base>тегом:

http://drupal.org/node/13148


Посилання вказує на дискусію, яка мала вісім років до цієї відповіді, так що майже десять років тому. Я думаю, що слід зробити трохи більше тестування, якщо це все-таки є проблемою, а не посилатися на такий віковий опис проблеми, який може не існувати.
Самі Кухмонен

Правда, але IMHO все ще відкриває очі на те, які проблеми потрібно перевірити на <base>базі вашої реалізації, а не лише про те, що ваші якіри працюють прямо у вашому браузері.
Amr Mostafa

@AmrMostafa, просто не використовуй базовий href.
Печер'є

10

Це полегшує сторінки для перегляду в режимі офлайн; ви можете помістити повністю кваліфіковану URL-адресу в базовий тег, і тоді ваші віддалені ресурси завантажуватимуться належним чином.


@Erik, окрім перегляду в режимі офлайн, він також працює для всіх випадкових випадків використання, які потребують демонстрації сторінки домену в іншому домені. Наприклад, демонструючи сторінку на jsfiddle, ви можете використовувати base href для базування вашого домену замість домену jsfiddle. Хоча реалістично кажучи, створення тегів саме для таких випадків використання зупинки не є хорошим дизайном, тому базовий href повинен бути застарілим і видалений навіть тоді, коли він може бути корисним для таких випадків використання зупинки.
Печер'є

5

В даний час хеш "#" працює для перехідних посилань спільно з базовим елементом, але лише в останніх версіях Google Chrome і Firefox, а не IE9.

Здається, що IE9 спричиняє перезавантаження сторінки, нікуди не стрибаючи. Якщо ви використовуєте посилання стрибків на зовнішній стороні рамки, під час керування кадром завантажувати перехідні посилання на окрему сторінку всередині кадру, замість цього ви отримаєте другу копію сторінки перехідної сторінки, завантаженої всередині кадру.


5

Це, мабуть, не дуже популярно, тому що це недостатньо відомо. Я б не побоявся його використовувати, оскільки його підтримують усі основні браузери.

Якщо ваш сайт використовує AJAX, ви хочете переконатися, що всі ваші сторінки налаштовані правильно, або ви можете отримати посилання, які неможливо вирішити.

Просто не використовуйте targetатрибут на сторінці строгої HTML 4.01.


Насправді базовий ціль може бути корисним, але basehref не так. Дійсно, він не популярний, тому що він корисний . Дивіться мої анс.
Печер'є

Тепер усі браузери підтримують baseтег.
Віталій Зданевич

3

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

Оскільки за допомогою baseтегу (як уже зазначалося вище) ви фактично втрачаєте можливість використовувати відносні хеш-адреси, наприклад, у

<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тегу, тому що, як я це бачу, він приносить більше проблем, ніж вирішує.


З або без SVG базовий тег марний і вважається шкідливим . Дивіться мої розробки: stackoverflow.com/a/46539210/632951
Pacerier

3

Крім того, слід пам’ятати, що якщо ви запускаєте веб-сервер на нестандартному порту, вам потрібно також вказати номер порту в базовому href:

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

2

Я ніколи не бачив сенсу в його використанні. Забезпечує дуже малу перевагу, і навіть може ускладнити використання.

Якщо у вас не трапляються сотні чи тисячі посилань, все до одного підкаталога. Тоді це може заощадити кілька байт пропускної здатності.

Здається, я пам'ятаю, що в IE6 була якась проблема з тегом. Ви можете розмістити їх у будь-якому місці тіла, перенаправляючи різні частини сайту в різні місця. Це було зафіксовано в IE7, який зламав багато сайтів.


3
Перевага, ймовірно, полягає не в збереженні пропускної здатності, а в більш чистих і коротших URL-адресах. На жаль, витончених змін у поведінці до всіх посилань насправді не варто, як виявляється.
Kzqai

1
baseТег є рішенням деяких проблем. Якщо у вас немає проблеми, не використовуйте baseтег. Приклади: 1. Повторне використання вмісту HTML у різних системах. Посилання зберігаються відносно за змістом і встановлюється відповідний baseтег (CMS), щоб посилання правильно вирішувались. 2. Існуючий веб-сайт використовує відносні URL-адреси протягом усього часу, але пізніше вирішує впровадити "гарні" URL-адреси, які змінюють глибину URL-шляху. baseТег може розглядатися як краще «фіксації» все відносні URL.
MrWhite

@MrWhite, CMS не потрібно використовувати базовий тег для правильного вирішення посилань, оскільки HTML вже підтримує відносні шляхи, які за замовчуванням до поточної папки. Див розробку тут: stackoverflow.com/a/46539210/632951
Pacerier

1
@Pacerier Це залежить від місця розташування вмісту (FWIW я не маю на увазі WordPress та ін.)
MrWhite

@MrWhite, як правило, CMS не використовуватиме в першу чергу статичні посилання, тому такий приклад є дивним. Насправді, дуже мало веб-сайтів сьогодні створено за допомогою статичного HTML. - Я бачу ваші моменти там, але це рішення проблем, які в основному застаріли. (Усі та їхні бабусі і дідусі використовують для всього WordPress або подібне.)
Atli

2

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


2

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


1

Майте на увазі одне:

Якщо ви розробляєте веб-сторінку, яка відображатиметься в UIWebView на iOS, вам доведеться використовувати тег BASE. Інакше це не буде працювати. Будьте те JavaScript, CSS, зображення - жоден з них не буде працювати з відносними посиланнями під UIWebView, якщо не вказано тег BASE.

Мене це спіймало раніше, поки я не дізнався.


1

Я знайшов спосіб використовувати <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>

Ви повинні використовувати в кінці сторінки


0

Моя рекомендація НЕ використовувати цей <base>елемент в управлінні шляхами URL-адреси . Чому?

Він просто торгує однією проблемою за іншою. Без базового елемента ви можете використовувати будь-яку систему шляху, яка вам подобається, для ваших відносних шляхів і посилань, не побоюючись, що вони зірвуться Після того, як ви встановите базовий елемент на шлях, який ви "заблоковані", щоб спроектувати всі ваші URL-адреси, щоб відпрацювати цей шлях, і тепер доведеться змінити ВСІ шляхи на роботу з базового шляху. Погана ідея!

Це означає, що вам доведеться тепер писати ДЛІНШІ шляхи І слідкувати за тим, де кожен шлях відносно цієї бази. Гірше ..... при використанні <base>елемента вони рекомендують використовувати повністю кваліфікований базовий шлях для підтримки старих браузерів (" https://www.example.com/ "), тому тепер ви жорстко зашифрували свій домен у вашому домені сторінки або зробив усі ваші посилання залежними від дійсного шляху домену.

З іншого боку, щойно ви знову видаляєте базовий шлях зі свого веб-сайту, тепер ви знову можете використовувати короткі відносні шляхи, які можуть бути повністю кваліфікованими, використовувати абсолютні шляхи від кореня або використовувати шляхи, які справді відносяться до файл і папка, в якій ви перебуваєте. Він набагато гнучкіший. І краще за все фрагменти типу "#hello" працюють правильно без додаткових виправлень. Знову люди створюють проблеми, яких не існує.

Крім того, аргумент вище, що ваш базовий URL використовується для того, щоб допомогти вам переміщувати папки веб-сторінок на нові місця підпапок, сьогодні насправді не має значення, оскільки більшість сучасних серверів дозволяють швидко налаштувати будь-яку папку як нову кореневу папку програми під будь-яким доменом. Визначення або "корінь" веб-програми зараз не обмежуються ні папками, ні доменами.

Ця думка здається якось дурною. Тому я кажу, що вийдіть з базового URL-адреси та підтримайте старішу систему корінних маршрутів для сервера-клієнта, яка не використовує її.

Примітка. Якщо у вас є проблема управління шляхами завдяки якійсь новій системі API, рішення є простим ... будьте послідовними в тому, як ви відстежуєте всі ваші URL-адреси та посилання у своєму API. Не покладайтеся на підтримку браузера бази чи HTML5 або нові циркові хитрощі, як це роблять дітки JavaScript JavaScript. Просто послідовно прокладайте всі свої прив’язні теги, і у вас ніколи не буде проблем. Більше того, ваш веб-додаток миттєво переноситься на нові сервери незалежно від використовуваних систем шляху.

Whats old - знову новий! Базовий елемент явно полягає у спробі створити рішення проблеми, яка ніколи не існувала у Веб-світі 20 років тому, тим більше сьогодні.


-1

Приклад базового href

Скажіть типову сторінку із посиланнями:

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

.і посилання на різні папки:

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

За допомогою базового 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>


Висновок

( Базова ціль може бути корисною.) Базовий href марний, як:

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

Пов'язані


Напевно @downvoters не зможе пояснити, наскільки корисний basehref, тим більше, коли цілі галузі рекомендують не використовувати його.
Pacerier
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.