Intent to implement and ship: Document.scrollingElement

361 views
Skip to first unread message

Rick Byers

unread,
Apr 9, 2015, 10:21:07 AM4/9/15
to blink-dev

Contact emails

rby...@chromium.org


Spec

http://dev.w3.org/csswg/cssom-view/#dom-document-scrollingelement

Tag review: not necessary, this is a trivial addition


Summary

Adds a simple 'scrollingElement' property on Document which returns either document.body or document.htmlElement depending on which element can currently be used to scroll the viewport.


Motivation

The spec for the Element scrolling APIs (eg. scrollTop) is non-trivial when it comes to body vs. htmlElement due to legacy reasons. WebKit and Blink still don't implement the spec properly and unfortunately sites (eg. Facebook) and frameworks (eg. Closure) have come to rely on UA checks to expect the WebKit behavior. There isn't a great replacement for such UA checks to enable developers to reliably choose between using body or scrollTop for scrolling (the typically advocated approaches tend to be broken in some scenarios).


This API provides a simple way for the browser to tell the web page which element is used for scrolling the viewport, making it trivial to update existing code. Tactically I feel this is essential to ease the migration to spec-compliant behavior in blink. But even long term this is still somewhat useful since the spec-compliant behavior is non-trivial (depends on quirks mode).


Compatibility Risk

Low. This is a tiny feature with just a little extra surface area. It's almost certainly going to lead to improved compatibility. That said it's a brand new API (I just thought to suggest spec'ing it yesterday), so there's still some chance other vendors will object somehow. To avoid making the scroll interop problem even worse (eg. the latest Spartan builds copy our bug), I still think we should ship this API immediately. If (in the unlikely event) the spec looks like it might change before we hit stable, I'll pull it out.


Ongoing technical constraints

None


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


OWP launch tracking bug?

http://crbug.com/475531


Link to entry on the feature dashboard

I created one feature for the bigger picture issue: Interopable body/documentElement scroll behavior


Requesting approval to ship?

Yes


Mathias Bynens

unread,
Apr 10, 2015, 5:40:13 AM4/10/15
to Rick Byers, blink-dev
Non-owner LGTM!

Here’s a `document.scrollingElement` polyfill that works in HTML, XML,
and HTML frameset documents, and avoids the common issues with similar
scripts (like returning `<body>` for a non-scrollable document):
https://github.com/mathiasbynens/document.scrollingElement
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+...@chromium.org.

Chris Harrelson

unread,
Apr 10, 2015, 11:48:23 AM4/10/15
to Rick Byers, blink-dev
LGTM to implement, but for shipping I would like to see positive vendor or TAG review. There are 5 weeks until the next branch point, so there should be time for this.

Dimitri Glazkov

unread,
Apr 10, 2015, 11:56:50 AM4/10/15
to Chris Harrelson, Rick Byers, blink-dev
LGTM2.

PhistucK

unread,
Apr 10, 2015, 1:38:36 PM4/10/15
to Chris Harrelson, Rick Byers, blink-dev
Yes, or else it would just become another browser-by-feature detection, or unhelpful. :(


☆PhistucK

Rick Byers

unread,
Apr 14, 2015, 9:36:54 AM4/14/15
to Matt Rakow, Chris Harrelson, blink-dev
Update: the API has landed behind --enable-experimental-web-platform-features

Safari has expressed concerned (added complexity that would ideally be unnecessary) but says they'll implement it if Chrome and Firefox do.
IE team hasn't commented yet.  +Matt Rakow who is the one that was asking me to fix our scrollTop bug :-)

Chris, do you want to wait to hear from the IE team before we ship this?

Matt Rakow

unread,
Apr 14, 2015, 3:57:05 PM4/14/15
to Rick Byers, Chris Harrelson, blink-dev

Sounds reasonable to me :)

Boris Zbarsky

unread,
Apr 14, 2015, 4:23:33 PM4/14/15
to blink-dev
On 4/14/15 9:36 AM, Rick Byers wrote:
> Mozilla says they plan to implement it
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1153322>

Though, as often, the devil is in the details as to what the resulting
behavior should actually be in various edge cases....

-Boris

Rick Byers

unread,
Apr 14, 2015, 4:27:50 PM4/14/15
to blink-dev, Chris Harrelson, Matt Rakow, Simon Pieters
Thanks Matt.

Chris and I talked more offline.

1) First there's the question of whether having BOTH body.scrollTop and documentElement.scrollTop return/set the viewport scroll offset would be more compatible than trying to switch our behavior.  I don't think this idea is worth pursuing.  When I google this problem with Chrome, the 2nd hit I get is our own bug page (from 2009) where there are a number of suggestions like this:

