<base>
HTMLタグ を実際に見たことがない。その使用に落とし穴はありますか?
最新の本番サイト(または任意のサイト)で使用されていることに気付いたことがないという事実は、サイトのリンクを簡素化するための便利なアプリケーションがあるように見えますが、それを心配しています。
ベースタグを数週間使用した後、ベースタグを使用してmajorいくつかの落とし穴を見つけて、最初よりもずっと望ましくないものにしました登場しました。基本的に、ベースタグの下のhref='#topic'
およびhref=''
への変更は、デフォルトの動作とvery互換性がなく、このデフォルトの動作からの変更は簡単に実行できます。コントロール外のサードパーティライブラリはデフォルトの動作に論理的に依存するため、予期しない方法で非常に信頼性が低い。多くの場合、変更は微妙であり、大規模なコードベースを処理するときに、すぐには明らかにならない問題につながります。それ以来、以下で経験した問題の詳細を記した回答を作成しました。したがって、<base>
の広範な展開にコミットする前に、リンク結果を自分でテストしてください。私の新しいアドバイスです。
基本タグには直感的でない効果があるように見えるため、<base>
に依存する前に、結果を認識して自分でテストすることをお勧めします。私はそれらを発見したのでafter異なるURLを持つローカルサイトを処理するためにベースタグを使用しようとして、問題のある効果を見つけたのは、残念なことに、作成することを余儀なくされました他の人にとってのこれらの潜在的な落とし穴のこの要約。
以下の場合の例として<base href="http://www.example.com/other-subdirectory/">
のベースタグを使用し、コードが存在するページが http://localsite.com/original-subdirectoryのふりをします
リンクまたは名前付きアンカーまたは空白のhrefは、明示的に指定されていない限り、元のサブディレクトリを指しません。ベースタグはeverythingリンクを異なるものにします。代わりに、ページアンカーがベースタグのURLにリンクします。例:
<a href='#top-of-page' title='Some title'>A link to the top of the page via a named anchor</a>
bemeses<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>
bemeses<a href='http://www.example.com/other-subdirectory/?update=1' title='Some title'>A link to the base tag's page instead</a>
いくつかの作業により、これらのリンクがリンクしているページにリンクすることを明示的に指定することで、制御可能なリンクのこれらの問題を修正できますが、標準の動作に依存するサードパーティライブラリをミックスに追加すると、それは簡単に大きな混乱を引き起こす可能性があります。
条件付きコメントを必要とするIE6修正:dom階層の混乱を回避するために、ie6の条件付きコメントが必要です。つまり、上記の回答でBalusC
として言及されている<base href="http://www.example.com/"><!--[if lte IE 6]></base><![endif]-->
。
全体として、すべてのリンクを完全に編集制御できない限り、主要な問題は扱いにくいものになります。当初私が恐れていたように、それは価値がある以上にトラブルになります。今、私はそれのすべての使用法を書き直さなければなりません! :p
「フラグメント」/ハッシュを使用する場合の問題のテストの関連リンク:
http://www.w3.org/People/mimasa/test/base/
http://www.w3.org/People/mimasa/test/base/results
Izzyによる編集:コメントに関して私と同じ混乱に陥っているすべての人のために:
私は自分でそれを試したところ、次の結果が得られました。
#anchor
および?query
は、指定された<BASE>
に単に追加されます)。other.html
およびdir/other.html
はDOCUMENT_ROOT
で始まり、/other-subdirectory
は(正しく)として処理されますファイルのため、省略されました。したがって、相対リンクの場合、BASE
は移動したページで正常に機能しますが、アンカーと?queries
はファイル名を明示的に指定する必要があります(BASE
は末尾にスラッシュを付け、最後の要素は使用されているファイルの名前に対応します)。
<BASE>
をファイル自体へのの完全なURL(およびnotが存在するディレクトリに置き換え)と考える、そしてあなたは物事を正しくするでしょう。この例で使用されるファイルがother-subdirectory/test.html
(新しい場所に移動した後)であると仮定すると、正しい指定は次のようになります:
<base href="http://www.example.com/other-subdirectory/test.html
">
– et voila、everythingは期待どおりに動作します。#anchor
、?query
、other.html
、very/other.html
、/completely/other.html
。
<base>
タグを使用するかどうかを決定する前に、それがどのように機能するのか、何に使用できるのか、どのような影響があるのかを理解し、最終的に利点/欠点を上回る必要があります。
<base>
タグは、every linkの現在のコンテキストを心配する必要がないため、主にテンプレート言語での相対リンクの作成を容易にします。
あなたは例えばすることができます
<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>
タグは、終了タグ</base>
を持つnotとして指定されたHTML内にあるため、終了タグなしで<base>
を使用するのが正当です。ただし、IE6はそうではないと考え、コンテンツ全体afterの場合、<base>
タグはchildとして配置されますHTML DOMツリーの<base>
要素。これにより、HTML DOMインスペクターでbase
が必要であることが判明するまで、Javascript/jQuery/CSSで説明できない問題、つまりhtml>body
などの特定のセレクターで完全に到達不可能な要素が発生します。およびhead
)の間に。
IE6の一般的な修正は、IE条件付きコメントを使用して終了タグを含めることです。
<base href="http://example.com/en/"><!--[if lte IE 6]></base><![endif]-->
W3 Validatorを気にしない場合、または既にHTML5を使用している場合は、それを自己クローズできます。すべてのWebブラウザーはとにかくそれをサポートします。
<base href="http://example.com/en/" />
<base>
タグを閉じると、WinXP SP3上のIE6の insanity が即座に修正され、src
に相対URIを持つ<script>
リソースが無限ループで要求されます。
<base>
や<base href="//example.com/somefolder/">
などの<base href="/somefolder/">
タグで相対URIを使用すると、別の潜在的なIE問題が明らかになります。 IE6/7/8ではこれは失敗します。ただし、これは正確にはブラウザの問題ではありません。 <base>
タグで相対URIを使用することは、それ自体が間違っています。 HTML4仕様 は、絶対URIである必要があると述べているため、http://
またはhttps://
スキームで開始します。これは HTML5仕様 で削除されました。したがって、HTML5を使用し、HTML5互換のブラウザーのみを対象とする場合は、<base>
タグで相対URIを使用することで十分です。
<a href="#anchor">
などの名前付き/ハッシュフラグメントアンカー、<a href="?foo=bar">
などのクエリ文字列アンカー、および<a href=";foo=bar">
などのパスフラグメントアンカーの使用については、基本的に宣言する<base>
タグall相対リンク、それらの種類のアンカーを含む。相対リンクは、現在のリクエスト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}
は基本的に、PHPでは$_SERVER['REQUEST_URI']
、JSPでは${pageContext.request.requestURI}
、JSFでは#{request.requestURI}
に変換されます。 JSFのようなMVCフレームワークには、この定型文をすべて減らし、<base>
の必要性をなくすタグがあることに注意してください。 a.oも参照してください。 他のJSFページへのリンク/ナビゲートに使用するURL 。
まあ、ちょっと待って。基本タグがこの悪い評判に値するとは思わない。
ベースタグのいいところは、複雑なURLの書き換えを簡単に行えることです。
これが一例です。 http://example.com/product/category/thisproduct から http://example.com/product/thisproduct に移動することにしました。最初のURLを2番目のURLに書き換えるように.htaccessファイルを変更します。
ベースタグを配置したら、.htaccessの書き換えを行います。問題ない。しかし、ベースタグがなければ、あなたの全ての相対リンクは壊れます。
URLの書き換えは、サイトのアーキテクチャと検索エンジンの可視性を向上させるのに役立つので、しばしば必要です。確かに、あなたは人々が言及した「#」と「」の問題に対する回避策が必要です。しかし、ベースタグはツールキット内の場所に値します。
それを使うべきかどうかを決めるために、あなたはそれが何をするのか、そしてそれが必要とされるのかを知っておくべきです。これはすでに この回答 で概説されており、私もこれに貢献しました。しかし、理解しやすくするために、ここで2番目の説明をします。まず理解する必要があります。
<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に置き換わることになっています。そのため、ユーザーが<BASE>
で指定されたURLを呼び出したかのように、すべてのリンクをレンダリングします。これは他のいくつかの答えのいくつかの混乱を説明します:
<BASE>
で指定されたものが、ユーザーから最初に呼び出されたものと異なる場合)<BASE>
:の設定方法には特別な注意を払う必要があります。mod_rewrite
を使ってあるURLを「きれいに」したいとしましょう:
<DOCUMENT_ROOT>/some/dir/file.php?lang=en
http://www.example.com/some/dir/file.php?lang=en
http://www.example.com/en/file
mod_rewrite
がtransparentlyにユーザーフレンドリーなURLを本物のURLに書き換えるために使われると仮定しましょう(外部からのリダイレクトはないので、 "ユーザーフレンドリーな" URLはブラウザに残ります)実際のものがロードされている間、アドレスバー)。今何をする?
<BASE>
が指定されていない:すべての相対リンクを解除します(これらは現在http://www.example.com/en/file
に基づいているため)。<BASE HREF='http://www.example.com/some/dir>
:絶対に間違っています。 dir
は、指定されたURLのfile部分と見なされるので、それでも、すべての相対リンクは壊れています。<BASE HREF='http://www.example.com/some/dir/>
:もういいよ。しかし、「タイプ4」の相対リンクはまだ壊れています(「ケースB」を除く)。<BASE HREF='http://www.example.com/some/dir/file.php>
:その通りです。すべてこれでうまくいくはずです。これは、ドキュメントのall URLに適用されることに注意してください。
<A HREF=
<IMG SRC=
<SCRIPT SRC=
Drupalは当初<base>
タグに頼っていましたが、その後HTTPクローラとキャッシュの問題のために使わないという決定を下しました。
私は一般的にリンクを投稿するのは好きではありません。しかし、これは<base>
タグを使用して実際の経験の詳細を探している人に役立つ可能性があるため、共有する価値があります。
オフラインで閲覧しやすいようにページが簡単になります。完全修飾URLをベースタグに入れると、リモートリソースが正しくロードされます。
ハッシュ "#"は現在ベース要素と連動してジャンプリンクに機能しますが、IE9ではなく最新バージョンのGoogle ChromeとFirefoxでのみ有効です。
IE9は、どこにもジャンプせずにページをリロードさせるようです。 iframeの外側でジャンプリンクを使用している場合は、フレーム内の別のページにジャンプリンクをロードするようにフレームに指示しながら、代わりにフレーム内にロードされたジャンプリンクページの2番目のコピーを取得します。
あまり知られていないので、おそらくそれほど人気はないでしょう。すべての主要なブラウザがそれをサポートしているので、私はそれを使うのを恐れないでしょう。
あなたのサイトがAJAXを使っているなら、あなたはあなたのすべてのページがそれが正しく設定されていることを確かめたいと思うでしょう。
HTML 4.01 Strictページでtarget
属性を使用しないでください。
ページ内にインライン展開されたSVG画像の場合、base
タグを使用したときに発生するもう1つの重要な問題があります。
base
タグを使用すると(上で既に説明したように)、次のように相対的なハッシュURLを使用する機能が事実上失われることになります。
<a href="#foo">
現在のドキュメントの場所ではなくベースURLに対して解決されるため、相対的なものではなくなったためです。ですから、現在の文書のパスをこのような種類のリンクに追加する必要があります。
<a href="/path/to/this/page/name.html#foo">
そのためbase
タグの一見ポジティブな側面(これは長いURLプレフィックスをアンカータグから遠ざけて、より短く、より短いアンカーを取得することです)の1つは、完全にローカルハッシュURLを裏付けるものです。
これは、ページ内でSVGをインライン展開するときに特に厄介です。静的SVGでも動的SVGでも SVGにはこのような参照が多数ある可能性があります であり、base
タグが使用されるとすぐに壊れます。すべてではありませんが、ほとんどのユーザーエージェントの実装で(Chromeは執筆時点で少なくともこれらのシナリオで動作します)。
あなたがあなたのページを処理/生成するテンプレートシステムあるいは他のツールチェーンを使用しているなら、私はそれが解決するよりそれがテーブルにもっと問題をもたらすので、私は常にbase
タグを取り除くことを試みます。
また、Webサーバを標準以外のポートで実行している場合は、ベースのhrefにもポート番号を含める必要があることに注意してください。
<base href="//localhost:1234" /> // from base url
<base href="../" /> // for one step above
私は本当にそれを使うことに意味を見たことがない。ごくわずかな利点しかもたらさず、物事を使いにくくさえするかもしれません。
たまたま何百、何千ものリンクがある場合を除き、すべて同じサブディレクトリにリンクします。それからそれはあなたに帯域幅の数バイトを節約するかもしれません。
後付けとして、IE6のタグに問題があることを思い出します。サイトのさまざまな部分をさまざまな場所にリダイレクトして、体のどこにでも配置できます。これはIE7で修正され、多くのサイトが壊れました。
AngularJSを使用してBASEタグを設定すると、$ cookieStoreが暗黙のうちに破られ、私のアプリがCookieを書き込めなくなった理由を理解するのにしばらく時間がかかりました。警告されます...
ベースタグが使われているサイトもあり、説明されている問題が発生しました。 (jqueryのアップグレード後)、タブURLを次のようにすることで修正できました。
<li><a href="{$smarty.server.REQUEST_URI}#tab_1"></li>
これはそれらを「ローカル」にします
私が使用した参照:
http://bugs.jqueryui.com/ticket/7822http://htmlhelp.com/reference/html40/head/base.htmlhttp: //tjvantoll.com/2013/02/17/using-jquery-ui-tabs-with-the-base-tag/
私は<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>
あなたはページの終わりに使うべきです
覚えておくべき1つのこと:
IOSのUIWebView内に表示されるWebページを開発する場合は、BASEタグを使用する必要があります。それ以外ではうまくいきません。 JavaScript、CSS、画像であれば、タグBASEが指定されていない限り、UIWebViewの下の相対リンクでは機能しません。
私が気付くまで、私は前にこれに巻き込まれました。