@@ -948,26 +948,48 @@ Relative URLs</h4>
948
948
<h5 id='local-urls'>
949
949
Fragment URLs</h5>
950
950
951
- To work around some common eccentricities in browser URL handling,
952
- CSS has special behavior for fragment-only urls.
951
+ To enable element ID references to work in CSS
952
+ regardless of base URL changes
953
+ or shadow DOM,
954
+ <<url>> s have special behavior
955
+ when they contain only a fragment.
953
956
954
957
If a <<url>> 's value starts with a U+0023 NUMBER SIGN (<code> #</code> ) character,
955
- parse it as per normal for URLs,
956
- but additionally set the <dfn export for="url()">local url flag</dfn> of the <<url>> .
958
+ then the URL additionally has its
959
+ <dfn export for="<url>">local url flag</dfn> set,
960
+ and is a [=tree-scoped reference=]
961
+ for the URL's [=url/fragment=] .
957
962
958
963
When matching a <<url>> with the <a>local url flag</a> set,
959
- ignore everything but the URL's fragment,
960
- and resolve that fragment against the [=node tree=]
961
- of the stylesheet's [=CSSStyleSheet/owner node=] .
962
- This reference must always be treated as same-document
963
- (rather than cross-document).
964
-
965
- ISSUE(3320): This relative URL resolution behavior is under discussion.
964
+ resolve it as a [=tree-scoped reference=]
965
+ with the tree's IDs as the associated [=tree-scoped names=] :
966
+ specifically, resolve to the first element
967
+ in [=tree order=]
968
+ among the associated [=node tree=] 's descendants
969
+ with the URL's [=url/fragment=] as its ID.
970
+ (And, as usual for [=tree-scoped references=] ,
971
+ continuing up to the host's tree if needed.)
972
+ If no such element is found,
973
+ the URL fails to resolve.
974
+
975
+ Issue: Possibly reference <l spec=html> [=find a potential indicated element=] </l> ,
976
+ but that is defined specifically for {{Document}} s,
977
+ not {{ShadowRoot}} s.
978
+
979
+ Issue: I'm just folding together "can't find the ID"
980
+ and "is a Media Fragment or other non-ID fragment",
981
+ and treating both of them as a failed reference.
982
+ I <em> think</em> this is reasonable.
966
983
967
984
Note: This means that such fragments will resolve
968
985
against the contents of the current document
969
- (and in consideration of shadow DOM, only within the stylesheet's associated [=node tree=] ),
970
- regardless of what base URL relative URLs outside of CSS resolve against.
986
+ (or whichever [=node tree=] the stylesheet lives in,
987
+ if shadow DOM is involved)
988
+ regardless of how such relative URLs would resolve elsewhere
989
+ (ignoring, for example, <{base}> elements
990
+ changing the base URL,
991
+ or relative URLs in linked stylesheets
992
+ resolving against the stylesheet's URL).
971
993
972
994
<div class="example">
973
995
In the following example,
@@ -986,25 +1008,6 @@ Fragment URLs</h5>
986
1008
a ''url()'' with the <a>local url flag</a> set,
987
1009
it must serialize as just the fragment.
988
1010
989
- <details class=note>
990
- <summary> What “browser eccentricities”?</summary>
991
-
992
- Theoretically, browsers should re-resolve any relative URLs,
993
- including fragment-only URLs,
994
- whenever the document's base URL changes
995
- (such as through mutation of the <{base}> element,
996
- or calling {{History/pushState()}} ).
997
- In many cases they don't, however,
998
- and so without special handling,
999
- fragment-only URLs will suddenly become cross-document references
1000
- (pointing at the previous base URL)
1001
- and break in many of the places they're used.
1002
-
1003
- Since fragment-only URLs express a clear semantic
1004
- of wanting to refer to the current document
1005
- regardless of what its current URL is,
1006
- this hack preserves the expected behavior at least in these cases.
1007
- </details>
1008
1011
1009
1012
<h4 id="url-empty">
1010
1013
Empty URLs</h4>
0 commit comments