- From: fantasai <notifications@github.com>
- Date: Mon, 26 Mar 2018 06:34:05 +0000 (UTC)
- To: whatwg/url <url@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/url/issues/375/376060592@github.com>
@annevk within the URL spec, I'd expect using the first formulation (hence the local-lt), but outside of it I think writing the second one makes it clear you're talking about a URL fragment and not something else. Similar reason to why in the grid spec I might use grid terms without “grid” written in front of them, but I export them with “grid” included, e.g. “grid track” or “grid row”--even if another spec (like css-align) is in a paragraph very clearly about grids, since it's not all about grids, it's clearer (and not painfully redundant, as it would be in the grid spec) to use “grid row” instead of just “row”... If in a particular sentence I want to use just “row” (since I already listed, e.g. “grid column” earlier in the sentence), I can use `lt=` to shorten it. @tabatkins If the new plan is to have every instance of a cross-linked term in every CSS spec explicitly namespaced to CSS, lmk and I'll set aside some time to write a preprocessor for your preprocessor. :) That way we'll have a cross-module concept of local terms for the full set of CSS specs, which is another way of solving the immediate problem here. I still think making the «URL» “namespace” explicit in the term, rather than hiding it as metadata, would be an improvement to the set of exported terms here, though. It may be possible to namespace prose terms with Bikeshed, but relying on that is not imho as straightforward as relying on property-value/interface-method/element-attribute relationships--which, unlike hidden Bikeshed namespaces, are self-evident to the reader as well as inherent to the spec regardless of tooling. It's not just “fragment” (which happens to be what brought me here): “username” and “password” are very generic concepts that I don't think should be representing such a specific, localized concept in the global pool of exported vocabulary if we can so easily avoid it by localizing it. (Ditto “parse”, but I'll file that in the CSSWG repo.) It helps both reduce tooling conflicts and encourage precision in wording (which helps the reader, who no longer needs to click through as often) to export terms that are more specific. In cases where the specificity is awkward, the editor of the incoming reference can always modulate it with `lt`, but it means the default cross-spec linking text is more specific. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/url/issues/375#issuecomment-376060592
Received on Monday, 26 March 2018 06:34:35 UTC