Re: [css-houdini-drafts] [all] Move Houdini APIs to `window.CSS`

The CSS Working Group just discussed https://github.com/w3c/css-houdini-drafts/issues/350, and agreed to the following resolutions:

```
RESOLVED: element.attributeStyleMap and element.computedStyleMap, attributeStyleMap to be renamed later, pseudo-element styles accessed through PseudoElement APIs
```

<details><summary>The full IRC log of that discussion</summary>

```
<shane> Topic: https://github.com/w3c/css-houdini-drafts/issues/350
<fantasai> shane: have window.getComputedStyleMap()
<shane> should either be CSS.getComputedStyleMap or CSS.getComputedStyle
<fantasai> shane: It should either be CSS.getComputedStyleMap() or CSS.getComputedStyle()?
<dbaron> Github topic: https://github.com/w3c/css-houdini-drafts/issues/350
<fantasai> shane: We called it getComputedStyleMap() earlier so it doesn't collide with getComputedStyle, but now we have an opportunity to use the other name
<fantasai> iank_: Does it make sense to move that particular one to CSS from window?
<fantasai> dbaron: Why isn't this element.computedStyleMap?
<fantasai> dbaron: Putting getComputedStyle() on window was a mistake
<shane> 1. Window.getComputedStyleMap()
<shane> 2. CSS.getComputedStyleMap()
<fantasai> leaverou: Why not just element.computedStyle
<shane> 3. CSS.getComputedStyle()
<fantasai> leaverou: Which is what getComputedStyle should have been in the first place
<fantasai> dbaron: That's more or less what I said in the first place..
<fantasai> leaverou: I thought you were proposing a function
<shane> 4. Element.computedStyleMap
<fantasai> dbaron: I think, IIRC, that other things that return style maps end in StyleMap, and wouldn't want ot have just one that omits the word Map
<fantasai> dbaron: But should be a getter
<fantasai> leaverou: especially if it has Map at the end
<fantasai> shane: I quite like element.computedStyleMap
<fantasai> iank_: Is this live?
<fantasai> TabAtkins: Yes, it's in the minutes
<TabAtkins> (Per the minutes, it's live and we're very sad about it.)
<fantasai> SimonSapin: Style maps are live in general, but computedStyle is readonly isn't it?
<fantasai> TabAtkins: Yes
<fantasai> SimonSapin: So it doesn't matter if it's live
<fantasai> dbaron: yes it does, cuz then things are changed
<fantasai> TabAtkins: nice thing is that values are hidden behind .get call so can compute them lazily
<fantasai> iank_: One thing that getComputedStyle has is second arg is optional string for pseudo-element name
<fantasai> dbaron: We had this discussion before 5 years ago
<fantasai> dbaron: We specced it all in CSSOM
<fantasai> dbaron: But then deleted it because nobody implemented it
<fantasai> dbaron: But we did come up with API we liked for this
<fantasai> dbaron: Wehad a pseudo-element class
<fantasai> birtles: I thought it was defined in two specs, in CSSOm and css-pseudo
<fantasai> fantasai: Stuff in css-pseudo is "here is some stuff as ideas, please comment on it" not ready to impl..
<fantasai> shane: Let's do what dbaron says
<birtles> birtles: CSSPseudoElement is used by Web Animations
<fantasai> shane: If we want to have pseudo-element class and have computed style of them hang off htat class, then tpe dCSSOM might not let you get pseudo element styles
<fantasai> shane: transiently while we put the rest of the mechanism in place
<fantasai> shane: But I don't think that's an issue given that the typed OM is incomplete in lots of other ways anyway
<fantasai> shane: SO I think we should do what dbaron says
<fantasai> Rossen: I think we already established that :)
<fantasai> shane: I'm gonna keep saying it until we resolve on it
<fantasai> Rossen: Was there some other option?
<fantasai> shane: Yeah, I listed them out
<shane> 1. Window.getComputedStyleMap()
<shane> 2. CSS.getComputedStyleMap()
<shane> 3. CSS.getComputedStyle()
<shane> 4. Element.computedStyleMap ( + pseudoElement mechanisms)
<fantasai> Rossen: What's + pseudElement mechanism?
<fantasai> shane: Have an object representing the pseudoElement with a .computedStyleMap
<fantasai> dino: Why not just .styleMap?
<fantasai> ?: Because that's style attr
<fantasai> dino: But this is the API people actually want
<fantasai> ??: Could call it inlineStyleMap and computedStyleMap to be explicit about it
<fantasai> dino/smfr: people already get confused about .style being style attr and not computed style
<shane> 5. 4 + styleMap -> ??bikeshed??StyleMap
<fantasai> TabAtkins: Don't really want to have .style = inlineStyleMap and styleMap = getCoputedStyle
<SimonSapin> .styleAttrMap / .computedStyleMap ?
<fantasai> SimonSapin: Don't want to overload inline, already overloaded
<leaverou> 4 (though it depends on the pseudo-element mechanisms)
<fantasai> fantasai: I like .styleAttrMap / .computedStyleMap
<fantasai> Rossen: attrStyleMap
<fantasai> plinss: So that it's always StyleMap
<fantasai> iank_: No other DOM api abbreviates attribute
<fantasai> Rossen: Okay, we can bikeshed that late
<fantasai> r
<fantasai> Rossen: So, option #N is adopt element.attrStyleMap and element.computedStyleMap + pseudoElement mechanisms
<fantasai> iank_: I don't want the attr thing
<fantasai> iank_: attribute
<fantasai> Rossen: We'll make it attributeStyleMap
<fantasai> RESOLVED: element.attributeStyleMap and element.computedStyleMap, attributeStyleMap to be renamed later, pseudo-element styles accessed through PseudoElement APIs
<fantasai> dino: Can someone summarize the pseudElement stuff?
<fantasai> TabAtkins: element.pseudos with ..
<fantasai> dbaron: was a function pseudo(...) that returns elementlike thing
<fantasai> leaverou: What about parameterized pseudo elements
<dbaron> element.pseudo(":before").computedStyleMap
<TabAtkins> "::before", certainly
<fantasai> https://www.w3.org/TR/2013/WD-cssom-20131205/#extensions-to-the-element-interface
<fantasai> fantasai: There's a reason we publish periodically to /TR with with dated snapshots
<dbaron> https://hg.csswg.org/drafts/rev/26e59827f85c removed it
<dbaron> It is present in https://www.w3.org/TR/2013/WD-cssom-20131205/#extensions-to-the-element-interface although there may have been later improvements before the removal
<fantasai> Rossen: we need to publish a new draft pending the changes
```
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/350#issuecomment-294690156 using your GitHub account

Received on Tuesday, 18 April 2017 05:38:16 UTC