For a compatibility proof solution that doesn't check for the browser like the above 
example, just get the total value of both:
document.documentElement.scrollTop + document.body.scrollTop

This will return the same value on all browsers, as one of the values is the document 
scroll, and the other one will be 0.

Searching GitHub I indeed find a couple examples of people using a pattern like this.  This is anecdotal (and I could do a more extensive compat test), but I think the risk of trying to introduce a new 3rd broken behavior is such that it's not worth going down this path. 

In contrast to the above, I haven't been able to find examples on GitHub of people relying on WebKit UA checks.  Most often the code seems to rely on either the window scrolling APIs (which are fine) or "document.body.scrollTop || document.documentElement.scrollTop" which are also fine with either behavior.

2) There's still some risk we won't be able to change blink to match the spec without unacceptable breakage.  In that case, I believe document.scrollingElement is still the exact API we want.  We could perhaps even update the spec to discourage use of scrollTop/Left on body and documentElement (possibly saying behavior is implementation defined) in favor of scrollingElement.  Arguably, if all browsers implement scrollingElement (as now seems likely), it may not even be worth the pain of trying to fix this longstanding bug!  But I hope that's a path of last resort (momentum will ensure developers continue to be bitten by this until we solve it).

Anyway, given the above I believe we should proceed with shipping scrollingElement.  I'll work to try to identify and update known sites relying on a UA check to prefer scrollingElement.

Separately we can re-discuss when / whether we should try to enable ScrollTopLeftInterop by default.

WDYT?
   Rick 

Matt Rakow

unread,
Apr 14, 2015, 5:10:04 PM4/14/15
to Rick Byers, blink-dev, Chris Harrelson, Simon Pieters

Agreed returning the offset on both elements isn’t a good option, for the reason you mention.

 

Aside from inconsistency with the spec and other implementations, my main objection to the current Webkit/Blink behavior is that it has strange results in cases where both the documentElement and body have non-“visible” overflow.  Consider this example, where the body element is scrolling, the body element is receiving the scroll event, but the body element’s scrollTop remains 0:

http://codepen.io/anon/pen/emqEJw

 

I don’t think there’s an easy solution to that wart without enabling ScrollTopLeftInterop.  A web developer could sort of work around it by watching the boundingClientRect of a dummy element, but that would be pretty hacky.

 

Reporting the offset on the body also means that layout viewport metrics are spread across two elements, which is strange.  The documentElement.clientWidth/Height gives the dimensions of the layout viewport but the body.scrollTop/Left (or scrollingElement.scrollTop/Left) would give its position.  Except in double-non-“visible” cases as noted above.

 

Thanks,

-Matt

Rick Byers

unread,
Apr 14, 2015, 5:22:15 PM4/14/15
to Matt Rakow, blink-dev, Chris Harrelson, Simon Pieters
Thanks for the additional context Matt!

I haven't been focusing on the 'html { overflow: hidden;} body { overflow: scroll; }" case because I assumed that's a pretty crazy site design and unlikely to be much of an issue on real websites.  Are you aware of any real websites with a design like that?  Also you can still use the window scrolling APIs in that case (window.scrollY, scrollTo), right?

Still, I agree with your high level point that the spec'd behavior is the most rational and we should make a serious effort (even if it involves some compat pain for us) to fix this.  I'm optimistic that 'scrollingElement' will be the thing we need to unblock a path to fixing this properly.

Rick

Matt Rakow

unread,
Apr 14, 2015, 5:43:53 PM4/14/15
to Rick Byers, blink-dev, Chris Harrelson, Simon Pieters

We’ve had a couple bugs in the past unique to that construction, so I know the usage is non-zero.  I’m not certain of any top-tier examples offhand though.  The window scrolling APIs don’t work in this case, presumably because they’re targeting the top level scroller.

Simon Pieters

unread,
Apr 15, 2015, 8:27:42 AM4/15/15
to blink-dev, Rick Byers, Chris Harrelson, Matt Rakow
On Tue, 14 Apr 2015 22:27:25 +0200, Rick Byers <rby...@chromium.org> wrote:

