Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[all] Move Houdini APIs to window.CSS #350

tabatkins opened this issue Feb 3, 2017 · 7 comments

[all] Move Houdini APIs to window.CSS #350

tabatkins opened this issue Feb 3, 2017 · 7 comments


Copy link

tabatkins commented Feb 3, 2017

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').)

Copy link

dbaron commented Mar 13, 2017

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

Copy link

shans commented Apr 3, 2017

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

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

Copy link

bfgeek commented Apr 10, 2017

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

Copy link

nainar commented Apr 18, 2017

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

Copy link

css-meeting-bot commented Apr 18, 2017

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:
<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:
<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> fantasai: There's a reason we publish periodically to /TR with with dated snapshots
<dbaron> removed it
<dbaron> It is present in although there may have been later improvements before the removal
<fantasai> Rossen: we need to publish a new draft pending the changes

shans pushed a commit that referenced this issue Aug 22, 2017
* Move getComputedStyleMap to CSS namespace

* Rename to attributeStyleMap/computedStyleMap

* Rename CSSStyleRule.styleMap as well
Copy link

nainar commented Oct 17, 2017

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

Copy link

majido commented Jun 24, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

7 participants