[cssom-view] document.scrollingElement review

I happened to notice scrollingElement was discussed on the call today and  
wanted to comment on a few things...

On Wed, 06 May 2015 02:40:50 +0200, Peter Linss <peter.linss@hp.com> wrote:

> 1. CSSOM View document.scrollingElement review
> ----------------------------------------------
> https://github.com/w3ctag/spec-reviews/issues/51

http://krijnhoetmer.nl/irc-logs/css/20150506#l-335 :

> [18:05] <dael> Topic: CSSOM View document.scrollingElement review
> [18:05] <plinss>  
> http://dev.w3.org/csswg/cssom-view/#dom-document-scrollingelement
> [18:06] <dael> plinss: TAG was asked for input and there was discussion  
> there, but I don't think we discussed this in the group. I wanted to  
> make sure we took a look at this and give commnts or feedback
> [18:06] <dael> plinss: It's not widely impl, but has different  
> behaviors. I'm not sure if this section has been reviewed by many people  
> and I want to make sure it's impl what we want it to impl.
> [18:07] <dael> plinss: So does anyone have feedback?
> [18:07] <dbaron> Why is this being added?  It seems like an odd  
> definition.
> [18:07] <dael> smfr: It's not clear if this is a stopgap until browsers  
> have correct behavior or if it's a long term API that will stick around
> [18:07] <dael> plinss: Not to me either.

It will stick around for sure, if browsers ship it.

> [18:07] <dael> Rossen: Which are you referring to?
> [18:08] <dael> smfr: In standards mode it's always scrolling element. I  
> think this is a stopgap until webkit and blick use the document element  
> in standards mode. With the intent this is used by polyfills to get  
> correct behavior
> [18:08] <dbaron> It would be nice if the spec actually contained the  
> motivation.

It does, in a note.

> [18:09] <dael> smfr: It doesn't feel like a stopgap, it seems like it  
> will stick around until the end of time. If it is a stopgap, I'd prefer  
> it was designed more like one.
> [18:09] <dael> Rossen: I don't think this is a stopgap. I think it has  
> wide adoption. Backing out, I'm not sure if it would be easy even if you  
> want to change.
> [18:09] <smfr> dbaron: lots of motivation at  
> https://github.com/w3ctag/spec-reviews/issues/51

Right.

> [18:09] <dbaron> Gecko doesn't implement it
> [18:09] <dael> plinss: It's not clear how useful this API is. What does  
> it do in iFrames? There's holes here.

What's not clear about iframes?

> [18:10] <dael> smfr: It's not intended to be scrolling. It's only for  
> this issue with a historical behavior where in standards mode it scrolls  
> the body, not the doc. It sounds more general, but it's really specific.
> [18:10] <dael> Rossen: We have impl the same way as webkit and Chrome  
> for mobile interop. This is a fairly used API at this point and I don't  
> think we can backout unless we do it together.

What is "it" referring to here?

> [18:10] <dael> smfr: I don't think you immpl this. I think you impl the  
> body as a scrolling element.
> [18:11] <dael> dbaron: If this is to be a transitional thing for the  
> quirky behavior can go away, shoudln't the definition be tied to if the  
> behavior is there?

In quirks mode, the behavior will not change. In standards mode, in  
Blink/WebKit/MSEdge, the hope is to move from the "quirky" behavior to the  
Gecko/IE11/spec behavior.

> [18:11] <dael> smfr: That's a good suggestion for ric.
> [18:11] <dbaron> (e.g., if Gecko were to implement it, and doesn't have  
> the quirky behavior, should we be implementing something different from  
> what the spec says?)

No. The normative part of the spec is exactly what Gecko should implement,  
and what other browsers should also implement when they switch from quirky  
to compliant behavior.

> [18:11] <dael> TabAtkins: The major reason for this is the weird  
> behavior of webkit and blink, but the same quirks mode effects it. So  
> even if you impl properly you still need to detect if you're in quirks  
> mode
> [18:12] <dael> plinss: I'm hearing from MS not sure if it can be  
> changed, hearing from others I'm not sure if that's the way we want it.
> [18:12] <dael> TabAtkins: It sounds like this is needed for quirks mode  
> vs standard mode docs as well as the webkit behaviors
> [18:13] <dael> Rossen: It sounds like this is something we ought to be  
> working on.
> [18:13] <dael> smfr: I don't obj to this. I think the bug report was  
> webkit would like it to be more clear on intent.
> [18:13] <dael> plinss: Are we comf. with the behavior as speced?
> [18:13] <dael> Rossen: Are you saying a little stronger and clearer def  
> would make you willing to put in efforts?
> [18:14] <dael> smfr: If what TabAtkins says is correct and this will be  
> longterm behaviour it seems like it has legs and will stick around.
> [18:14] <dael> Rossen: Okay. So who would want to work on that, spec  
> wise?
> [18:14] <dbaron> I think (a) we should have a plan to have  
> implementations doing the same thing and (b) if this is part of a plan  
> to migrate to some end state, that migration sequence should be  
> described in the spec

The desired end state is the current normative part of the spec.

> [18:14] <dael> TabAtkins: The spec part seems trivial. You put it in  
> CSSOM View and it's a paragraph of definition. That's all.

The spec already has a definition of scrollingElement, if that was what  
you meant.

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

> [18:14] <dael> plinss: dbaron made some comments in IRC
> [18:15] <dael> plinss: Anyone willing to take this work?
> [18:15] <dael> TabAtkins: I can work with ric to get a definition and do  
> a PR
> [18:15] <dael> plinss: Everyone happy with that?
> [18:15] <dael> Rossen: Yep.
> [18:15] <dael> resolved: accept the behavior but add more definitions

cheers
-- 
Simon Pieters
Opera Software
/me is not actually working so might be slow with responses

Received on Wednesday, 6 May 2015 17:35:19 UTC