> Thanks Matt.
>
> Chris and I talked more offline.
>
> 1) First there's the question of whether having BOTH body.scrollTop and
> documentElement.scrollTop return/set the viewport scroll offset would be
> more compatible than trying to switch our behavior. I don't think this
> idea is worth pursuing.

I agree, it seems bad to break `document.documentElement.scrollTop +
document.body.scrollTop`.

> 2) There's still some risk we won't be able to change blink to match the
> spec without unacceptable breakage. In that case, I believe
> document.scrollingElement is still the exact API we want. We could
> perhaps
> even update the spec to discourage use of scrollTop/Left on body and
> documentElement (possibly saying behavior is implementation defined) in
> favor of scrollingElement. Arguably, if all browsers implement
> scrollingElement (as now seems likely), it may not even be worth the pain
> of trying to fix this longstanding bug!

Naw, I think it is still important to fix, as it enables
independently-scrollable body and people will probably continue to run
into the lack of interop even if scrollingElement exists.

> But I hope that's a path of last
> resort (momentum will ensure developers continue to be bitten by this
> until
> we solve it).
>
> Anyway, given the above I believe we should proceed with shipping
> scrollingElement. I'll work to try to identify and update known sites
> relying on a UA check to prefer scrollingElement.
>
> Separately we can re-discuss when / whether we should try to enable
> ScrollTopLeftInterop by default.
>
> WDYT?
> Rick

I think it's good to ship scrollingElement as it is a step towards fixing
"the scrollTop bug". Fixing it is good for the Web long term although will
probably have some short-term pain. If IE/Spartan end up having to copy
the bug it will be more difficult to fix, so the sooner the better I think.

--
Simon Pieters
Opera Software

Rick Byers

unread,
Apr 15, 2015, 9:31:30 AM4/15/15
to Matt Rakow, blink-dev, Chris Harrelson, Simon Pieters
On Tue, Apr 14, 2015 at 5:43 PM, Matt Rakow <mar...@microsoft.com> wrote:

We’ve had a couple bugs in the past unique to that construction, so I know the usage is non-zero.  I’m not certain of any top-tier examples offhand though. 


Good to know you've hit concrete examples.  Then I do indeed consider this another good reason to work hard at trying to ship ScrollTopLeftInterop mode.
 

The window scrolling APIs don’t work in this case, presumably because they’re targeting the top level scroller.


Right, of course (sorry I was thinking backwards). 

Philip Jägenstedt

unread,
Apr 16, 2015, 7:11:43 AM4/16/15
to Rick Byers, blink-dev
LGTM3 to implement. Alex is making a template for requesting TAG
review, but to speed things along simply opening an issue in
https://github.com/w3ctag/spec-reviews/issues ought to work.

I'm keen to know what is known about the compat problems with aligning
with the spec on documentElement-vs-body issue. The hope is that
adding document.scrollingElement will make it much easier to do
outreach to fix sites that sniff to determine which element to use for
scrolling. Further, the hope is that the outreach will make a big
enough dent in the problematic usage that it would unblock the change
needed in Blink.

I share these hopes, but wonder if there's reason to be optimistic. It
seems that more often than not, there's some bit of code that has been
copied around the Web or ended up in a popular framework that makes
outreach entirely ineffective because the problem is spread uniformly,
as opposed to being concentrated in a few big sites.

If we don't have a good idea about what will break by fixing the
documentElement-vs-body situation, we could try to just make the
change and let it set for a while in the non-stable channels to
collect bug reports and then reverting. If the scope of the problem
seems small enough, might we not simply fix the problem?

Philip

On Thu, Apr 9, 2015 at 4:20 PM, Rick Byers <rby...@chromium.org> wrote:

Simon Pieters

unread,
Apr 16, 2015, 8:50:50 AM4/16/15
to Rick Byers, Philip Jägenstedt, blink-dev
On Thu, 16 Apr 2015 13:11:38 +0200, Philip Jägenstedt <phi...@opera.com>
wrote:

> LGTM3 to implement. Alex is making a template for requesting TAG
> review, but to speed things along simply opening an issue in
> https://github.com/w3ctag/spec-reviews/issues ought to work.

Filed https://github.com/w3ctag/spec-reviews/issues/51

cheers

Rick Byers

unread,
Apr 16, 2015, 11:42:41 AM4/16/15
to Philip Jägenstedt, blink-dev
On Thu, Apr 16, 2015 at 7:11 AM, Philip Jägenstedt <phi...@opera.com> wrote:
LGTM3 to implement. Alex is making a template for requesting TAG
review, but to speed things along simply opening an issue in
https://github.com/w3ctag/spec-reviews/issues ought to work.

