Jakie są zalecenia dla tagu HTML <base>?

Nigdy wcześniej nie widziałem <base>tagu HTML, którego rzeczywiście używano. Czy są jakieś pułapki w jego użyciu, co oznacza, że ​​powinienem go unikać?

Fakt, że nigdy nie zauważyłem, że jest używany na nowoczesnej stronie produkcyjnej (lub innej stronie), sprawia, że ​​jestem ostrożny, chociaż wydaje się, że może mieć przydatne aplikacje do uproszczenia linków na mojej stronie.

Edytować

Po kilku tygodniach używania tagu podstawowego znalazłem kilka poważnych problemów z użyciem tagu podstawowego, który sprawia, że ​​jest on mniej pożądany, niż się pojawił. Zasadniczo zmiany w znaczniku bazowym href='#topic'i href=''pod nim są bardzo niezgodne z ich domyślnym zachowaniem, a ta zmiana w stosunku do domyślnego zachowania może sprawić, że biblioteki stron trzecich poza twoją kontrolą będą bardzo niewiarygodne w nieoczekiwany sposób, ponieważ będą one logicznie zależeć od domyślnego zachowania. Często zmiany są subtelne i prowadzą do nieoczywistych problemów w przypadku dużej bazy kodu. Od tego czasu stworzyłem odpowiedź opisującą problemy, których doświadczyłem poniżej. Więc przetestuj wyniki linków, zanim zdecydujesz się na powszechne wdrożenie <base>, to moja nowa rada!

Przed podjęciem decyzji, czy użyć <base>tagu, czy nie, musisz zrozumieć, jak to działa, do czego może być użyty i jakie są tego konsekwencje, a na koniec przeważyć zalety / wady.

<base>Tag ułatwia głównie tworzenie względne linki w templating językach nie trzeba się martwić o obecnej sytuacji w każdym linkiem.

Możesz zrobić na przykład

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

zamiast

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

Uwaga: <base href>wartość kończy się ukośnikiem, w przeciwnym razie zostanie zinterpretowana względem ostatniej ścieżki.

Jeśli chodzi o zgodność przeglądarki, powoduje to tylko problemy w IE. <base>Tag HTML jest określona jako nie posiadające znacznik końcowy </base>, tak to prawda tylko do użytku <base>bez znacznika końcowego. Jednak IE6 myśli inaczej i cała zawartość po tym <base>tagu jest umieszczony w takim przypadku, jak dziecko z <base>elementu w drzewie DOM HTML. Może to powodować na pierwszy rzut oka niewyjaśnione problemy w Javascript / jQuery / CSS, tj. Elementy są całkowicie nieosiągalne w określonych selektorach html>body, dopóki nie odkryjesz w inspektorze DOM HTML, że pomiędzy nimi powinien być base(i head).

Typowa poprawka IE6 używa komentarza warunkowego IE w celu dołączenia znacznika końcowego:

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

Jeśli nie zależy ci na walidatorze W3 lub korzystasz już z HTML5, możesz go po prostu zamknąć, każdy przeglądarka internetowa i tak go obsługuje:

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

Zamknięcie <base>znacznika natychmiast naprawia również szaleństwo IE6 w WinXP SP3, aby żądać <script>zasobów ze względnym URI w srcnieskończonej pętli.

Kolejny potencjalny problem IE pojawi się, gdy użyjesz względnego identyfikatora URI w <base>znaczniku, takiego jak <base href="https://example.com/somefolder/">lub <base href="https://stackoverflow.com/somefolder/">. To się nie powiedzie w IE6 / 7/8. Nie jest to jednak wina przeglądarki; używanie względnych identyfikatorów URI w <base>znaczniku jest błędne. W specyfikacji HTML4 podano, że powinien to być bezwzględny identyfikator URI, zaczynając od schematu http://lub https://. Zostało to usunięte w specyfikacji HTML5 . Jeśli więc używasz tylko HTML5 i docelowych przeglądarek zgodnych z HTML5, wszystko powinno być w porządku, używając względnego identyfikatora URI w <base>tagu.

