Closed Bug 1181624 Opened 9 years ago Closed 9 years ago

Make any CSSUnprefixingService-backed properties available via the DOM

Categories

(Core :: DOM: CSS Object Model, defect)

Product:
Core
Component:
DOM: CSS Object Model
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: miketaylr, Unassigned)

References

Details

Right now the CSS Unprefixing Service will rewrite "-webkit-box-flex: 1" to "flex: 1", but only at the Stylesheet level.

We will also need the ability to understand elem.style.webkitBoxFlex = "1", and similar for properties handled via the Unprefixing service.

(Maybe this fits better in DOM: CSSOM? Please move if so.)
Blocks: 1170774
cf. https://github.com/webcompat/web-bugs/issues/1333#issuecomment-119581968, where Google uses inline webkitTransform on their Tier 1 gmail to slide in emails.
Actually, bad example--webkitTransform would be handled by Bug 837211. I have a Google bug somewhere that depends on elm.style.webkitBoxFlex, will link when I find it.
I'd like to understand a bit more about the desired behavior here.

The CSS unprefixing service does unprefixing on a per-site basis.  Are we aiming for per-site support for elem.style.webkit*?  Or just wholesale support on all sites?

Also, are we only talking about properties that are strict aliases, or ones that need syntax rewriting?

Lastly, how much do we care about the performance of these setters?
Component: CSS Parsing and Computation → DOM: CSS Object Model
> The CSS unprefixing service does unprefixing on a per-site basis.  Are we aiming for per-site support for elem.style.webkit*?  Or just wholesale support on all sites?

The idea is to aim for wholesale support everywhere (see Bug 1177263). Sort of scary, but our initial tests on top US 250 sites show this hasn't broken anything (yet). This is also what Edge does.

> Also, are we only talking about properties that are strict aliases, or ones that need syntax rewriting?

This bug would cover the ones that require syntax rewriting. The idea is that strict aliases would not be handled with the Unprefixing service.

> Lastly, how much do we care about the performance of these setters?

A lot. I don't think anybody wants to trade perf for compat. :)

dholbert started to do some profiling of the unprefixing service rewriting stuff, but it's unclear (to me) right now how aliased setters impact performance.
> The idea is to aim for wholesale support everywhere

OK, that makes things a bit simpler.

> A lot.

And that makes it more complicated.  A naive implementation would just have us install some setters from chrome JS that call into the unprefixing service rewriter and then call the underlying built-in property setter.  But that sounds pretty expensive to me...
This happens automatically if we use our normal aliasing mechanism rather than the unprefixing service.  If we're talking about making these aliases available globally, we should take that path instead.
Let me be clearer:  we will not expose the unprefixing service in its current state (or anything close to it) to all sites.  Most of the things in it can and should be done in better ways in order to expose them everywhere.

It's likely to be less confusing if you file bugs about the behaviors that are needed rather than particular technical solutions for them.
> Let me be clearer:  we will not expose the unprefixing service in its current state (or anything close to it) to all sites. Most of the things in it can and should be done in better ways in order to expose them everywhere.

See <https://groups.google.com/d/msg/mozilla.compatibility/_Xevs-KENpw/Krww3eJXS9AJ>. Specifically the part, "It looks like we have consensus to fix bug 1177263 in Q3 and announce an intent to implement."

See also https://bugzilla.mozilla.org/show_bug.cgi?id=1170774#c7.

This bug isn't about "most of the things", i.e. aliasing. This bug is about the things that require rewriting via the unprefixing service (flexbox + gradients). If it turns out we use something else for that, great--we can update the title of this bug.


> It's likely to be less confusing if you file bugs about the behaviors that are needed rather than particular technical solutions for them.