I'm keen to know what is known about the compat problems with aligning
with the spec on documentElement-vs-body issue. The hope is that
adding document.scrollingElement will make it much easier to do
outreach to fix sites that sniff to determine which element to use for
scrolling. Further, the hope is that the outreach will make a big
enough dent in the problematic usage that it would unblock the change
needed in Blink.

I share these hopes, but wonder if there's reason to be optimistic. It
seems that more often than not, there's some bit of code that has been
copied around the Web or ended up in a popular framework that makes
outreach entirely ineffective because the problem is spread uniformly,
as opposed to being concentrated in a few big sites.

If we don't have a good idea about what will break by fixing the
documentElement-vs-body situation, we could try to just make the
change and let it set for a while in the non-stable channels to
collect bug reports and then reverting. If the scope of the problem
seems small enough, might we not simply fix the problem?

The various efforts to fix this problem over the past few years have given us some anecdotal data here:

1) In Chrome 32 we had the standards compliant behavior enabled in trunk for 5 days.  Issues were immediately reported with Goolgle News and panoramio.com.

2) Between Chrome 33 and 41 we had the spec compliant behavior behind an 'experimental' web platform feature.  Due to the (small but far from non-zero) usage of the --enable-experimental-web-platform-features flag we got (AFAIK) reports of issues in three places during that time: Google+ (now fixed), Facebook (fix in progress), and the Closure framework (fix blocked on scrollingElement).  Given that we got about ~40 reports on the Facebook bug about this, it seems reasonable to expect that we would have heard more complaints on other sides if the issue was extremely widespread.  That said, we still have very little visibility into the torso and tail tail here.

3) We know that other popular frameworks (like jQuery) have long been designed to address the issue without relying on a UA check (to ensure they don't break when WebKit is fixed).

What I'd like to do (with TAG / blink API owners approval of course) is this:
1. ship document.scrollingElement.  From the closure code and Facebook's experience, such an API almost certainly makes the problem of updating UA-checking code from potentially difficult to trivial.
2. work to ensure all known frameworks and major sites are fixed (eg. to depend on scrollingElement)
3. enable ScrollTopLeftInterop and collect data
4. if we continue to see major breakage (major sites / popular frameworks), disable the flag and iterate from #2

Then the question is what amount of breakage we're willing to stomach to correct this long-standing wart.  Worst case, this process of evangelism and getting sites updated could take multiple years, or we could perhaps try to push through in a few months.  In any case, there's no point in even trying without a trivial drop-in replacement like scrollingElement. Thoughts?

Antonio Gomes

unread,
Apr 16, 2015, 11:47:59 AM4/16/15
to Simon Pieters, blink-dev, Rick Byers, Chris Harrelson, Matt Rakow
On Wed, Apr 15, 2015 at 9:27 PM, Simon Pieters <sim...@opera.com> wrote:
> On Tue, 14 Apr 2015 22:27:25 +0200, Rick Byers <rby...@chromium.org> wrote:
>
>> Thanks Matt.
>>
>> Chris and I talked more offline.
>>
>> 1) First there's the question of whether having BOTH body.scrollTop and
>> documentElement.scrollTop return/set the viewport scroll offset would be
>> more compatible than trying to switch our behavior. I don't think this
>> idea is worth pursuing.
>
>
> I agree, it seems bad to break `document.documentElement.scrollTop +
> document.body.scrollTop`.

That was the first approach I tried, and based on that experience I do
not advice assuming this is a good path to take again.

>> 2) There's still some risk we won't be able to change blink to match the
>> spec without unacceptable breakage. In that case, I believe
>> document.scrollingElement is still the exact API we want. We could
>> perhaps
>> even update the spec to discourage use of scrollTop/Left on body and
>> documentElement (possibly saying behavior is implementation defined) in
>> favor of scrollingElement. Arguably, if all browsers implement
>> scrollingElement (as now seems likely), it may not even be worth the pain
>> of trying to fix this longstanding bug!

Something to also consider is the way Chromium's / Chrome's Web UI is
coded today rely on the existing quirks. These are some of broken UI
issues that regressed when I toggled scrollTopLeftInterop first time:

https://code.google.com/p/chromium/issues/detail?id=305800
https://code.google.com/p/chromium/issues/detail?id=305745
https://code.google.com/p/chromium/issues/detail?id=304753
https://code.google.com/p/chromium/issues/detail?id=304816
https://code.google.com/p/chromium/issues/detail?id=305742