Jeśli chodzi o stosowanie kotwic nazwanych / fragmentów mieszających, jak <a href="#anchor">, kotwicowych ciągów znaków podobnych <a href="?foo=bar">i kotwicowych fragmentów ścieżki podobnych <a href=";foo=bar">, za pomocą <base>znacznika zasadniczo deklarujesz wszystkie względne linki względem niego, w tym tego rodzaju kotwice. Żadne z odnośników relacyjnych nie jest już związane z bieżącym identyfikatorem URI żądania (jak by się to stało bez <base>tagu). To może być przede wszystkim mylące dla początkujących. Aby zbudować te kotwice we właściwy sposób, w zasadzie musisz dołączyć identyfikator URI,

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

gdzie w ${uri}zasadzie tłumaczy się $_SERVER['REQUEST_URI']na PHP, ${pageContext.request.requestURI}JSP i #{request.requestURI}JSF. Należy zauważyć, że frameworki MVC, takie jak JSF, mają znaczniki zmniejszające cały ten szablon i eliminujące potrzebę <base>. Zobacz także m.in. Jakiego adresu URL użyć do połączenia / nawigacji do innych stron JSF .

Podział efektów znacznika podstawowego:

Tag bazowy wydaje się mieć nieintuicyjne efekty, więc zalecam zdawanie sobie sprawy z wyników i testowanie ich samemu, zanim zaczniesz na nich polegać <base>! Ponieważ odkryłem je po próbie użycia tagu podstawowego do obsługi lokalnych stron z różnymi adresami URL i odkryłem problematyczne efekty dopiero po moim rozczarowaniu, czuję się zmuszony do stworzenia tego podsumowania tych potencjalnych pułapek dla innych.

Użyję podstawowego tagu: <base href="http://www.example.com/other-subdirectory/">jako mojego przykładu w poniższych przypadkach i udam, że strona, na której znajduje się kod, to http://localsite.com/original-subdirectory

Poważny:

Żadne linki, nazwane kotwice lub puste hrefy nie będą wskazywać oryginalnego podkatalogu, chyba że zostanie to wyraźnie zaznaczone: Tag podstawowy powoduje, że wszystko łączy się inaczej, łącznie z linkami kotwiczącymi tej samej strony do adresu URL tagu podstawowego, np .:

• <a href='#top-of-page' title='Some title'>A link to the top of the page via a named anchor</a>
  staje się
  <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>
  staje się
  <a href='http://www.example.com/other-subdirectory/?update=1' title='Some title'>A link to the base tag's page instead</a>

Przy odrobinie pracy możesz rozwiązać te problemy w linkach, nad którymi masz kontrolę, wyraźnie określając, że linki te prowadzą do strony, na której się znajdują, ale gdy dodasz biblioteki innych firm do miksu, które opierają się na standardowym zachowaniu, może łatwo spowodować wielki bałagan.

Mniejszy:

Poprawka IE6 wymagająca komentarzy warunkowych: Wymaga komentarzy warunkowych dla ie6, aby uniknąć zepsucia hierarchii domen, tj. <base href="http://www.example.com/"><!--[if lte IE 6]></base><![endif]-->Jak BalusCwspomniano w jego odpowiedzi powyżej.

Ogólnie rzecz biorąc, główny problem sprawia, że ​​korzystanie z niego jest trudne, chyba że masz pełną kontrolę nad edycją każdego linku, a jak się początkowo obawiałem, sprawia to więcej kłopotów niż jest wart. Teraz muszę odejść i przepisać wszystkie moje zastosowania! : p

Powiązane linki do testowania problemów podczas używania „fragmentów” / skrótów:

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

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

Edytowane przez Izzy: Dla was wszystkich napotykam takie samo zamieszanie jak ja odnośnie komentarzy:

