- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 Apr 2018 09:11:24 +0000
- To: public-css-archive@w3.org
The Working Group just discussed `Clarify behavior of window.getComputedStyle on detached subtrees, and the definition of "the root element"`, and agreed to the following resolutions: * `RESOLVED: For elements not part of a tree or part of a detached tree they return no computed styles` * `RESOLVED: Elements not part of a flat tree return no style for getComputedStyle` * `RESOLVED: Regardless of what window you obtain the gCS function from the origin of the style is where ever the element is` * `RESOLVED: getComputedStyle returns none for elements part of non-rendered iframes` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Clarify behavior of window.getComputedStyle on detached subtrees, and the definition of "the root element"<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/1548<br> <dael> emilio: While I was doing the styling stuff it became unclear and it became obvious that each browser does something different.<br> <dael> emilio: FF does if you go across document it's sometimes across document, sometimes the ones attached to that doc. We should decide how it should work.<br> <dael> Rossen: In your issue it's detached sub trees.<br> <dael> emilio: Spec says whenever you call window.getComputedStyle on a document it says you should only get values in that window.<br> <dael> TabAtkins: I'd rather say they don't have a computedStyle.<br> <dael> emilio: Yes, you can't do it on an iframe. If you break that the web breaks. There's 3 cases. Element outside doc, computed stylle cross document.<br> <dael> TabAtkins: Also shadow dom. If it's detached no style. If it's in an iframe that happens to be detached we can discuss. The others have no style.<br> <dael> TabAtkins: The flat tree case there's nothing to inherit from.<br> <dael> rune_: But for not slotted and fallback for slotted?<br> <dael> TabAtkins: Yeah.<br> <dael> rune_: I don't know what is a sensible choice.<br> <dael> TabAtkins: String param.<br> <dael> fremy: For us it's work. Anything that's not tree I think it's reasoable to say don't render a style. All the use cases I have are internal and we don't need the API. For the API elements outside the tree can return no style. Still want it to work in documents. Spec requests if you call getComputedStyle from one window to another you have to get the values from the other window.<br> <dael> TabAtkins: spec bug<br> <dael> fremy: We don't want this. If we try and run this we get the wrong docuemnt. if you call getComputedStyle you get the values for the document of the element for which you called.<br> <dael> TabAtkins: Agree.<br> <dael> Rossen: Separate issue, though. Back to this one. What do we return on elements not part of any document?<br> <dael> Rossen: In Edge we go threw pains to try and calc what it should have been and it's a pain. We'd rather return some stock style with initial values or not return anything.<br> <dael> emilio: Makes sense. I think we can switch FF for non-iframes because we have archetectur that prevents us from this for iframes.<br> <dael> TabAtkins: I'd like to know more why you think web compat on iframes<br> <dael> emilio: blink returns style of actual document. But you can't say there's no style.<br> <dael> dbaron: Gecko has had security bugs about getting confused about styles between doc<br> <dael> emilio: When we know we're in the mess we're now consistant.<br> <dael> TabAtkins: Boris mentions iframes. What's the next best thing.<br> <dael> emilio: computing style from the window.<br> <dael> TabAtkins Returning some styles is required for web compat.<br> <dael> Rossen: But a stock style with initials<br> <dael> emilio: Might not work.<br> <dael> emilio: Still talking corss document? Detached sub trees returning no style works.<br> <dael> TabAtkins: Detached element or one in a detached sub tree should return no computed styles<br> <dael> rune_: Boris mentioned...<br> <dael> Rossen: One at a time.<br> <dael> Rossen: For elements not part of a tree or part of a detached tree they return no computed styles<br> <dael> Rossen: Obj?<br> <dael> RESOLVED: For elements not part of a tree or part of a detached tree they return no computed styles<br> <dael> Rossen: next.<br> <astearns> (and by no computed styles, we mean empty strings)<br> <dael> TabAtkins: An element not in the flat tree<br> <dael> emilio: Either return no style or return from the default.<br> <dael> Rossen: Reason to do that?<br> <dael> emilio: We don't ship shadow dom.<br> <dael> rune_: Blink does the same.<br> <dael> TabAtkins: Let's do it. No style.<br> <dael> Rossen: Elements not part of a flat tree return no style for getComputedStyle<br> <dael> emilio: You sure blink does that?<br> <dael> rune_: Not in the flat tree you get parent value which is null.<br> <dael> rune_: If not we should fix it.<br> <dael> Rossen: Obj?<br> <dael> RESOLVED: Elements not part of a flat tree return no style for getComputedStyle<br> <dael> TabAtkins: calling gCS from one window on an element from another document should return the element's normal styles<br> <dael> TabAtkins: If we decide later we needed it we can change.<br> <dael> fremy: That's what we do.<br> <dael> TabAtkins: Regardless of what window you obtain the gCS function from the origin of the style is whereever the element is<br> <dael> Rossen: Obj?<br> <dael> RESOLVED: Regardless of what window you obtain the gCS function from the origin of the style is where ever the element is<br> <dael> TabAtkins: Next is a display:none or detached iframe or elements inside of it have a window they can hit and a styling context, but are not being rendered. In this case we have to return something, we can return all initial.<br> <dael> Rossen: I think last time we tried this someone...FF or Blink...returned stock style<br> <dael> emilio: I suspect returning stock style is not going to be web compat. jQuery used to create display:none iframe and point computed style there and it wants to know the default style for a div.<br> <dael> fremy: I think no change.<br> <dael> emilio: There's a question of how MQ are resolved.<br> <dael> TabAtkins: All MQ resolve.<br> <dael> fremy: I don't remember what we do. I don't think it matters for compat.<br> <TabAtkins> s/resolve/are false/<br> <dael> smfr: I have this memory that browsers are going up the render tree for a display:none iframe. Don't ads create them?<br> <dael> emilio: gecko doesn't do anything like that. I think blink doesn't create render trees.<br> <dael> smfr: Yeah, we created some optimizations.<br> <dael> ??: We've gone back and forth. We've tried to create it, but we've gone back and forth.<br> <emilio> s/??/eae/<br> <dael> smfr: getComputed Style may have a [missed]<br> <smfr> s/[missed]/created a render tree<br> <dael> eae: WE don't do that today and haven't had a reason to revert that decision.<br> <dael> smfr: I'm not objecting, but I thik there's compat. Long term I think we all agree.<br> <dael> Rossen: We've held the display:none hammer for a long time.<br> <dael> Rossen: If you guys are doing it then it should be web compat.<br> <dael> eae: Too early to tell.<br> <dael> Rossen: If we spec it would be that display:none iframes return nothing?<br> <dael> eae: Yeah.<br> <dael> emilio: iframes that are not in the document? I guess the have no style.<br> <dael> Rossen: They shouldn't.<br> <dael> emilio: So display:none iframes and iframes not rendered in the document.<br> <dael> Rossen: They're elements that are not part of anything. That they're iframes doesn't make them less of an element.<br> <dael> Rossen: I think what you raised is for the subtrees inside iframes what do we do.<br> <dael> emilio: FF has an API that we added for jQuery. We tried to remove it and failed because calling getComputedStyle on an iframe that's not rendered.<br> <dael> Rossen: So there is a compat issue.<br> <dael> emilio: I suspect it's still the case.<br> <dael> Rossen: Proposal?<br> <dael> emilio: I'd love to say we don't return style but I don't thinkt hat's reaslistic. I think all browsers return.<br> <dael> Rossen: We do. We go through serious pains to compute styles in all situations and we want out. If there's a compat reason for jQuery<br> <dael> emilio: It's an old version of jQuery.<br> <dael> Rossen: Plenty uses older jQuery, though.<br> <dael> emilio: If someone wants to try not returning style on iframes and see what it does that would be nice.<br> <dael> eae: I don't think we've shipped not returning styles<br> <dael> Rossen: From behavior PoV returning none makes most sense. We can try and spec it and based on impl feedback we might come back and say compat blocks this and we need to revisit.<br> <dael> emilio: And if we do we have to define MQs. If people are willing to try this works.<br> <dael> Rossen: Prop: getComputedStyle returns no result for elements part of display:none or detached iframe<br> <dael> emilio: non-rendered type iframes<br> <dael> Rossen: Prop: getComputedStyle returns no result for elements part of non-rendered iframes<br> <dael> RESOLVED: getComputedStyle returns none for elements part of non-rendered iframes<br> <dael> Rossen: Anything else o nthis issue?<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1548#issuecomment-380383455 using your GitHub account
Received on Wednesday, 11 April 2018 09:11:29 UTC