> Naw, I think it is still important to fix, as it enables
> independently-scrollable body and people will probably continue to run into
> the lack of interop even if scrollingElement exists.
>

Also, google's site could get fixed too:
https://code.google.com/p/chromium/issues/detail?id=304768
https://code.google.com/p/chromium/issues/detail?id=305099

>> Anyway, given the above I believe we should proceed with shipping
>> scrollingElement. I'll work to try to identify and update known sites
>> relying on a UA check to prefer scrollingElement.

No strong opinion here. I believe the amount of content that rely on
the quirks current behavior is non-trivial, I do not see
scrollingElement helping legacy content out there.
Still, if it does not get the situation worse, it seems worth it to try.


>> Separately we can re-discuss when / whether we should try to enable
>> ScrollTopLeftInterop by default.
>>
>> WDYT?

I agree.

Rick Byers

unread,
Apr 16, 2015, 12:06:56 PM4/16/15
to Antonio Gomes, Simon Pieters, blink-dev, Chris Harrelson, Matt Rakow
Yep, that's due to closure.  I can't really fix closure with document.scrollingElement. 


>> Anyway, given the above I believe we should proceed with shipping
>> scrollingElement.  I'll work to try to identify and update known sites
>> relying on a UA check to prefer scrollingElement.

No strong opinion here. I believe the amount of content that rely on
the quirks current behavior is non-trivial, I do not see
scrollingElement helping legacy content out there.
Still, if it does not get the situation worse, it seems worth it to try.

Don't you think your changes here (eg. consolidated in this CL) would have been made somewhat simpler by document.scrollingElement?  It's not as bad as a case like closure (where their public API depends on being able to identify a single element as the document-scrolling element), but still seems like it would have at least eased your pain substantially (could have become a simple regex: s/\.body\.scroll/\.documentElement\.scroll/g).

Antonio Gomes

unread,
Apr 16, 2015, 12:35:08 PM4/16/15
to Rick Byers, Simon Pieters, blink-dev, Chris Harrelson, Matt Rakow


No strong opinion here. I believe the amount of content that rely on
the quirks current behavior is non-trivial, I do not see
scrollingElement helping legacy content out there.
Still, if it does not get the situation worse, it seems worth it to try.

Don't you think your changes here (eg. consolidated in this CL) would have been made somewhat simpler by document.scrollingElement?  It's not as bad as a case like closure (where their public API depends on being able to identify a single element as the document-scrolling element), but still seems like it would have at least eased your pain substantially (could have become a simple regex: s/\.body\.scroll/\.documentElement\.scroll/g).

Yes! It is a progression for the transition and  as a possible long term solution.

I am a bit skeptical about the amont of broken legacy content when we flip scrollInterop ON, but you are the best person to try to move things forward here regardless.

+1 


 

>> Separately we can re-discuss when / whether we should try to enable
>> ScrollTopLeftInterop by default.
>>
>> WDYT?

I agree.



--
--Antonio Gomes

Philip Jägenstedt

unread,
Apr 17, 2015, 7:16:35 AM4/17/15
to Rick Byers, blink-dev
You have convinced me that this is a path worth trying. One of your comment on the TAG issue was illuminating to me:
https://github.com/w3ctag/spec-reviews/issues/51#issuecomment-93787661

The Closure code looks like this:
goog.dom.getDocumentScrollElement_ = function(doc) {
  // WebKit needs body.scrollLeft in both quirks mode and strict mode. We also
  // default to the documentElement if the document does not have a body (e.g.
  // a SVG document).
  if (!goog.userAgent.WEBKIT && goog.dom.isCss1CompatMode_(doc)) {
    return doc.documentElement;
  }
  return doc.body || doc.documentElement;
};

With document.scrollingElement it becomes trivial to make this reliable without the UA sniffing.

Also, apparently Microsoft have already copied the bug:

If there is to be any chance of fixing the documentElement-vs-body bug, time is of the essence. I think we should ship document.scrollingElement in M44, or even backport it to M43 if that isn't too crazy.

The worst-case and perhaps even most likely outcome is that we'll still fail to fix the documentElement-vs-body bug and that document.scrollingElement will become a synonym of document.body. However, even in that scenario document.scrollingElement would have some utility if also implemented by Gecko.

Philip

Rick Byers

