- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 11 Jun 2024 10:27:15 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[cssom] How safe is it really to shorthandify properties?`.
<details><summary>The full IRC log of that discussion</summary>
<emeyer> fantasai: We often want to extend CSS by turning an existing proeprty into a shorthand<br>
<emeyer> …There are compatiobility problems with that<br>
<emeyer> …This shows up in ennumeration of CSS style declarations, which is only supposed to ennumerate longhands<br>
<emeyer> TabAtkins: We have some compatibility issues with turning anything into a shorthand<br>
<emeyer> …A few APIs only care about longhands<br>
<emeyer> …Sudden losses of properties cause bugs in people's programs<br>
<emeyer> …We saw this with white-space and another one that escapes me<br>
<emeyer> …Chrome got some bugs reported and ended up implementing a third, worse behavior<br>
<lea> Seems like the appropriate solution is to fix these APIs, not to stop shorthandifying properties. Shorthands not showing up in these APIs (when they could be serialized) is a common author pain point.<br>
<emeyer> …we prefer not to do that again, especially for things like positoin<br>
<dbaron> (were you thinking of vertical-align as the other one?)<br>
<emeyer> …We suspect position is un-shorthand-able<br>
<lea> q+<br>
<emilio> we did shorthandify something really old (overflow) without that much pain, right?<br>
<oriol> q+<br>
<emeyer> …David, you're right, it was vertical-align<br>
<emeyer> …Emilio, I don't know how much pain there was with overflow<br>
<fantasai> emilio, that was expanded out a very very long time ago; we just expanded the shorthand to allow two keywords recently<br>
<emeyer> florian: Were you going to explain how to work around this with that behavior?<br>
<dbaron> (I think overflow was a shorthand in WebKit from very long ago.)<br>
<emeyer> TabAtkins: No, we really don't like it, and we don't want to do it any more<br>
<astearns> ack lea<br>
<emeyer> lea: Seems like we should fix the APIs, not stop fixing CSS<br>
<una> q+<br>
<emeyer> …Shorthands not showing up in APIs is a perpetual author pain point<br>
<fserb> +1 to that<br>
<emeyer> oriol: Don't completely agree with Lea<br>
<emilio> q+<br>
<emeyer> …if you ask for a shorthand, you get a list of all the longhands, which seems normal<br>
<emeyer> …I think it's duplicated information to have both shorthands and longhands<br>
<florian> q+<br>
<emeyer> …From Tab, I have concerns about duplicating things<br>
<emeyer> …Inline styles can be modified by CSSOM and that concerns me<br>
<fserb> q+<br>
<astearns> ack oriol<br>
<emeyer> …If you remove some longhands, keeping the shorthands would be broken, so there would need to be checks to avoid that<br>
<emeyer> …If you're iterating longhands from end to beginning, and removing some, that would mess up indexes and you could end up going out of bounds<br>
<emeyer> …Depending on what the author is doing, the application can break<br>
<lea> q+ to say the current design is clearly problematic, and these don't seem like dealbreakers, just like the usual design decisions we need to make with every feature. And they certainly don't prove that we shouldn't even explore that avenue. I don't see how removing shorthands when the longhands are removed is that different from adding longhands when a shorthand is specified, it's not like what the author specified is preserved exactly<br>
<astearns> ack una<br>
<emeyer> una: An example of where shorthands add confusion is recently we implemented transition-behavior with discrete value<br>
<TabAtkins> transition-behavior: allow-discrete<br>
<emeyer> …The transition acutally overrides the longhand<br>
<emeyer> …This is one example where we'd let authors opt in, but we can't do that now<br>
<emilio> q-<br>
<emeyer> …Shorthands aren't always better and can add confusion<br>
<astearns> ack florian<br>
<una> s/discrete/allow-discrete<br>
<emeyer> florian: Need to think about this further, but for these APIs that care about the difference between short and longhands<br>
<emeyer> …If the values in use can be represented through the shorthand, then we include the shorthand only in the serialization<br>
<emeyer> …If not, then we'd include the longhands only in the APIs<br>
<emeyer> emilio: That causes really weird behavior<br>
<emeyer> …The set of anuimated properties can become longer, and would change longstanding behavior<br>
<emeyer> …You would maybe expect the four margin longhands, but suddenly you just get margin<br>
<emeyer> …This would make computing the length of the ennumerator difficult<br>
<emeyer> TabAtkins: I presume this would only apply for the handful of properties we list out<br>
<emeyer> florian: I think emilio's point is good; there are a bunch of proeprties we can't do this for<br>
<emeyer> …But could it work if we scoped it to certain properties?<br>
<emeyer> …We could let existing proeprties continue to act as is, but open up new behaviors<br>
<emeyer> dbaron: I think a bunch of this is going in a direction that's not the problem we need to address<br>
<emeyer> …This is more about ennumeration and not about serialization<br>
<astearns> ack fserb<br>
<emeyer> fserb: I'm confused about the scope of the question, whether it's about ennumeration or is it more generic?<br>
<emeyer> florian: I think if you could serialize as the shorthand, you would do that; if you can't, then you wouldn't<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to discuss minimal compat fix<br>
<emeyer> fantasai: I think as Tab said, we can't do this for all proeprties<br>
<emeyer> …For transition stuff, perhaps we could include both shorthand and longhand safely<br>
<emeyer> …For the ennumeration, we'd keep a list and if the longhands can be represented as a shorthanded value that's one of the values that are legacy-constrained<br>
<oriol> q+<br>
<emeyer> …If the longhands have extra values that can't be represented in that limited syntax, we ennumerate the longhands<br>
<emeyer> …So for white-space, if you gave it some new unrecognized value, then you'd ennumerate the longhands<br>
<emeyer> dbaron: My understanding of the ennumeration problem is that there's no concern whatsoever about the values<br>
<emeyer> …I believe the problem is that if you do a JS ennumeration through CSSOM, it gives you a list of every longhand property in CSS<br>
<florian> q+<br>
<emeyer> …It doesn't matter what's been specified, it's just a list of everything<br>
<emeyer> …I think we've fixed the serialization problems<br>
<emeyer> …We have problems with mechanisms that let you ennumerate weverything in CSS, which have no value depends at all<br>
<astearns> ack dbaron<br>
<emeyer> s/depend/dependence/<br>
<emeyer> …It's possible there are other problems here, but does anyone think I was wrong about that?<br>
<emeyer> TabAtkins: No<br>
<astearns> ack lea<br>
<Zakim> lea, you wanted to say the current design is clearly problematic, and these don't seem like dealbreakers, just like the usual design decisions we need to make with every feature.<br>
<Zakim> ... And they certainly don't prove that we shouldn't even explore that avenue. I don't see how removing shorthands when the longhands are removed is that different from adding<br>
<Zakim> ... longhands when a shorthand is specified, it's not like what the author specified is preserved exactly<br>
<astearns> q+ dbaron<br>
<emeyer> lea: Back to what Oriol was saying, we know the CSSOM is problematic<br>
<emeyer> …We need to explore some of these avenues to see if what we come up with, we need to check if it will make things worse or better<br>
<emeyer> …Authors specifying shorthands and getting back longhands is just as confusing as making shorthands disappear when longhnads disappear<br>
<emilio> q+<br>
<emeyer> …Authors almost never intend to get back the entire list of of all properties<br>
<TabAtkins> These enumerations are used by some tooling, that's who reported compat bugs<br>
<emeyer> …If authors ask for a border, they can't get any shorthands, they have to get a very specific longhand<br>
<emilio> dbaron: In specified declarations, we do only enumerate specified longhands<br>
<emeyer> oriol: If you ask for the border, you get the border, you get the serialized values<br>
<emeyer> …I do agree with dbaron, this isn't a value problem<br>
<astearns> ack oriol<br>
<emilio> It's only getComputedStyle() which returns all longhands<br>
<emeyer> …If you change the value of a longhand or a shorthand, a shorthand stops being serializable<br>
<emeyer> …This would make things unreliable<br>
<astearns> ack florian<br>
<emeyer> lea: I was just writing that parts of the CSSOM seem to have improved<br>
<emeyer> florian: I'm not approaching this as serialization, I agree it's about ennumeration<br>
<emeyer> …It may be this is a bad idea, but I think all the cases you mentioned about ennumeration, they all depend on contexts where you could go on to get the value<br>
<emeyer> …If there isn't the notion of being able to ask, then what I propose would become impossible<br>
<emeyer> …If you can go on to ask about the values after you ennumerate, then this linkage can be made<br>
<emeyer> …In order to preserve shorthands as standalone properties, this would introduce a dependency, and has the downside that the set of properties and their indexes would change<br>
<lea> +1 to florian<br>
<emeyer> …Itæs a tradeoff, but it might be a worthwhile tradeoff<br>
<astearns> ack dbaron<br>
<emeyer> dbaron: I think from the JS perspective, what Oriol is suggesting would be really strange<br>
<emeyer> …I admit I haven't paid a ton of attention to JS engine optimizations, but back when I did, there was much done based on type inference<br>
<emeyer> …Making an object have different properties means now CSS style isn't really a type, it's hundreds of types<br>
<emeyer> iank_: It changes the shape<br>
<emeyer> dbaron: We're talking at the boundary of the CSSOM and JS<br>
<emeyer> florian: Not quite undoable, but very near><br>
<emeyer> dbaron: Yes<br>
<emeyer> fantasai: So you're saying this thing we're ennumerating always returns every property in CSS?<br>
<emeyer> dbaron: Yes<br>
<emeyer> …If you use an ennumeration in JS to ask what all the fields in a CSS style are, you get all the CSS properties<br>
<emeyer> fantasai: And ennumerating the short and longhands would break in what ways?<br>
<bramus> +1 to dbaron<br>
<lea> q?<br>
<astearns> ack emilio<br>
<emeyer> dbaron: If we could do it, that might work, but I don't know if that would break anything<br>
<emeyer> emilio: I don't know if that's true<br>
<fantasai> s/short and longhands/shorthands in question and their longhands/<br>
<lea> q+ Not sure I understand what's strange from a JS perspective. Enumerating objects whose properties have dependencies between them is pretty common? Also, is the proposal to *only* include shorthands? I thought it was to include both…<br>
<lea> q?<br>
<emeyer> …When you ennumerate specific CSS declarations, you get the longhands that are specified in that declaration<br>
<florian> s/ but very near>/ but very weird?<br>
<lea> q+<br>
<emeyer> … .length is how many longhands you have in there<br>
<dbaron> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cbody%20style%3D%22margin%3A%202em%22%3E%0A%3Cscript%3E%0Afor%20(var%20i%20in%20document.body.style)%20%7B%0A%20%20document.write(i%20%2B%20%22%3Cbr%3E%22)%3B%0A%7D%0A%3C%2Fscript%3E<br>
<emeyer> iank_: I believe dsome of our compatibility problems came from ennumerating<br>
<dbaron> emilio, see above testcase<br>
<emeyer> emilio: Preserving shorthands in specified styles is a relatively big change, but seems doable<br>
<florian> q+<br>
<emeyer> …Doing it in getComputedStyle is a bit tricky<br>
<emeyer> dbaron: I don't think that's the issue<br>
<dbaron> dbaron: I think it was (for i in document.body.style)<br>
<lea> dbaron's demo with values: https://codepen.io/leaverou/pen/KKLXqBw?editors=1111<br>
<emeyer> emilio: A lot of things we've been discovering have been different<br>
<astearns> ack lea<br>
<emeyer> lea: ASking David what is weird from the JS perspective<br>
<emeyer> …Is the proposal to remove longhands?<br>
<emeyer> dbaron: I'm not sure what you mean by dependencies and if there was a proposal<br>
<emeyer> …I think maybe it was to include shorthands in a place that only has longhands<br>
<fserb> q+<br>
<emilio> `for (let i in document.body.style) { console.log(i) }` does include shorthands<br>
<emilio> (In Gecko at least)<br>
<emeyer> TabAtkins: That appears to be a requirement of whatever we settle on<br>
<astearns> ack florian<br>
<emilio> q+<br>
<emeyer> florian: I think we effectively have three proposal to consider<br>
<emeyer> …1. Sometimes don';t include longhands<br>
<lea> What I was proposing was to include *both* longhands and shorthands.<br>
<dbaron> emilio, it doesn't include "font" in the url I gave above<br>
<emeyer> …2. The list of properties you ennumerate depends on the actual values<br>
<emeyer> …3. For a subset of properties, list both the shorthands and longhands only<br>
<emeyer> …You'd have to make it a subset because there are historical properties where doing that would break things<br>
<emilio> dbaron: it does for me? (the codepen console eats it because too many properties)<br>
<emeyer> fserb: This is just about the ennumeration?<br>
<emeyer> florian: Yes<br>
<fantasai> s/dbaron:/dbaron,<br>
<lea> emilio: Open the browser console<br>
<emeyer> …I suspect alternative 3 is the simplest, but I don't know if it's possible<br>
<astearns> ack iank_<br>
<astearns> ack IanK<br>
<Zakim> IanK, you wanted to clarify what exactly the problems are that we're running into<br>
<emeyer> fantasai: Ian, what are the problems and what are we trying to solve?<br>
<emeyer> iank_: I'd have to go back and see what we found<br>
<dbaron> emilio, oops, you're right -- they're in a very strange order!<br>
<emilio> lea, `{ let found = false; for (let i in document.body.style) { found = found || i == "font" } console.log(found) } ` logs true here<br>
<emeyer> …I worry that optoin 3 would open a separate can of worms<br>
<emeyer> astearns: We could resolve on opening that can of worms to see what we find<br>
<florian> q?<br>
<lea> emilio: Yes, that's what I'm noticing in Chrome too. Then what's the issue?<br>
<florian> qq+<br>
<emilio> q+<br>
<emilio> dbaron, See above? ^<br>
<fantasai> [note to scribe to keep lea/emilio chat as a side-converstaion, not as corrections to the minutes]<br>
<astearns> ack fserb<br>
<emeyer> fserb: Can someone speak to the use case here?<br>
<emeyer> …What's the use case for ennumeration?<br>
<dbaron> ok, yeah, chrome and gecko both seem to include shorthands in enumeration... I'm not sure what the issue is<br>
<emeyer> …What do we care about, and what do we not?<br>
<emeyer> florian: I'm not approaching this as any particular use case, but from the place where thaere are cases where it's useful<br>
<emeyer> …But things are not posisble with how we do ennumeration now<br>
<oriol> for...in just does the normal JS thing, right? I thought we were talking about for...of<br>
<emeyer> fserb: This works when we query the properties, yes?<br>
<emilio> dbaron, my understanding is that `style.cssText = "font: ...;"; [...style].includes("font")` is `false`, but that's the same `.length` bit that I commented above<br>
<masonf> q+<br>
<emeyer> …There is a thing about people getting confused, but I would argue having both would make people more confused<br>
<oriol> +1 that having both is just more confusing<br>
<emeyer> …If you want just a sense of properties, having to do the extra work of knowing the shorthand means you can't get the bag of properties<br>
<emeyer> florian: The way I'm thinking about this is not about what makes sense in theory but what we can do that doesn't break compaibility<br>
<emilio> oriol, so yeah, my understanding is that what you said is correct, but that might be solvable in different ways depending on whether compat issues are in the specified style and computed styles<br>
<lea> q+ to say This discussion makes me think we also need a data structure that allows authors to read what is a shorthand of what. Also relevant to this future TAG principle: https://github.com/w3ctag/design-principles/issues/300<br>
<emeyer> …So I had a question to Ian, earlier, what kind of can or worms were you talking about?<br>
<emeyer> …Did you mean there are some properties where changing this breaks things?<br>
<astearns> ack florian<br>
<Zakim> florian, you wanted to react to IanK<br>
<emeyer> …Or is this more about the API shape itself?<br>
<astearns> zakim, close queue<br>
<Zakim> ok, astearns, the speaker queue is closed<br>
<emeyer> iank_: My thesis at the moment is that properties that have been around since time immemorial is more likely to have author depending ont he ennumeration<br>
<emeyer> …Things that are more recent, much less likely<br>
<masonf> q-<br>
<emeyer> …What we had to do with white-space was a lot more extensive<br>
<emeyer> florian: So I propose for all properties that exist, we do what we've been doing, but for any new property or newly shorthanded properties, we list both shorthand and longhand<br>
<dbaron> emilio, here's the actual testcase (thanks to Ian): https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cbody%3E%0A%3Cscript%3E%0Avar%20cs%20%3D%20getComputedStyle(document.body)%3B%0Afor%20(var%20i%20%3D%200%3B%20i%20%3C%20cs.length%20%3B%20%2B%2Bi)%20%7B%0A%20%20document.write(cs%5Bi%5D%20%2B%20%22%3Cbr%3E%22)%3B%0A%7D%0A%3C%2Fscript%3E<br>
<emeyer> …Is that something we can do, whether or not we should?<br>
<emilio> I think I have a proposal, if this is for the computed style<br>
<emeyer> andruud: Would that help?<br>
<lea> In terms of API design, that seems like the worst of all worlds. How are we supposed to explain this to authors?<br>
<emeyer> …In the position case, we don't touch that since it's been around since forever?<br>
<emeyer> florian: No, if we shorthandify that, we would do the new thing, but we don't do it to things like margin<br>
<emeyer> andruud: Can we research this can of worms without opening it?<br>
<emeyer> iank_: I don't know<br>
<lea> q?<br>
<matthieud> q+<br>
<emeyer> astearns: I've closed the queue since I'm not hearing consensus or conclusions<br>
<emeyer> emilio: We need to distinguish the computed and specified styles<br>
<emeyer> …We can have a shorthand list and the only thing we need to make sure is the whole longhand space can be represented by the shorthand<br>
<emeyer> iank_: I think it depends on how it's being used<br>
<oriol> +1 most of my concerns are about non-computed styles, since you can modify them<br>
<emeyer> emilio: I propose that if this is about the computed style, we can do this easily<br>
<emeyer> …If this is about the specified style, that's a bigger change<br>
<emeyer> …When the CSS parser parses white-space, it ends up with a bunch of longhands<br>
<emeyer> …We could make it not do that, but that would be a big change<br>
<matthieud> q-<br>
<emeyer> …Having a flag on a shorthand would be trivial-ish?<br>
<astearns> ack emilio<br>
<emeyer> dbaron: Ian and I have been test casing and one of the things I said earlier was wrong<br>
<emeyer> …`i in foo` is wrong for where the compatibility exists<br>
<emeyer> …it's more in `i to length`<br>
<emeyer> …The ennumeration order has the shorthands first and then the longhands<br>
<emeyer> …The problem may be computed-style only<br>
<masonf> The `white-space` compat problem we encountered was that `for(s of getComputedStyle)` was missing `white-space`.<br>
<astearns> ack lea<br>
<Zakim> lea, you wanted to say This discussion makes me think we also need a data structure that allows authors to read what is a shorthand of what. Also relevant to this future TAG<br>
<emeyer> …Again, we probably need more test cases to be sure we're talking about the right thing.<br>
<Zakim> ... principle: https://github.com/w3ctag/design-principles/issues/300<br>
<emeyer> lea: I think we have consusensus we don't want to stop shorthandifying properties<br>
<emeyer> …Breaking properties into BC/AD seems like the worst solution<br>
<emeyer> …Exceptions make APIs really hard to explain<br>
<emeyer> …By principle of least surprise and assuming most authors use lookup instead of ennumeration, we could make changes<br>
<emeyer> …We could really use methods that allow authors to ask what is a shorthand of what<br>
<astearns> +1 to introspection of shorthand/longhand relationships<br>
<emeyer> …This is also compatible with the TAG future design principle of allowing introspection<br>
<oriol> You can currently know what is a shorthand of what with the current API. The proposals here would break that.<br>
<emeyer> astearns: Sounds like we need more tests and finding the smallest can of worms we can open<br>
<lea> s/Exceptions make APIs really hard to explain/How are we supposed to explain this to authors? I'd much rather add one-off exceptions, but I'm not convinced we even need to do that./<br>
<emeyer> fantasai: There was also an issue around transition events<br>
<emeyer> dbaron: I think that's the harder half<br>
<emeyer> …That said, I think we made the easy half hard by talking about what it is instead of solving it<br>
<emeyer> …And I also think we still don't know<br>
<lea> s/We could really use methods that allow authors to ask what is a shorthand of what/There should be a data structure for authors to read what is a shorthand of what, so that if they're doing some complicated thing they at least can figure out what is happening, which is incredibly tricky right now (I’ve tried to do it!)./<br>
<emeyer> astearns: Leaving this for now<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8398#issuecomment-2160388896 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 11 June 2024 10:27:16 UTC