-
Notifications
You must be signed in to change notification settings - Fork 707
[css-conditional-3] define whether/how it matters if namespace prefixes are declared #3220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
And I'd note that one of the relevant pieces here is that the CSS Qualified Names section of namespaces says:
|
Thanks for filing, was on my list of things to do :) As I said in the linked issue, I'd argue for keeping the consistency with existing APIs in regards of treating undeclared namespaces as invalid. For example, right now This is both more consistent (IMO) and easier to implement / less special-casey. |
(Do the same as in "treat it as invalid", not as in throwing :)) |
In the discussion just minuted in #3207, we resolved not to take the option of "namespaces are all invalid", but didn't yet choose between "all valid" and "use the namespace map". |
Minutes of the earlier discussion: https://lists.w3.org/Archives/Public/www-style/2018Dec/0004.html |
Well, we need to pick one of those :) |
@emilio, any opinions? |
I'd prefer the "valid when declared" option. Still less special-casey. |
The CSS Working Group just discussed
The full IRC log of that discussion<gregwhitworth> Topic: define whether/how it matters if namespace prefixes are declared<astearns> github: https://github.com//issues/3220 <TabAtkins> @supports (content: attr(n|href)) { <TabAtkins> } <gregwhitworth> TabAtkins: things that take a namespace value, such as the attr function <gregwhitworth> TabAtkins: in this case if the n namespace is not declared should this supports declaration valid or not <gregwhitworth> TabAtkins: emilio_ had an opinion 14 mins ago <gregwhitworth> TabAtkins: only consider it valid when the namespace has been declared <gregwhitworth> TabAtkins: I don't like namespaces so I don't care <chris> ok someone else take this, I will rejoin <TabAtkins> document.querySelector("a|b") <gregwhitworth> TabAtkins: emilio_ also pointed out ^ (example) does check the namespace map <fantasai> chris points out it's a corner case <gregwhitworth> TabAtkins: thus we should probably stay consistent with APIs that care about namepaces <gregwhitworth> TabAtkins: it shouldn't matter, as chris said it's a corner case <gregwhitworth> fremy: one thing - you have to re-verify the at-supports <gregwhitworth> fantasai: no - that's not true, namespaces are per file <gregwhitworth> fremy: how does that work in queryselector? <fantasai> https://www.w3.org/TR/css-namespaces/#scope <gregwhitworth> rune: yeah I don't get how query selector will work <emilio_> It does _not_ check the ns map, there's no ns map to check <gregwhitworth> TabAtkins: at-supports should query the stylesheets namespace value <emilio_> But yeah @supports could <gregwhitworth> TabAtkins: so, I'm fine with emilio_ opinion <gregwhitworth> fantasai: I'm in favor of what's easy to implement as well <TabAtkins> proposed resolution: the CSS.supports() function considers all namespaces invalid (like .querySelector() does), the @supports rule consults the stylesheet's namespace map <gregwhitworth> chris: I just want it defined <gregwhitworth> astearns: any objections <gregwhitworth> the CSS.supports() function considers all namespaces invalid (like .querySelector() does), the @supports rule consults the stylesheet's namespace map <gregwhitworth> RESOLVED: the CSS.supports() function considers all namespaces invalid (like .querySelector() does), the @supports rule consults the stylesheet's namespace map |
One issue that came up in #3207 (noticed by @heycam while reviewing code from @emilio) is that the spec should define to what extent namespace prefixes are required to be declared. In particular, how do:
depend on whether the namespace prefix
n
has been declared? Do they:The text was updated successfully, but these errors were encountered: