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

Open
tabatkins opened this Issue Feb 3, 2017 · 6 comments

Comments

Projects
None yet
6 participants
@tabatkins
Member

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

@dbaron

This comment has been minimized.

Show comment
Hide comment
@dbaron

dbaron Mar 13, 2017

Member

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

Member

dbaron commented Mar 13, 2017

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

@shans

This comment has been minimized.

Show comment
Hide comment
@shans

shans Apr 3, 2017

Contributor

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

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

Contributor

shans commented Apr 3, 2017

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

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

@bfgeek

This comment has been minimized.

Show comment
Hide comment
@bfgeek

bfgeek Apr 10, 2017

Contributor

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

Contributor

bfgeek commented Apr 10, 2017

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

@bfgeek bfgeek removed the css-paint-api-1 label Apr 10, 2017

@nainar

This comment has been minimized.

Show comment
Hide comment
@nainar

nainar Apr 18, 2017

Contributor

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

Contributor

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

@css-meeting-bot

This comment has been minimized.

Show comment
Hide comment
@css-meeting-bot

css-meeting-bot Apr 18, 2017

Member

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
Member

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: 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

@shans shans added the Needs Edits label May 23, 2017

shans added a commit that referenced this issue Aug 22, 2017

[css-typed-om] #350 Rename styleMap and getComputedStyleMap (#454)
* Move getComputedStyleMap to CSS namespace

* Rename to attributeStyleMap/computedStyleMap

* Rename CSSStyleRule.styleMap as well
@nainar

This comment has been minimized.

Show comment
Hide comment
@nainar

nainar Oct 17, 2017

Contributor

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

Contributor

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.

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