Właśnie to przetestowałem, z następującymi wynikami:

• końcowe ukośnik czy nie, nie ma znaczenia dla podanych tutaj przykładów ( #anchori ?querypo prostu zostanie dołączony do podanego <BASE>).
• Jednak robi to różnicę w przypadku linków względnych: pomijając końcowy ukośnik other.htmli dir/other.htmlzaczynałby się DOCUMENT_ROOTod podanego przykładu, /other-subdirectorybędąc (poprawnie) traktowanym jak plik i tym samym pominiętym.

W przypadku linków względnych BASEdziała dobrze z przeniesioną stroną - podczas gdy kotwice i ?querieswymagałyby wyraźnego określenia nazwy pliku (z BASEukośnikiem końcowym lub ostatnim elementem nie odpowiadającym nazwie pliku, w którym został użyty).

Pomyśl o tym jako o <BASE>zamianie pełnego adresu URL do samego pliku (a nie katalogu, w którym on się znajduje), a wszystko będzie dobrze. Zakładając, że plik użyty w tym przykładzie był other-subdirectory/test.html(po przeniesieniu do nowej lokalizacji), poprawna specyfikacja powinna być:

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

- et voila, wszystko działa zgodnie z oczekiwaniami: #anchor, ?query, other.html, very/other.html, /completely/other.html.

Poczekaj chwilę. Nie sądzę, że tag podstawowy zasługuje na tę złą reputację.

Zaletą tagu bazowego jest to, że umożliwia on wykonywanie skomplikowanych przeróbek adresów URL bez większych problemów.

Oto przykład. Zdecydujesz się przenieść http://example.com/product/category/thisproduct na http://example.com/product/thisproduct . Zmieniasz plik .htaccess, aby przepisać pierwszy adres URL na drugi adres URL.

Po umieszczeniu znacznika podstawowego wykonujesz przepisywanie .htaccess i to wszystko. Nie ma problemu. Ale bez tagu podstawowego wszystkie linki względne ulegną awarii.

Przepisywanie adresów URL jest często konieczne, ponieważ ich poprawianie może pomóc w architekturze witryny i widoczności w wyszukiwarkach. To prawda, że ​​będziesz potrzebować obejścia problemów „#” i „, o których wspominali ludzie. Ale znacznik podstawowy zasługuje na miejsce w zestawie narzędzi.

Aby zdecydować, czy należy go użyć, czy nie, należy zdawać sobie sprawę z tego, co robi i czy jest potrzebny. Jest to już częściowo zarysowane w tej odpowiedzi , do której również się przyczyniłem. Ale aby ułatwić zrozumienie i przestrzeganie, drugie wyjaśnienie tutaj. Najpierw musimy zrozumieć:

Jak łącza są przetwarzane przez przeglądarkę bez <BASE>użycia?

Dla niektórych przykładów załóżmy, że mamy te adresy URL:

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

Zarówno A + B powoduje, że ten sam plik ( index.html) jest wysyłany do przeglądarki, C oczywiście wysyła page.html, a D wysyła /subdir/page.html.

Załóżmy ponadto, że obie strony zawierają zestaw linków:

1) w pełni kwalifikowane łącza bezwzględne ( http://www...)
2) lokalne łącza bezwzględne ( /some/dir/page.html)
3) łącza względne, w tym nazwy plików (dir/page.html ) i
4) łącza względne tylko z „segmentami” ( #anchor, ?foo=bar).

Przeglądarka odbiera stronę i renderuje HTML. Jeśli znajdzie jakiś adres URL, musi wiedzieć, gdzie go wskazać. Jest to zawsze jasne dla linku 1), który jest przyjmowany w obecnej postaci. Wszystkie pozostałe zależą od adresu URL renderowanej strony:

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

Teraz co się zmienia z <BASE> użyciem?

