[css-values-4] Rephrase fragment-only URLs in terms of tree-scoped references. w3c#3320

Author: tabatkins

css-values-4/Overview.bs

@@ -948,26 +948,48 @@ Relative URLs</h4>
 <h5 id='local-urls'>
 Fragment URLs</h5>
 
-	To work around some common eccentricities in browser URL handling,
-	CSS has special behavior for fragment-only urls.
+	To enable element ID references to work in CSS
+	regardless of base URL changes
+	or shadow DOM,
+	<<url>>s have special behavior
+	when they contain only a fragment.
 
 	If a <<url>>'s value starts with a U+0023 NUMBER SIGN (<code>#</code>) character,
-	parse it as per normal for URLs,
-	but additionally set the <dfn export for="url()">local url flag</dfn> of the <<url>>.
+	then the URL additionally has its
+	<dfn export for="<url>">local url flag</dfn> set,
+	and is a [=tree-scoped reference=]
+	for the URL's [=url/fragment=].
 
 	When matching a <<url>> with the <a>local url flag</a> set,
-	ignore everything but the URL's fragment,
-	and resolve that fragment against the [=node tree=]
-	of the stylesheet's [=CSSStyleSheet/owner node=].
-	This reference must always be treated as same-document
-	(rather than cross-document).
-
-	ISSUE(3320): This relative URL resolution behavior is under discussion.
+	resolve it as a [=tree-scoped reference=]
+	with the tree's IDs as the associated [=tree-scoped names=]:
+	specifically, resolve to the first element
+	in [=tree order=]
+	among the associated [=node tree=]'s descendants
+	with the URL's [=url/fragment=] as its ID.
+	(And, as usual for [=tree-scoped references=],
+	continuing up to the host's tree if needed.)
+	If no such element is found,
+	the URL fails to resolve.
+
+	Issue: Possibly reference <l spec=html>[=find a potential indicated element=]</l>,
+	but that is defined specifically for {{Document}}s,
+	not {{ShadowRoot}}s.
+
+	Issue: I'm just folding together "can't find the ID"
+	and "is a Media Fragment or other non-ID fragment",
+	and treating both of them as a failed reference.
+	I <em>think</em> this is reasonable.
 
 	Note: This means that such fragments will resolve
 	against the contents of the current document
-	(and in consideration of shadow DOM, only within the stylesheet's associated [=node tree=]),
-	regardless of what base URL relative URLs outside of CSS resolve against.
+	(or whichever [=node tree=] the stylesheet lives in,
+	if shadow DOM is involved)
+	regardless of how such relative URLs would resolve elsewhere
+	(ignoring, for example, <{base}> elements
+	changing the base URL,
+	or relative URLs in linked stylesheets
+	resolving against the stylesheet's URL).
 
 	<div class="example">
 		In the following example,
@@ -986,25 +1008,6 @@ Fragment URLs</h5>
 	a ''url()'' with the <a>local url flag</a> set,
 	it must serialize as just the fragment.
 
-	<details class=note>
-		<summary>What “browser eccentricities”?</summary>
-
-		Theoretically, browsers should re-resolve any relative URLs,
-		including fragment-only URLs,
-		whenever the document's base URL changes
-		(such as through mutation of the <{base}> element,
-		or calling {{History/pushState()}}).
-		In many cases they don't, however,
-		and so without special handling,
-		fragment-only URLs will suddenly become cross-document references
-		(pointing at the previous base URL)
-		and break in many of the places they're used.
-
-		Since fragment-only URLs express a clear semantic
-		of wanting to refer to the current document
-		regardless of what its current URL is,
-		this hack preserves the expected behavior at least in these cases.
-	</details>
 
 <h4 id="url-empty">
 Empty URLs</h4>