-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Add <meta name="theme-color"> definition #720
Conversation
used. <span w-nodev>User agents that support such proprietary variants must ignore them if the | ||
document contains a <code>meta</code> element with its <code | ||
data-x="attr-meta-name">name</code> attribute set to the value <code | ||
data-x="meta-theme-color">theme-color</code>, in accordance with the below algorithm.</span></p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems a little weird. Why acknowledge these proprietary variants? Either user agents must ignore them too, or we likely need to support them, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea is to add an explicit normative requirement saying "if you see both theme-color and some other proprietary thing that you implement, please turn off your proprietary-thing handling and use the standard thing instead"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My point is that if such proprietary features are widespread enough for user agents not to remove them, we should perhaps support them here too.
There's not a practice of acknowledging proprietary alternatives. We either expect those to die and then the specification doesn't need to cater to them. Or we expect them to be adopted by everyone, in which case the specification needs to adopt them too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm OK either way, but this is what whatwg/meta-theme-color had, and I think it makes sense. I guess I'll defer to @marcoscaceres?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We either expect those to die and then the specification doesn't need to cater to them. Or we expect them to be adopted by everyone, in which case the specification needs to adopt them too.
I think we should expect them to die until we hear otherwise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(i.e., let's just stay silent on the proprietary things and just use the algorithm given below)
Will take a look Monday. Trying to refocus on standards this year.
|
Do we really want a CSS color, and not an HTML "simple color"? |
Some previous discussion in whatwg/meta-theme-color#1. It seems pretty intentional. |
OK then. Do translucent colors work (in implementations)? |
|
||
<p>This value must be a string that is <span data-x="parsed as a CSS <color> | ||
value">parsable as a CSS <color> value</span> defining a suggested color that user agents | ||
should use to customize the display of the page or of surrounding UI. For example, a browser |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
user interface
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated here, but left as "UI" below. The spec uses "UI" quite a lot.
I tried http://jsbin.com/tutibufiho in mobile Chrome, which has |
OK so should we spec that the alpha component must be set to 1.0 after parsing the color? |
I don't think so. Browsers should be allowed to use the alpha components if it makes sense in the specific piece of UI they're using it for. Chrome is just invoking + <p>When using the theme color in UI, user agents may adjust it in implementation-specific ways
+ to make it more suitable for the UI in question. For example, if a user agent intends to use
+ the theme color as a background and display white text over it, it might use a darker variant of
+ the theme color in that part of the UI, to ensure adequate contrast.</p> |
WFM |
@marcoscaceres do you think you'll have time to review this? Other editors, any other concerns? Should I just remove the mention of the proprietary alternatives, I guess? |
I would prefer that, unless there's precedent somewhere. |
Yes. I think I also disagree with the suggested requirement for proprietary ones; if the standard keyword is supported but has some bug, it can be useful to be able to override it with a proprietary meta. (Though it's better to only support the standard one and have shared tests to avoid bugs.) |
OK, removed that paragraph, rebased and squashed. |
LGTM. |
Will wait for @zcorpan's sign off as well. |
<dd> | ||
|
||
<p>This value must be a string that is <span data-x="parsed as a CSS <color> | ||
value">parsable as a CSS <color> value</span> defining a suggested color that user agents |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This confuses authoring conformance and UA conformance. You want to say that the value must match the CSS <color> production, and separately user agents must parse it as a CSS <color> value.
@zcorpan added a new commit addressing your comments except the "UI" one. PTAL. |
LGTM. |
Fixes https://www.w3.org/Bugs/Public/show_bug.cgi?id=28623. Maybe @marcoscaceres wants to help review? He might be too busy though based on the comments in that bug.