Skip to content

[css-typed-om] Describe that StylePropertyMaps are not live objects #149

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

Closed
nainar opened this issue Apr 4, 2016 · 9 comments
Closed

[css-typed-om] Describe that StylePropertyMaps are not live objects #149

nainar opened this issue Apr 4, 2016 · 9 comments

Comments

@nainar
Copy link
Contributor

nainar commented Apr 4, 2016

No description provided.

@nainar
Copy link
Contributor Author

nainar commented Apr 4, 2016

@tabatkins

@jyc
Copy link
Contributor

jyc commented Jul 26, 2016

What does this mean? If a CSS declaration or inline style is otherwise modified (say, through JS), does the specified or inline StylePropertyMap update? What happens if we then call StylePropertyMap::append, for example? Do we append to the declaration or inline style based on its current value while appending to the StylePropertyMap's value based on what it was created with? What does the iterator give us for that property?

@jyc
Copy link
Contributor

jyc commented Jul 26, 2016

Found a definition of "live object" here: https://dom.spec.whatwg.org/#concept-collection-live .
Is this the correct definition? If so, and these are not live objects and therefore do not "operate on the actual underlying data, not a snapshot of the data," what is the point of mutable StylePropertyMaps?

@shans
Copy link
Contributor

shans commented Jul 27, 2016

To clarify, this is saying that StylePropertyMaps won't update based on style changes from other sources:

var map = el.styleMap;
map.get('height') // for argument's sake, CSSSimpleLength(100, 'px')
el.style.height = '200px';
map.get('height') // will still return CSSSimpleLength(100, 'px')

It might actually be reasonably simple to support live maps for specified objects but for computed styles this gets quite expensive, and it seems best to be consistent.

@shans
Copy link
Contributor

shans commented Jul 27, 2016

feedback from jyc on irc: this should probably be true only for computed maps, not specified maps.

@tabatkins
Copy link
Member

Ah, that's probably fine. I was getting a little confused why .set() worked but wasn't live - there's clearly still a communication channel there. (This doesn't really need to be "live", per se, it's just that .get() goes and gets the value off of the element.)

So yeah, the Readonly version is non-live.

@dbaron
Copy link
Member

dbaron commented Sep 22, 2016

Resolved to be live for specified and for computed style maps.

@shans
Copy link
Contributor

shans commented Apr 3, 2017

The only map that's left is the inline map. We didn't specifically talk about this during the spetember f2f but it seems it should be live too. OK for me to close this issue as invalid?

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed #149, and agreed to the following resolutions:

RESOLVED: inline style map is also live
The full IRC log of that discussion
<shane> Topic: https://github.com/w3c/css-houdini-drafts/issues/149
<fantasai> shane: We resolved in September of last year tha tthe specified and computed style maps were live
<fantasai> shane: So if you made changes not through typed OM, would see those changes reflected i nthe map
<fantasai> shane: We did not discuss inline style map
<fantasai> shane: I assume that would be live as well, anyone disagree?
<fantasai> dbaron: I consider that one case of the specified style
<fantasai> shane: Same as specified style in the sense that represents specified style, but has different backing model
<fantasai> Rossen: If we're making specified style live, inline is just specified
<fantasai> RESOLVED: inline style map is also live

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

No branches or pull requests

6 participants