Skip to content
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

[css-conditional-3] [css-fonts-4] Allow CSS.supports('font-family: system-ui') for feature detection #590

Closed
foolip opened this issue Oct 11, 2016 · 4 comments

Comments

@foolip
Copy link
Member

foolip commented Oct 11, 2016

https://drafts.csswg.org/css-conditional-3/#the-css-interface
https://drafts.csswg.org/css-fonts-4/#extended-generics

Context: blink-dev Intent to Implement and Ship: The “system-ui” generic font family where I wonder "Would there really be any privacy concern in allowing support for an alias like this to be detected? It seems about as harmless as CSS.supports('font-family: sans-serif')."

I couldn't actually find which specs makes it currently not work, help @kojiishi?

It seems like a good idea to support this for all generic font families, to disable any code that might be making guesses based on other information.

@upsuper
Copy link
Member

upsuper commented Oct 11, 2016

I don't think using 'font-family: system-ui' works here, because simply wrapping it with parens '(font-family: system-ui)' makes it pass on all browsers. We may need a function syntax for this kind of thing.

@kojiishi
Copy link
Contributor

Spec-wise, CSS.supports defines:

value would be successfully parsed as a supported value for that property

and system-ui is a valid font_family_name, so it should return true.

A function syntax as suggested by @upsuper might work, but probably the first thing to discuss is what are the cases where cascading font_family_name_list cannot solve but CSS.supports can. Do you have any examples in mind?

@foolip
Copy link
Member Author

foolip commented Nov 9, 2016

My assumption was that implementations that don't support this also don't parse it successfully, but apparently that's not the case.

I'm OK with closing this if nobody has good ideas.

@litherum
Copy link
Contributor

litherum commented Mar 8, 2017

It appears that nobody has any good ideas.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants