- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 20 Oct 2020 23:05:45 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `CSS Logical Properties`, and agreed to the following: * `RESOLVED: proposal from fremy: During serialization, each logical property group is considered, and shorthand values can be emitted instead of the longhands only if the all the longhands of the same mapping logic are present and consecutive (ignoring all properties that are not in the group). Otherwise, the shorthand is not used when serializing the properties in the group.` * `RESOLVED: proposal from fremy:During serialization, each logical property group is considered, and shorthand values can be emitted instead of the longhands only if the all the longhands of the same mapping logic are present and consecutive (ignoring all properties that are not in the group). Otherwise, the shorthand is not used when serializing the properties in the group.` <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: CSS Logical Properties<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/3030<br> <Rossen_> github: https://github.com/w3c/csswg-drafts/issues/3030<br> <tantek> fremy: main issue is that in CSS spec it defines how to serialize properties, contains a lot of tricks to merge declarations<br> <tantek> ... e.g. if you set all four border properties, the rules merge it to a single declaration<br> <tantek> ... when I looked at the logical properties, this is not as easy<br> <tantek> ... even if you have all four, you cannot always merge them into a single property<br> <tantek> ... it means you have to detect this case (e.g. inline-start) and do something smart<br> <tantek> ... logical and physical properties<br> <tantek> ... proposing a couple of rules to the serialization steps<br> <tantek> ... to only merge all four if they are of the same type<br> <tantek> ... while we were looking at this, a few more updates<br> <tantek> ... e.g. dbaron proposed if you set the margin property on the style attribute<br> <tantek> ... there is no reason to keep the margin-inline properties<br> <tantek> ... the logical ones<br> <fantasai> (because they have all now been overridden)<br> <tantek> ... proposal: make sure that the grouping would work<br> <tantek> ... making sure when you set things you override propertly<br> <emilio> q+<br> <tantek> s/propertly/properly<br> <tantek> emilio: Gecko has the concept of logical property groups<br> <tantek> ... we added it to the spec<br> <tantek> ... this concept already exists<br> <tantek> ... e.g. border-inline-start:10px; border-start:20px;<br> <tantek> ... Gecko will do the right thing<br> <tantek> ... the concept is already in the spec. this is an obvious bugfix<br> <tantek> fremy: the link you sent sounds like exactly what I'm proposing that seems fine<br> <Rossen_> See the refs for https://drafts.csswg.org/css-logical-1/#logical-property-group<br> <tantek> s/the link you sent/emilio's link https://drafts.csswg.org/css-logical-1/#logical-property-group<br> <tantek> fantasai: we should make sure ... interleaved ... then that can be folded into a shorthand<br> <emilio> https://drafts.csswg.org/cssom/#set-a-css-declaration is already using this concept<br> <emilio> We should use it from serialization<br> <tantek> ... the other part of your proposal, if a shorthand is set, then you can drop any previous declarations that set any property in that logical property group<br> <tantek> fremy: that sounds correct to me<br> <tantek> Rossen_: do we not have this currently specified? the part you just added fantasai ? in terms of the behavior?<br> <tantek> fantasai: I think in terms of how everything is supposed to behave like cascade, etc. is defined. this is about CSSOM interaction<br> <tantek> Rossen_: so this is going into CSSOM then? mostly?<br> <tantek> fantasai: I guess so. emilio and I will work it out<br> <tantek> Rossen_: any other opinions?<br> <tantek> emilio: I need to look a bit more closely at the replace all the physical longhands<br> <tantek> ... because there are more complex cases<br> <tantek> ... e.g. shorthands that only override two properties<br> <tantek> ... like the serialization stuff when stuff is interleaved, that's good<br> <tantek> ... the replace of the existing physical properties, that may or may not be confusing<br> <tantek> fantasai: I think they are two separate proposals that happen to be in the same issue<br> <tantek> Rossen_: can you separate them for resolutions?<br> <fantasai> First proposal from fremy: During parsing of a css declaration block, shorthands (like margin and all) expands only to the set of longhand (grouped by mapping logic: so either logical or physical) required to describe their value, and by default resort to use physical properties if both sets are possible. Note that they can only expand if they do not contain var() substitutions.<br> <fantasai> Second proposal from fremy: During serialization, each logical property group is considered, and shorthand values can be emitted instead of the longhands only if the all the longhands of the same mapping logic are present and consecutive (ignoring all properties that are not in the group). Otherwise, the shorthand is not used when serializing the properties in the group.<br> <tantek> Rossen_: please read the first one, which is about the behavior specifying, and how declaration blocks behave between shorthands and longhands and logical properties<br> <tantek> fantasai: looks like I'm finding more pieces of it<br> <tantek> emilio: the first one I assume every browser already does that<br> <emilio> s/emilio/fremy<br> <tantek> ... it's not clear from the spec, but I assume that should work regardless<br> <fantasai> Third piece from fremy: When removing a shorthand property, all the longhand associated with that shorthand should be removed, regardless of their mapping kind.<br> <TabAtkins> +1, all sound good<br> <fantasai> Fourth piece from dbaron: appending a shorthand property could set all of its constituent shorthands of one mapping logic and also remove all of the constituent shorthands of the other.<br> <tantek> Rossen_: any objections to accepting this first proposal<br> <tantek> emilio: q, we are talking about shorthands that map to both physical and logical properties? but those do not exist in browser today<br> <tantek> fremy: it's possible, back them we had proposal for margin, I don't know if we still have that<br> <tantek> fantasai: we never figured out a syntax that was appropriate<br> <tantek> fremy: that was mostly to make sure that case worked<br> <tantek> ... I don't think it's wrong to add this even if we don't have the mechanism<br> <tantek> emilio: not saying it's wrong, just possibly confusing<br> <tantek> how would you test it?<br> <tantek> RESOLVED: proposal from fremy: During serialization, each logical property group is considered, and shorthand values can be emitted instead of the longhands only if the all the longhands of the same mapping logic are present and consecutive (ignoring all properties that are not in the group). Otherwise, the shorthand is not used when serializing the properties in the group.<br> <tantek> fremy: mostly the loop needs to be modified<br> <tantek> Rossen_: wanting make sure everyone is comfortable with accepting this change<br> <emilio> yeah, +1 for the serialization change, that's unobjectionable imo<br> <fremy> https://www.w3.org/TR/cssom-1/#serialize-a-css-declaration-block<br> <tantek> ... without delaying people too much, any objections or wait til Thu morning?<br> <tantek> fremy: for me both is fine<br> <Rossen_> RESOLVED: proposal from fremy:During serialization, each logical property group is considered, and shorthand values can be emitted instead of the longhands only if the all the longhands of the same mapping logic are present and consecutive (ignoring all properties that are not in the group). Otherwise, the shorthand is not used when serializing the properties in the group.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3030#issuecomment-713189338 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 20 October 2020 23:05:47 UTC