[css-navigation-1] Add partial work-in-progress draft of spec for CSS side.

(This is part of importing the history from WICG/declarative-partial-updates.)

Author: dbaron

css-navigation-1/Overview.bs

@@ -0,0 +1,140 @@
+<pre class="metadata">
+Title: CSS Route Matching
+Status: UD
+Work Status: Exploring
+Shortname: css-route-matching
+Org: w3c
+Level: 1
+Repository: WICG/declarative-route-matching
+!Issue Tracking: <a href="https://github.com/w3c/csswg-drafts/issues/12594">w3c/csswg-drafts#12594</a>
+ED: https://wicg.github.io/declarative-partial-updates/css-route-matching.html
+Editor: L. David Baron, Google https://www.google.com/, https://dbaron.org/, w3cid 15393
+Editor: Noam Rosenthal, Google https://www.google.com/, w3cid 121539
+Abstract: This module contains conditional CSS rules for styling based on routes
+        declared in HTML.  This allows styles to be conditioned on the current URL
+        or conditioned on the status of navigating between particular URLs.
+</pre>
+<!-- for now using Org: w3c rather than Group: csswg because the latter forces an incorrect issue tracking link, overriding Repository -->
+
+<h2 id="at-route">Route queries: the ''@route'' rule</h2>
+
+The <dfn at-rule id="at-ruledef-route">@route</dfn> rule
+is a conditional group rule
+whose condition tests
+characteristics of the current URL
+or of the state of navigation between two URLs.
+These queries are called <dfn export>route queries</dfn>.
+
+Authors can use it to:
+* write style sheets that apply to multiple pages
+	but behave somewhat differently between those pages,
+* write style sheets that apply to
+	single page applications
+	that change their URL over time,
+	so that style changes when the URL changes, and
+* write style sheets that declaratively start view transitions
+	(or make other appropriate style changes)
+	in response to navigations.
+
+The syntax of the condition in the ''@route'' rule
+is similar to that defined for
+<<supports-condition>> in [[CSS-CONDITIONAL-3]].
+Negation, conjunction, and disjunction are all needed
+so that authors can specify the interaction of multiple styles
+in ways that are most intuitive and require the simplest code.
+
+The syntax of the ''@route'' rule is:
+
+<pre class="prod def" nohighlight>
+@route <<route-condition>> {
+	<<rule-list>>
+}
+</pre>
+
+with <<route-condition>> defined as:
+
+<pre class="prod def" dfn-type="type" nohighlight>
+	<dfn><<route-condition>></dfn> = not <<route-in-parens>>
+	                     | <<route-in-parens>> [ and <<route-in-parens>> ]*
+	                     | <<route-in-parens>> [ or <<route-in-parens>> ]*
+	<dfn><<route-in-parens>></dfn> = ( <<route-condition>> ) | ( <<route-test>> ) | <<general-enclosed>>
+	<dfn><<route-test>></dfn> = <<route-name>> | <<route-keyword>> : <<route-name>>
+	<dfn><<route-keyword>></dfn> = at | to | from
+	<!-- TODO(dbaron): Should this be <<ident>> or <<custom-ident>> ? -->
+	<dfn><<route-name>></dfn> = <<custom-ident>>
+</pre>
+
+The above grammar is purposely very loose for forwards-compatibility reasons,
+since the <<general-enclosed>> production
+allows for substantial future extensibility.
+Any ''@route'' rule that does not parse according to the grammar above
+(that is, a rule that does not match this loose grammar
+which includes the <<general-enclosed>> production)
+is invalid.
+Style sheets <strong>must not</strong> use such a rule and
+processors <strong>must</strong> ignore such a rule (including all of its contents).
+
+A <<route-name>> is a reference to a route
+named in a <code highlight=html>&lt;script type=routemap></code>
+in the document.
+<span class="issue">This should be defined more formally once routemaps are.</span>
+
+Many of these grammar terms are associated with a boolean result,
+as follows:
+
+: <<route-condition>>
+::	: not <<route-in-parens>>
+	:: The result is the negation of the <<route-in-parens>> term.
+
+	: <<route-in-parens>> [ and <<route-in-parens>> ]*
+	::
+		The result is true if all of the <<route-in-parens>> child terms are true,
+		and false otherwise.
+
+	: <<route-in-parens>> [ or <<route-in-parens>> ]*
+	::
+		The result is false if all of the <<route-in-parens>> child terms are false,
+		and true otherwise.
+
+: <<route-in-parens>>
+:: The result is the result of the child subexpression.
+
+: <<route-test>>
+::	: <<route-name>>
+	: at: <<route-name>>
+	:: The result is true if
+		the document's [=Document/URL=] [=URL pattern/match|matches=]
+		the URL pattern of a route named <<route-name>>
+		declared in a <code highlight=html>&lt;script type=routemap></code>.
+
+	: to: <<route-name>>
+	:: The result is true if
+		the document's [=node navigable=]'s
+		@@@ @@@ <span class="issue">define this properly</span>
+		[=URL pattern/match|matches=]
+		the URL pattern of a route named <<route-name>>
+		declared in a <code highlight=html>&lt;script type=routemap></code>.
+
+	: from: <<route-name>>
+	:: The result is true if
+		the document's [=node navigable=]'s
+		@@@ @@@ <span class="issue">define this properly</span>
+		[=URL pattern/match|matches=]
+		the URL pattern of a route named <<route-name>>
+		declared in a <code highlight=html>&lt;script type=routemap></code>.
+
+	ISSUE: Once routemaps are defined more formally,
+	this should be defined in terms of the routemap definition
+	instead of referring directly to URLPattern.
+
+: <<general-enclosed>>
+::
+	The result is false.
+
+	Authors must not use <<general-enclosed>> in their stylesheets.
+	<span class='note'>It exists only for future-compatibility,
+	so that new syntax additions do not invalidate too much of a <<route-condition>> in older user agents.</span>
+
+The condition of the ''@route'' rule
+is the result of the <<route-condition>> in its prelude.
+