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

Add <meta name="theme-color"> definition #720

Merged
merged 1 commit into from Mar 1, 2016
Merged

Add <meta name="theme-color"> definition #720

merged 1 commit into from Mar 1, 2016

Conversation

domenic
Copy link
Member

@domenic domenic commented Feb 20, 2016

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.

@domenic domenic added the addition/proposal New features or enhancements label Feb 20, 2016
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>
Copy link
Member

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?

Copy link
Member Author

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"

Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member

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.

Copy link
Member

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)

@marcoscaceres
Copy link
Member

Will take a look Monday. Trying to refocus on standards this year.

On 20 Feb 2016, at 11:03 AM, Domenic Denicola notifications@github.com wrote:

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.

You can view, comment on, or merge this pull request online at:

#720

Commit Summary

Add definition
File Changes

M source (84)
Patch Links:

https://github.com/whatwg/html/pull/720.patch
https://github.com/whatwg/html/pull/720.diff

Reply to this email directly or view it on GitHub.

@zcorpan
Copy link
Member

zcorpan commented Feb 24, 2016

Do we really want a CSS color, and not an HTML "simple color"?

@domenic
Copy link
Member Author

domenic commented Feb 24, 2016

Some previous discussion in whatwg/meta-theme-color#1. It seems pretty intentional.

@zcorpan
Copy link
Member

zcorpan commented Feb 24, 2016

OK then. Do translucent colors work (in implementations)?


<p>This value must be a string that is <span data-x="parsed as a CSS &lt;color&gt;
value">parsable as a CSS &lt;color&gt; 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

user interface

Copy link
Member Author

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.

@domenic
Copy link
Member Author

domenic commented Feb 24, 2016

OK then. Do translucent colors work (in implementations)?

I tried http://jsbin.com/tutibufiho in mobile Chrome, which has rgba(0, 255, 0, 0.5), which appears to treat it as rgba(0, 255, 0).

@zcorpan
Copy link
Member

zcorpan commented Feb 25, 2016

OK so should we spec that the alpha component must be set to 1.0 after parsing the color?

@domenic
Copy link
Member Author

domenic commented Feb 25, 2016

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>

@zcorpan
Copy link
Member

zcorpan commented Feb 25, 2016

WFM

@domenic
Copy link
Member Author

domenic commented Feb 26, 2016

@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?

@annevk
Copy link
Member

annevk commented Feb 27, 2016

I would prefer that, unless there's precedent somewhere.

@zcorpan
Copy link
Member

zcorpan commented Feb 29, 2016

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.)

@domenic
Copy link
Member Author

domenic commented Feb 29, 2016

OK, removed that paragraph, rebased and squashed.

@domenic domenic removed their assignment Feb 29, 2016
@annevk
Copy link
Member

annevk commented Feb 29, 2016

LGTM.

@domenic
Copy link
Member Author

domenic commented Feb 29, 2016

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 &lt;color&gt;
value">parsable as a CSS &lt;color&gt; value</span> defining a suggested color that user agents
Copy link
Member

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.

@domenic
Copy link
Member Author

domenic commented Mar 1, 2016

@zcorpan added a new commit addressing your comments except the "UI" one. PTAL.

@domenic domenic assigned zcorpan and unassigned domenic Mar 1, 2016
@zcorpan
Copy link
Member

zcorpan commented Mar 1, 2016

LGTM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements
Development

Successfully merging this pull request may close these issues.

None yet

6 participants