<BASE> ma zastąpić adres URL tak, jak wygląda w przeglądarce . Renderuje więc wszystkie linki tak, jakby użytkownik wywołał adres URL określony w <BASE>. Co wyjaśnia niektóre zamieszanie w kilku innych odpowiedziach:

• znowu nic się nie zmienia dla „w pełni kwalifikowanych linków bezwzględnych” („typ 1”)
• w przypadku lokalnych łączy bezwzględnych serwer docelowy może się zmienić (jeśli ten określony w <BASE>różni się od tego, który jest wywoływany początkowo od użytkownika)
• względne adresy URL stają się tutaj krytyczne, więc musisz zachować szczególną ostrożność podczas ustawiania <BASE> :
  • lepiej unikać ustawiania go na katalog . W ten sposób linki „typu 3” mogą nadal działać, ale z pewnością psują linki „typu 4” (z wyjątkiem „przypadku B”)
  • ustawienie go na w pełni kwalifikowaną nazwę pliku daje w większości przypadków pożądane wyniki.

Przykład najlepiej to wyjaśnia

Powiedz, że chcesz „upiększyć” jakiś adres URL, używając mod_rewrite:

• prawdziwy plik: <DOCUMENT_ROOT>/some/dir/file.php?lang=en
• prawdziwy adres URL: http://www.example.com/some/dir/file.php?lang=en
• przyjazny dla użytkownika adres URL: http://www.example.com/en/file

Załóżmy, że mod_rewritesłuży do przezroczystego przepisywania przyjaznego dla użytkownika adresu URL na rzeczywisty (bez zewnętrznego przekierowywania, więc „przyjazny dla użytkownika” pozostaje w pasku adresu przeglądarki, podczas gdy rzeczywisty jest ładowany). Co zrobić teraz?

