search

w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.5k stars 661 forks source link

[css-size-adjust] specify -webkit-text-size-adjust as alias of text-size-adjust #237

Open RByers opened 8 years ago

RByers commented 8 years ago

Only the text-size-adjust property is specified. The compat spec requires -webkit-text-size-adjust to be an alias. According to HTTPArchive data this has become a defacto standard and is required for web compat :-(. Chrome is about to ship it (prefixed and unprefixed). Can we just move the alias requirement from the compat spec to the proper home in the css-size-adjust spec?

/cc @miketaylr @tantek

miketaylr commented 8 years ago

SGTM, just let me know when to remove the alias from the compat spec.

plinss commented 8 years ago

I strongly object to adding vendor prefixed properties and values to core CSS specs. That's what the compat spec is for, please just leave them there.

frivoal commented 8 years ago

We've been over this multiple time, so I know you don't like it, but the reason in favor it such things is always the same. If the web platform depends on something, regardless of how ugly its name is, we're stuck with it. Bad names that we can remove should be, but if the web depends on it enough that browsers feel they must add it / cannot remove it, then it doesn't help anyone to pretend it's not part of the platform. The web has its fair share of warts. Some bad names come from haphazard naming back when it was invented, and some come from our unfortunate history with prefixes. Regardless, if we're stuck with them, we're stuck with them.

We've already decided for other properties to include in the canonical spec the ugly prefixed de-facto name, and I think we should stay consistent with that.

SebastianZ commented 8 years ago

We've already decided for other properties to include in the canonical spec the ugly prefixed de-facto name, and I think we should stay consistent with that.

I didn't see prefixed properties in the canonical specs so far. And even when some prefixed properties are the de-facto standard, they should not be promoted by putting them in the canonical specs. The Text Size Adjustment Module may refer to the compat spec., though.

Sebastian

plinss commented 8 years ago

The only instance of a webkit property name (outside of examples) I see is user-select in the ED of UI-4, and that was only added less than two months ago. Given the number of webkit prefixes in the compat spec, I think the consistency argument favors keeping them out of CSS specs, and I'll argue that one should be removed as well (and added back to the compat spec).

I understand the unfortunate platform dependency, and agree that those prefixed items that have become problematical in the wild should be documented and standardized for web compatibility, but that's what the compat spec is for (modularity FTW).

Yes, we have to live with them (for now at least), but we don't want to spread the disease. The last thing we want to do is encourage authors to use them (both of the authors that actually read our specs), or give any kind of signal that someone implementing a CSS engine that doesn't necessarily care about web compat (like, say an ePub reader or offline formatting engine) should implement these things. What's next, adding conformance tests for -webkit- properties?

bradkemper commented 8 years ago

I'm for just having a note at the bottom of each spec saying something like "the following properties defined in this spec have prefixed equivalents listed in the comparability specification." And then list them and link to it.

miketaylr commented 8 years ago

What's next, adding conformance tests for -webkit- properties?

Yeah, why not. We have a few now: https://github.com/w3c/web-platform-tests/tree/master/compat

plinss commented 8 years ago

Sure, when testing for compat against the compat spec, but do we want implementation of vendor prefixed properties to be a CR exit requirement for the CSS specs? I certainly don't.

frivoal commented 8 years ago

do we want implementation of vendor prefixed properties to be a CR exit requirement for the CSS specs? I certainly don't.

I don't think the standards group (whether the CSSWG or the WHATWG) should spec prefixed properties that the browser vendors have not already decided to support. Specifying prefixed things only makes sense if the web actually depends on them, and I believe browser vendors are best placed to call that. But once they have decided to implement it because the web does depend on it, it won't hold up a spec in CR, since they are implemented.

If there isn't yet a consensus between browser vendors that they need to support this, I think we should hold off having it in the spec. If there is, it shouldn't slow down anything.

miketaylr commented 8 years ago

The only instance of a webkit property name (outside of examples) I see is user-select in the ED of UI-4, and that was only added less than two months ago.

See also:

(I guess the last isn't CSS, ¯_(ツ)_/¯ )

upsuper commented 8 years ago

FWIW, there are people who consider a property to be stable and guaranteed only if it is in CSS spec.

I had a discussion with developer of hail2u/vim-css3-syntax, and they refused to add webkit-prefixed properties to the syntax file because they think there is no guarantee that those properties are stable, and would only be happy to add if the properties appear in CSS specs.

tabatkins commented 8 years ago

This topic has drifted considerably from the actual question in the OP. I've opened #247 to deal with the "where should we spec prefixed properties?" discussion directly, please move further discussion to that.