[all] Move Houdini APIs to window.CSS

[tabatkins]

Per Seattle resolution (and TAG feedback), all the Houdini APIs should namespace themselves under the CSS object, rather than living on the global.

(Constructors still get put on the global by default, and that should be fine. We should add convenient aliases to CSS as appropriate, like CSS.px(x) for CSSSimpleLength(x, 'px').)

[dbaron]

#330 has some prior discussion (though specific to css-paint-api), including references to WebIDL work

[shans]

For typed OM, this would just be Window.getComputedStyleMap.

Should that become CSS.getComputedStyleMap, or CSS.getComputedStyle?

[bfgeek]

I've changed all the css-paint-api to CSS interface.

[nainar]

With regards to @shans suggestion I vote for CSS.getComputedStyleMap to make it clear to developers if they misuse it

[css-meeting-bot]

The CSS Working Group just discussed #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

The full IRC log of that discussion

<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

[nainar]

As per #454 - removing css-typed-om label. Since the work pertaining to that spec seems to be done here.

[majido]

@tabatkins can we close this issue now? Is there any more work left to be done?