1170774 - [meta] Implement some non-standard APIs for web compatibility

Status: RESOLVED FIXED

(Core :: General, defect)

Description

[Mike Taylor [:miketaylr]]

In order to be more compatible with the (mobile) web we should implement the most important WebKit prefixed APIs and CSS properties (enabled by default). The list of APIs implemented in the latest build of Microsoft Edge can serve as a guide for what is important. See:

<https://docs.google.com/spreadsheets/d/173d1p3LkW_LWk-VMnrxGPhTobtKSpED30Fys5ZJLttA/edit#gid=51341101>

Implementation here may be defined as a new feature implemented, a mapping to an existing feature, or something similar to our CSS Unprefixing service (sans whitelist).

Comment 1

[Masatoshi Kimura [:emk]]

I think it's time to define the WebKit-prefix Living Standard, just like mimesniff and quirksmode living standards. We should not pretend the prefix will go away from the Web. Given that Chrome will no longer add a new prefix, the prefix list will be fixed and finite.

Comment 2

[Mike Taylor [:miketaylr]]

(In reply to Masatoshi Kimura [:emk] from comment #1)
> I think it's time to define the WebKit-prefix Living Standard, just like
> mimesniff and quirksmode living standards. We should not pretend the prefix
> will go away from the Web. Given that Chrome will no longer add a new
> prefix, the prefix list will be fixed and finite.

FWIW, I agree.

Comment 3

[Masatoshi Kimura [:emk]]

Anne, how to propose a new Living Standard document?

Comment 4

[Anne (:annevk)]

1. Write a standard using Bikeshed.
2. Give me a desired GitHub repository name and some GitHub usernames that require access.
3. Email Ian and I for setting up the {name}.spec.whatwg.org domain name (ideally matches the GitHub repository name) and some commit hooks (and indicate how much of this you want to manage, easiest is to let me manage the domain and the commit hooks).
4. Attach a Twitter account to your repository.
5. Design a nice logo in SVG and use it.
6. Get back to maintaining that standard.

You can flip 1/2.

Comment 5

[Karl Dubost💡 :karlcow]

Adding Bug 823483 Shrink to fit doesn't work on Gecko the same way that it does in other browsers, which creates regular Web Compat issues.

Comment 6

[Karl Dubost💡 :karlcow]

Adding Bug 550426, this is now part of the CSS spec, but not implemented yet.
background-position-x
background-position-y

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Mike Taylor [:miketaylr] from comment #0)
> Implementation here may be defined as a new feature implemented, a mapping
> to an existing feature, or something similar to our CSS Unprefixing service
> (sans whitelist).

Tentative possible strategy, to avoid causing too much of a perf hit here:
 (1) For prefixed properties where we don't need to mess with the value (currently called "propertiesThatAreJustAliases"[1], use a version of dbaron's patches on bug 837211 to support. Properties currently in that group are listed here, and include "-webkit-background-size" & "-webkit-box-sizing":
http://mxr.mozilla.org/mozilla-central/source/layout/style/CSSUnprefixingService.js?rev=39c35b0c2e04#39

 (2) For the remaining prefixed properties where we need to swap out keywords or do more complex string-replacement, we could still call out to the CSSUnprefixingService, but before doing so, check the property-name against a C++ array of nsIAtoms for the unprefixable properties.  This would save us from useless roundtrips through the service for unsupported properties.  (I'm assuming atom-table lookups are cheaper than calling out to JS, too; seems likely, but if they aren't, this wouldn't be worthwhile as a filter.)

Comment 8

[Mike Taylor [:miketaylr]]

(In reply to Daniel Holbert [:dholbert] from comment #7) 
> Tentative possible strategy, to avoid causing too much of a perf hit here:

IIRC from our discussion, dbaron's patches from (1) will cover DOM element style/CSSOM aliases, right?

Would that also be possible somehow via (2)?

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to Mike Taylor [:miketaylr] from comment #8)
> IIRC from our discussion, dbaron's patches from (1) will cover DOM element
> style/CSSOM aliases, right?

That matches my recollection (modulo case sensitivity issues; IIRC webkit is oddly permissive, or something).

> Would that also be possible somehow via (2)?

Not directly; it would require additional machinery to make any CSSUnprefixingService-backed properties available via the DOM (for e.g. elem.style.webkitBoxFlex = "1")

Comment 10

[Mike Taylor [:miketaylr]]

(In reply to Daniel Holbert [:dholbert] from comment #9)
> (In reply to Mike Taylor [:miketaylr] from comment #8)
> > IIRC from our discussion, dbaron's patches from (1) will cover DOM element
> > style/CSSOM aliases, right?
> 
> That matches my recollection (modulo case sensitivity issues; IIRC webkit is
> oddly permissive, or something).

Cool. Case sensitivity is on my "investigation/spec" TODO list for Q3.

> > Would that also be possible somehow via (2)?
> 
> Not directly; it would require additional machinery to make any
> CSSUnprefixingService-backed properties available via the DOM (for e.g.
> elem.style.webkitBoxFlex = "1")

OK, we'll keep our eye out for bugs related to that to see how important it will be. My gut feeling is that we'll eventually want that.

Comment 11

[Mike Taylor [:miketaylr]]

Here's a wiki page where the webcompat team has ordered the importance of the work (roughly), as we see it. 

https://wiki.mozilla.org/Compatibility/Mobile/Non_Standard_Compatibility (also linked from URL).

Comment 12

[Mike Taylor [:miketaylr]]

I think we can close this now, thanks to everyone for their hard work!