The behavior that is needed is to make properties that have been rewritten available via the DOM. That happens today via the CSS unprefixing service.
See Also: → 1177263
(In reply to Mike Taylor [:miketaylr] from comment #8)
> This bug isn't about "most of the things", i.e. aliasing. This bug is about
> the things that require rewriting via the unprefixing service (flexbox +
> gradients).

Two things:
(1) The "webkit-box-flex" property (along with all other "propertiesThatAreJustAliases" in CSSUnprefixingService.js) can just be handled natively as an alias, which means comment 0 should Just Work. (If we need to support DOM accessors for any of the "propertiesThatNeedKeywordMapping" in CSSUnprefixingService.js, that may be trickier. Do you know that we need any of those?)

(2) I'd expect gradients to already Just Work in DOM accessors, since the gradient is just part of the value of an already-supported-in-the-DOM property.  (e.g. "background" vs "elem.style.background")  We don't need to expose any new DOM accessors there.
(In reply to Mike Taylor [:miketaylr] from comment #8)
> > Let me be clearer:  we will not expose the unprefixing service in its current state (or anything close to it) to all sites. Most of the things in it can and should be done in better ways in order to expose them everywhere.
> 
> See
> <https://groups.google.com/d/msg/mozilla.compatibility/_Xevs-KENpw/
> Krww3eJXS9AJ>. Specifically the part, "It looks like we have consensus to
> fix bug 1177263 in Q3 and announce an intent to implement."

The summary of that bug is a bit misleading, I think this is better:

> See also https://bugzilla.mozilla.org/show_bug.cgi?id=1170774#c7.

Agree on that as the plan.

> This bug isn't about "most of the things", i.e. aliasing. This bug is about
> the things that require rewriting via the unprefixing service (flexbox +
> gradients). If it turns out we use something else for that, great--we can
> update the title of this bug.

OK.  I missed that implication.  (It's not clear to me how the rewrite in comment 0 couldn't be an alias... but maybe there's something else about -webkit-box-flex that I'm missing.)

However, I think this particular technical solution you want here may be a lot of work.

The alternative is that if you find cases that are (after the plan above) in the unprefixing service that require DOM properties for adequate compatibility, we should consider the solution of moving the things that require it for compatibility out of the unprefixing service into C++ code, as a shorthand.

For stuff that we want to expose to the Web and spec, I think that has to be the long term plan anyway, since that's the probably only way we're actually going to match a spec that other browsers are also willing to match.
Yes, propertiesThatAreJustAliases shouldn't need any extra support (beyond being aliased natively). I've picked a bad example in Comment 0. Sorry to create unnecessary confusion. (It all made sense in my head I swear.)

(In reply to Daniel Holbert [:dholbert] from comment #9)
> (If we need to support DOM accessors for any of the "propertiesThatNeedKeywordMapping" in CSSUnprefixingService.js, that may be trickier. Do you know that we need any of those?)

The one example I found eludes me right now (I swear it was in mobile Gmail).

It's not impossible to find a few examples on GitHub, but that doesn't mean this exists in the wild in a way that makes it required:

https://github.com/vi-works/danmu/blob/e72d697877f960d04a7fd45ca25dec12057e7959/static/view.js#L167

(In reply to David Baron [:dbaron] ⏰UTC-7 (busy until July 20) from comment #10)
> The alternative is that if you find cases that are (after the plan above) in the unprefixing service that require DOM properties for adequate compatibility, we should consider the solution of moving the things that require it for compatibility out of the unprefixing service into C++ code, as a shorthand.

SGTM. The actual technical solution is less important to me.

As far as this bug goes, I think the webcompat team needs to better justify it with actual broken sites. I'm going to update <https://wiki.mozilla.org/Compatibility/Mobile/Non_Standard_Compatibility> and put this bug in a "Low Priority" section until we have more evidence.
Given that we're not going to be shipping webkit prefixed CSS support via the existing unprefixing service, I don't think we need this bug anymore. 

The original intent was that we should support webkit prefixed CSS via CSSOM, and when we ship native support we get that.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.