unread,
Apr 17, 2015, 10:43:14 AM4/17/15
to Philip Jägenstedt, blink-dev
Thanks Philip!
Note that the above closure code is also exposed as a public closure API, so to avoid breaking compatibility with users of closure we need to return something of this form.  I think making such issues trivial to fix is essential if we'll ever make progress on this issue.

I doubt we'll be able to justify back-porting to M43, but I agree that it would be valuable to get moving ASAP.  Let's wait and see how the TAG review progresses (I assume the new launch processes requires that we blog on TAG review, right?).

Rick

PhistucK

unread,
Apr 17, 2015, 10:47:23 AM4/17/15
to Rick Byers, Philip Jägenstedt, blink-dev
Since the scrollingElement polyfill exists, what is keeping Closure from using it instead?


☆PhistucK

Rick Byers

unread,
Apr 17, 2015, 11:58:46 AM4/17/15
to PhistucK, Philip Jägenstedt, blink-dev
On Fri, Apr 17, 2015 at 10:46 AM, PhistucK <phis...@gmail.com> wrote:
Since the scrollingElement polyfill exists, what is keeping Closure from using it instead?

Because it's 100 lines of complexity / risk to replace one simple working line doing a UA check today.  They might accept it, but I'm not personally interested in trying to fight that battle with each framework / library I find that needs to update (IMHO they should rightly ask me to make it easier for them to do the right thing).  If we want a reasonable chance of ever fixing this bug, I believe we need to provide a clear incremental path where the choice of adoption is trivially easy.

Philip Jägenstedt

unread,
Apr 17, 2015, 12:22:39 PM4/17/15
to Rick Byers, blink-dev
The TAG review is still a bit of an experiment, it's not clear what
should happen if (hypothetically) every member of the TAG thinks this
is a terrible idea but everyone in the Blink project thinks it's
great. Let's just see how it goes. Aiming for M44 seems reasonable to
me, so maybe revive the question of shipping in about two weeks if
this thread goes silent?

Philip

PhistucK

unread,
Apr 17, 2015, 12:23:30 PM4/17/15
to Rick Byers, Philip Jägenstedt, blink-dev
Funny, they are using browser detection which is a very bad practice and you have to fight the battle with them. This is ridiculous. Especially for Closure - Google always advocates feature detections.

Regarding Closure specifically, the polyfill can be trimmed much because Google products do not support older browsers anyway.


☆PhistucK

Chris Harrelson

unread,
Apr 17, 2015, 12:45:57 PM4/17/15
to PhistucK, Rick Byers, Philip Jägenstedt, blink-dev
LGTM to ship.

Rick Byers

unread,
Apr 17, 2015, 12:46:06 PM4/17/15
to PhistucK, Philip Jägenstedt, blink-dev
On Fri, Apr 17, 2015 at 12:22 PM, PhistucK <phis...@gmail.com> wrote:
Funny, they are using browser detection which is a very bad practice and you have to fight the battle with them. This is ridiculous. Especially for Closure - Google always advocates feature detections.

Don't confuse Chrome team and the apps teams as Google.  There's often just as much diversity in our opinions as with any other group of browser vendors + web developers :-).

Still I'm less concerned about any one project like Closure than I am about the totality of the tail of issues.  Even the ones I can't find / contact in advance - I need there to be simple clear guidance that anyone can follow in 5 minutes to fix their website when (if) we ship this change and break people.

Rick Byers

unread,
May 4, 2015, 12:05:16 PM5/4/15
to Chris Harrelson, Dimitri Glazkov, PhistucK, Philip Jägenstedt, blink-dev
TAG has given it's approval, IE and Gecko have indicated their support, and WebKit says they're willing to implement if Mozilla and Blink do.

Philip / Dimitri - is there anything else you want to see before upgrading your LGTM from implement to ship?

Thanks,
   Rick

Dimitri Glazkov

unread,
May 4, 2015, 10:45:24 PM5/4/15
to Rick Byers, Chris Harrelson, PhistucK, Philip Jägenstedt, blink-dev
LGTM to ship.

:DG<

Philip Jägenstedt

unread,
May 5, 2015, 8:03:36 AM5/5/15
to Dimitri Glazkov, Rick Byers, Chris Harrelson, PhistucK, blink-dev
LGTM to ship for me too. Alex says that there will be a writeup that presumably the whole TAG has signed off on, but I think we should go ahead and revert only if something unexpected comes up.

Philip
Reply all
Reply to author
Forward
0 new messages