• nie <BASE>określono: zrywa wszystkie linki względne (jak by były oparte nahttp://www.example.com/en/file razie)
• <BASE HREF='http://www.example.com/some/dir>: Absolutnie źle. dirbędzie uważany za plik część określonego adresu URL, więc wszystkie względne linki są zepsute.
• <BASE HREF='http://www.example.com/some/dir/>: Już lepiej. Ale względne linki „typu 4” są nadal zerwane (z wyjątkiem „przypadku B”).
• <BASE HREF='http://www.example.com/some/dir/file.php>: Dokładnie. Wszystko powinno z tym pracować.

Ostatnia nuta

Pamiętaj, że dotyczy to wszystkich adresów URL w dokumencie:

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

Drupal początkowo polegał na <base>tagu, a później podjął decyzję o nieużywaniu z powodu problemów z przeszukiwaczami HTTP i pamięciami podręcznymi.

Ogólnie nie lubię publikować linków. Ale ten naprawdę warto udostępnić, ponieważ może przydać się tym, którzy szukają szczegółów prawdziwego świata z <base>tagiem:

http://drupal.org/node/13148

Ułatwia przeglądanie stron w trybie offline; możesz umieścić w pełni kwalifikowany adres URL w znaczniku podstawowym, a następnie zdalne zasoby zostaną poprawnie załadowane.

Skrót „#” obecnie działa dla przeskoków w połączeniu z elementem podstawowym, ale tylko w najnowszych wersjach Google Chrome i Firefox, NIE IE9.

Wygląda na to, że IE9 powoduje przeładowanie strony, bez skakania w dowolnym miejscu. Jeśli korzystasz z łączy skoku na zewnętrznej stronie elementu iframe, kierując ramką w celu załadowania łączy skoku na osobnej stronie w ramce, zamiast tego otrzymasz drugą kopię strony łącza skoku załadowaną wewnątrz ramki.

Prawdopodobnie nie jest zbyt popularny, ponieważ nie jest dobrze znany. Nie bałbym się go używać, ponieważ wszystkie popularne przeglądarki go obsługują.

Jeśli Twoja witryna korzysta z AJAX, upewnij się, że wszystkie strony mają ustawiony poprawnie, lub możesz uzyskać linki, których nie można rozwiązać.

Po prostu nie używaj targetatrybutu na ścisłej stronie HTML 4.01.

W przypadku obrazów SVG umieszczonych na stronie istnieje inna ważna kwestia, która pojawia się, gdy base używany jest znacznik:

Ponieważ dzięki basetagowi (jak już wspomniano powyżej) skutecznie tracisz możliwość używania względnych adresów URL skrótów, takich jak w

<a href="#foo">

ponieważ będą one rozstrzygane na podstawie podstawowego adresu URL, a nie lokalizacji bieżącego dokumentu, a zatem nie są już względne. Musisz więc dodać ścieżkę bieżącego dokumentu do tego rodzaju linków, takich jak w

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

Tak więc jeden z pozornie pozytywnych aspektów basetagu (który polega na odsunięciu długich prefiksów URL od tagu kotwicy i uzyskaniu ładniejszych, krótszych kotwic) całkowicie psuje lokalne adresy URL mieszania.

Jest to szczególnie denerwujące, gdy wstawia się SVG na stronę, niezależnie od tego, czy jest to statyczny SVG, czy dynamicznie generowany SVG, ponieważ w SVG może być wiele takich odniesień i wszystkie one się zepsują, gdy tylkobase zostanie użyty tag, u większości, ale nie dla wszystkich użytkowników implementacje agentów (Chrome przynajmniej nadal działa w tych scenariuszach w momencie pisania).

Jeśli używasz systemu szablonów lub innego łańcucha narzędzi, który przetwarza / generuje strony, zawsze starałbym się pozbyć basetagu, ponieważ, jak go widzę, wnosi więcej problemów do tabeli niż rozwiązuje.

Należy również pamiętać, że jeśli serwer WWW działa na niestandardowym porcie, należy podać również numer portu w hrefie podstawowym:

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

Nigdy tak naprawdę nie widziałem sensu w używaniu go. Zapewnia bardzo małą przewagę, a może nawet utrudniać korzystanie z niej.

Jeśli nie masz setek lub tysięcy linków, wszystkie do tego samego podkatalogu. Może to zaoszczędzić kilka bajtów przepustowości.

Po namyśle wydaje mi się, że wystąpił problem z tagiem w IE6. Możesz umieścić je w dowolnym miejscu w ciele, przekierowując różne części witryny do różnych lokalizacji. Zostało to naprawione w IE7, który zepsuł wiele stron.

mam również witrynę, na której używany jest base-tag i wystąpił opisany problem. (po uaktualnieniu jquery), był w stanie to naprawić, korzystając z takich adresów URL kart:

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

dzięki temu są „lokalni”

referencje, których użyłem:

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 /

Podczas pracy z AngularJS znacznik BASE po cichu złamał $ cookieStore i zajęło mi trochę czasu, aby dowiedzieć się, dlaczego moja aplikacja nie może już pisać ciasteczek. Być ostrzeżonym...

Należy pamiętać o jednej rzeczy:

Jeśli tworzysz stronę internetową, która będzie wyświetlana w UIWebView na iOS, musisz użyć znacznika BASE. Po prostu nie zadziała inaczej. Czy to JavaScript, CSS, obrazy - żaden z nich nie będzie działał z odnośnikami względnymi w UIWebView, chyba że podany zostanie tag BASE.

Byłem już przyłapany na tym, dopóki się nie dowiem.

Znalazłem sposób na wykorzystanie <base>i zakotwiczenie linków. Możesz użyć JavaScript, aby linki #contactdziałały tak, jak powinny. Użyłem go na niektórych stronach paralaksy i działa dla mnie.

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

Powinieneś użyć na końcu strony

Moja rada jest taka , aby NIE używać <base>elementu w zarządzaniu ścieżki url . Dlaczego?

Po prostu zamienia jeden problem na drugi. Bez elementu podstawowego możesz używać dowolnego systemu ścieżek dla swoich ścieżek względnych i linków bez obawy, że się zepsują. W chwili, gdy ustawisz element podstawowy na ścieżkę, w której „jesteś zamknięty”, na zaprojektowanie wszystkich adresów URL do pracy z tą ścieżką, a teraz będziesz musiał zmienić WSZYSTKIE ścieżki, aby działały ze ścieżki podstawowej. Kiepski pomysł!

Oznacza to, że musisz teraz pisać DŁUŻSZE ścieżki i śledzić, gdzie każda ścieżka jest względem tej podstawy. Gorzej ... podczas korzystania z <base>elementu zalecają użycie w pełni kwalifikowanej ścieżki podstawowej do obsługi starszych przeglądarek („ https://www.example.com/ ”), więc teraz na stałe zapisałeś swoją domenę w swojej stronę lub uzależniły wszystkie linki od prawidłowej ścieżki domeny.

Z drugiej strony, gdy tylko ponownie usuniesz ścieżkę podstawową ze swojej witryny, możesz ponownie użyć krótszych ścieżek względnych, które można w pełni zakwalifikować, użyć ścieżek bezwzględnych z katalogu głównego lub ścieżek, które są naprawdę względne w stosunku do plik i folder, w którym się znajdujesz. Jest znacznie bardziej elastyczny. A najlepsze ze wszystkich fragmentów, takich jak „#hello”, działają poprawnie bez żadnych dodatkowych poprawek. Znów ludzie tworzą problemy, które nie istnieją.

Także powyższy argument, że Twój podstawowy adres URL pomaga migrować foldery stron internetowych do nowych lokalizacji podfolderów, nie ma dziś tak naprawdę znaczenia, ponieważ większość współczesnych serwerów pozwala szybko skonfigurować dowolny podfolder jako nowy folder główny aplikacji w dowolnej domenie. Definicja lub „katalog główny” aplikacji sieci Web nie jest obecnie ograniczona przez foldery ani domeny.

Cała debata wydaje się trochę głupia. Mówię więc, pomiń podstawowy adres URL i obsługuj starszy domyślny system ścieżki serwer-klient, który go nie używa.

Uwaga: jeśli masz problem z kontrolowaniem ścieżek z powodu jakiegoś nowego systemu API, rozwiązanie jest proste ... bądź konsekwentny w sposobie śledzenia wszystkich adresów URL i linków w interfejsie API. Nie polegaj na wsparciu przeglądarki podstawowych lub HTML5 lub nowszych sztuczek cyrkowych, jak robią to javascript API kiddies. Wystarczy konsekwentnie śledzić wszystkie tagi kotwicy i nigdy nie będziesz mieć problemów. Co więcej, twoja aplikacja internetowa jest natychmiast przenośna na nowe serwery, niezależnie od używanych systemów ścieżek.

To, co stare, znów jest nowe! Podstawowym elementem jest oczywiście próba stworzenia rozwiązania problemu, który nigdy nie istniał w Web World 20 lat temu, a tym bardziej dzisiaj.

Przykład bazy href

Powiedz typową stronę z linkami:

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

.i linki do folderu diff:

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

Dzięki base href możemy uniknąć powtarzania folderu podstawowego:

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

Więc to jest wygrana ... a jednak strony zbyt często zawierają adresy URL do różnych baz A obecna sieć obsługuje tylko jeden podstawowy href na stronę , więc wygrana jest szybko tracona jako bazy, które nie są powtarzane, np .:

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

( Podstawowy cel może być przydatny.) Podstawowy href jest bezużyteczny, ponieważ:

• strona jest równie mokra ponieważ:
  • domyślna podstawowa [–folder] ⇌ doskonała (chyba że niepotrzebne / rzadkie wyjątki 𝒞1 i 𝒞2 ).
  • bieżąca sieć ⇌ wiele podstawowych hrefów nie jest obsługiwanych .

Związane z

• porównanie z bazą przepisywania Apache ∙