- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 23 Oct 2018 10:06:09 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Flow-relative syntax for 'margin'-like shorthands`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Flow-relative syntax for 'margin'-like shorthands<br> <emilio> Github: https://github.com/w3c/csswg-drafts/issues/1282<br> <r12a> s/multiple languages as a single language/multiple languages for a single font/<br> <emilio> fantasai: currently css assign values in shorthands to the physical longhands<br> <emilio> fantasai: it seems useful to make logical shorthands similarly convenient, which is useful for i18n<br> <emilio> fantasai: but we don't have a proposal for which kind of syntax we want to have for this<br> <emilio> fantasai: one's relative keyword, other is a bang keyword, others is a different property<br> <astearns> !no<br> <emilio> fantasai: one of the main restrictions is try to keep it sufficiently easy to type<br> <dbaron> I would be pretty strongly against a ! syntax for something that's part of the property (i.e., not changing cascading).<br> <emilio> fantasai: nothing on the thread seems to have stuck<br> <emilio> fantasai: can we come up with some idea?<br> <emilio> fantasai: other proposals were like global mode switchs, etc...<br> <emilio> fantasai: we could do some or multiple<br> <emilio> fantasai: [enumerates other solutions from the thread]<br> <emilio> addison: one of the challenges is when you go to make a rtl page layout you need to edit your stylesheet to flip your margins, ideally it'd be default<br> <myles_> q+<br> <emilio> TabAtkins: Something in the value space is maybe the best, like keywords<br> <emilio> TabAtkins: I'd be against punctuation, no precedent and hard to google, plus not compatible with CSSOM<br> <emilio> TabAtkins: similarly for the bang<br> <emilio> TabAtkins: nor mode switches, dbaron argued against it, serialization is also harder that way<br> <emilio> q+<br> <r12a> q+<br> <emilio> fantasai: typing relative is too long<br> <astearns> ack myles_<br> <dbaron> +1 to tab saying it should be in the regular value space<br> <emilio> myles_: Will the bang keyword be applicable on every property<br> <emilio> *?<br> <iank_> q+<br> <emilio> fantasai: only to some<br> <astearns> +1 to dbaron's +1 on regular value space<br> <dbaron> q+<br> <emilio> myles_: so part of the grammar of the specific properties, right?<br> <emilio> fantasai: yes<br> <emilio> myles_: it'd be cool if it works with variables<br> <emilio> fantasai: that'd be terrifying<br> <astearns> ack emilio<br> <emilio> TabAtkins: you should be able to drop a whole relative margin value in a variable<br> <TabAtkins> TabAtkins: And you *cannot* put bang values into variables.<br> <myles_> emilio: expanding shorthand into mulitple lonahands dpeending on syntax, like overflow, is not something that any othe rproperty has righ tnow. So it's goig to require specifying how yous erialize when you have all of th e8 logical and physical margins. IF you want the solution that peoplw ill implement fast, the best option is different properties. Then, all the machinery is there already.<br> <myles_> fantasai: how do we come up with a systematic way of coming up with a new property that is consistent, short, easy<br> <myles_> emilio: yes<br> <myles_> TabAtkins: we do "margin-se"<br> <myles_> emilio: or "logical-margin"<br> <myles_> fantasai: it's way too long. some peopl will put all of their stylesheets all of the time, and will stop using physical properties. It needs to be ergonomic enough that it's possible<br> <dbaron> 'margins', 'paddings' :-P<br> <myles_> florian: will we push back against tab here about puctuation? ~padding ~margin?<br> <jensimmons> it might be faster to implement, but if we hate the choice 10 years from now, it’s not a good idea<br> <myles_> TabAtkins: if its property names, my objection is different. The only thing is that would not be an ident anymore.<br> <myles_> florian: can we fix it?<br> <myles_> TabAtkins: potentially but its a syntax change. It would be better for it to fit kn the syntax.<br> <myles_> florian: if somebody is using a property that uses idents, this would break.<br> <myles_> TabAtkins: we try to not change syntax<br> <myles_> florian: this may warrant an exception<br> <myles_> TabAtkins: yes. I think we can come up with a prefix in alphabumeric that's short<br> <emilio> astearns: do we have anything more on that?<br> <astearns> ack r12a<br> <emilio> r12a: I agree with that fantasai and TabAtkins that it needs to be easy to type, I'd suggest `lmargin`<br> <jensimmons> q+<br> <myles_> +1 to not using "relative"<br> <emilio> r12a: I think `logical` is a much better word than `relative`<br> <cbiesinger> +1 for not using relative<br> <astearns> ack iank_<br> <emilio> iank_: Any of the bang syntax will probably have very funky interactions with CSSOM<br> <TabAtkins> I think `l` as a prefix works okay. I think we can reasonably prefix any word with that.<br> <emilio> iank_: setProperty has a different argument for `!important` and such<br> <astearns> ack dbaron<br> <fantasai> I don't like prefixing with alphanumeric because it's less obvious what's going on and it won't sort correctly.<br> <TabAtkins> *post*fixing with `l`?<br> <fantasai> we use prefixes for the real name of the property, and prefix relationships are about shorthands<br> <fantasai> postfixing makes it look like a different longhand of the physical shorthand<br> <astearns> q?<br> <emilio> dbaron: So I think we all don't like the various bang things. I guess I'm not 100% convinced we want different property names, I think having it in the value would be slightly nicer even if we need to sort out a bunch of CSSOM issues, though it might depend on whether we find appropriate names for the properties<br> <astearns> ack jensimmons<br> <emilio> dbaron: different properties is probably faster<br> <cbiesinger> q+<br> <emilio> jensimmons: some of the things suggested where the good syntax is the old thing that nobody uses 10 years from now<br> <emilio> jensimmons: so even if might be more efficient or easier to implement we should peek a name that is a good name<br> <majidvp> q+<br> <emilio> heycam: I feel like all of the syntax proposed so far is going to be a bit different and awkward, so I'm not sure the goal of finding a clean word is feasible<br> <emilio> jensimmons: I think lmargin is a bit more awkward than relative on the value<br> <dbaron> I guess another option is using a delimiter within the 'margin' value like 1em / 2em / 3em / 4em.<br> <emilio> jensimmons: Some of them feels smoother than others<br> <r12a> q+<br> <rachelandrew> q+<br> <emilio> fantasai: can you give us your opinion on the different proposal?<br> <emilio> jensimmons: I think -new is better than a new name, and keyword is better than a bang, but I can look at the list as we goo<br> <astearns> ack fantasai<br> <emilio> jensimmons: how does it look in 10 years is something to look into<br> <TabAtkins> schmlinss<br> <myles_> jensimmons: sticking a random letter in front of iframe hasn't seemed to hinder its adoption, it seems most people colloquially speak of iframes instead of frames<br> <emilio> fantasai: prefixing breaks the sort order, margin-something feels like a longhand analogous to margin-left or such<br> <jensimmons> iMargin? lol<br> <emilio> fantasai: I'm a little skeptical about prefixing / suffixing has the issue of making it relate to properties it doesn't relate to<br> <dbaron> q+<br> <emilio> *seem to relate<br> <astearns> ack cbiesinger<br> <TabAtkins> Allowed postfix punctuators in ident syntax: - or _ ^_^<br> <TabAtkins> margin-, margin_<br> <myles_> margin: ➡️<br> <emilio> cbiesinger: I think lmargin and such are a huge concern, we have some other messy margin<br> <emilio> majidvp: I think mode switch is the easiest. Is the concern about serialization really a problem? When do you have the problem?<br> <jensimmons> imargin = international margin<br> <cbiesinger> @mode "logical"; at the top?<br> <fantasai> cbiesinger, yes that's one option<br> <emilio> florian: we have some of that problem with box-sizing and such<br> <fantasai> cbiesinger, the other is a block like @media<br> <cbiesinger> block seems worse to me<br> <fantasai> cbiesinger, yeah I agree<br> <emilio> dbaron: I think we consider it a design mistake<br> <fantasai> cbiesinger, if we have a mode switch we might want to have a way to put a specific declaration into the other mode, though<br> <astearns> ack r12a<br> <emilio> s/it/box-sizing<br> <astearns> ack majidvp<br> <fantasai> s/consider it/consider box-sizing/<br> <emilio> r12a: dbaron proposed separators instead, maybe we should consider that?<br> <cbiesinger> fantasai: maybe but your escape hatch is margin-left<br> <astearns> ack rachelandrew<br> <fantasai> s/fantasai:/fantasai,/<br> <emilio> rachelandrew: From the POV of teaching this a keyword means that you can look at your code and know what I'm using here, seems to infer the intent best<br> <emilio> dbaron: I suggested using separators, assuming we do want to move everyone to that, so that you can do something like `margin: 1em / 2em / 3em / 4em`<br> <emilio> dbaron: It's somewhat obscure so it makes the distinction less obvious, but if it becomes the way to do it it may not be a problem/<br> <jensimmons> What Rachel just said makes me think that `margin: 10px 5px 15px 25px relative;` is more of a “equal” to `margin` today… changing to a different property infers that it’s a different thing<br> <emilio> fantasai: we use slashes on some places already, so not sure we could switch everyhwere<br> <r12a> q+<br> <astearns> ack dbaron<br> <emilio> dbaron: it doesn't need to be a slash, there are probably a number of those we haven't used yet<br> <cbiesinger> +1 for dbaron's suggestion<br> <emilio> dbaron: the other reason it sort of makes sense to me is that the delimiter indicates a different relationship between the different values<br> <jensimmons> also, should we go the other way — to match Grid — …. ???? Crazy. but also....<br> <emilio> myles_: looks like if you don't use slashes code work and it'd look just wrong in RTL<br> <fantasai> yes, jensimmons, we will go the other way to match Grid<br> <astearns> ack r12a<br> <emilio> TabAtkins: Since the direction is different it at least sometimes will look wrong<br> <fantasai> Grid is using the direction we picked out for logical 4-value syntaxes in general, we just never solved this particular syntax issue to have them :)<br> <emilio> r12a: So you still have to deal with serialization and such<br> <emilio> dbaron: yeah, that was emilio's concern, we need to solve that if we handle margins<br> <fantasai> It's interesting to note that the grid-area shorthand already uses slashes (and is logical)<br> <emilio> emilio: You also need to handle compressing and serializing when you specify all the 8 margins<br> <emilio> dbaron: you could condense those to two occurences to the margin shorthand, but it's a bunch of CSSOM work<br> <rachelandrew> there is an example of individual properties here for padding: https://codepen.io/rachelandrew/pen/OQrorW<br> <emilio> dbaron: that's the 'this will take longer to get done'<br> <rachelandrew> from https://www.smashingmagazine.com/2018/03/understanding-logical-properties-values/<br> <emilio> emilio: note that you also need to figure out how that interacts with the other sub-shorthands like margin-block / margin-inline<br> <emilio> TabAtkins: yeah I think finding something using property names would be maybe the better idea<br> <Bert> q+<br> <emilio> fantasai: I think you still need a switch to change to physical in specific cases, and whatever solution we choose needs to be workable for that<br> <fantasai> myles_: Mode switch at the top of the file, many CSS authors don't know CSS that well and just copy-paste, so mode switches would end up being problematic for them<br> <astearns> ack Bert<br> <emilio> myles_: It's harder for authors to understand mode-switches, and they'll just get it wrong<br> <fantasai> Bert: Said earlier that it might be a problem if margin expands to different properties based on whether there's a keyword or not. Is that true? Wouldn't it expand to all of them all the time.<br> <emilio> fantasai: thanks, I had missed it :-)<br> <fantasai> florian: Depending on the values, they are propagated to different values, but always expand out to the same set of longhands (all of them)<br> <fantasai> dbaron: At the specified value it is, but at the computed value level, the two sets of properties compute the same values<br> <fantasai> dbaron: The way we've added logical properties, they are distinct properties at the specified value level nd they both exist in the object model<br> <fantasai> Bert: If you set margin-start, it goes to margin-start<br> <fantasai> Bert: If you set 'margin, does it also set margin-start or only go to margin-top<br> <fantasai> dbaron: We're rying to find a syntax that sets the margin-start property<br> <fantasai> Bert: Is it necessary?<br> <fantasai> florian: ...<br> <fantasai> florian: We don't have a logical shorthand. If we want logical to be the default way to write style sheets, we need that.<br> <fantasai> astearns: Short answer is no the shrothand doesn't expand to all 8<br> <fantasai> dbaron: Having the shorthand somehow set margin-top so that it sets the logical thing, could be doable, but would have some very confusing results<br> <fantasai> florian: I didn't understnad that<br> <fantasai> Bert: Problem is that the 'margin' property doesn't reset the logical margins. Can that be changed?<br> <fantasai> Bert: Like font resets font-size-adjust even tough it's not mentioned<br> <fantasai> fremy: I'm not sure why it doesn't set<br> <fantasai> fremy: These values would never be used<br> <fantasai> fremy: It doesn't matter if margin resets them or doesn't<br> <fantasai> fremy: If the orde rin which you reset them is such that you have the logical ones after the other ones its fine.<br> <fantasai> dbaron: That would be one solution to part of the object model issues.<br> <fantasai> dbaron: others around serialization<br> <fantasai> fremy: Somewhere we have to find principles of doing this, and need algorithm for this<br> <fantasai> fremy: I ddin't find it yet<br> <fantasai> dbaron: Might be in a GH issue somewhere<br> <fantasai> dbaron: probably don't want to dig too far into CSSOM issues right now<br> <fantasai> astearns: This was a good background on all solutions we could consider, but doesn't sound like we'll resolve today<br> <fantasai> TabAtkins: Sounds like we're interested in a declaration-based syntax<br> <TabAtkins> More specific than declaration-level. Property-name or value-level. (So not declaration glyphs, or ! values, etc.)<br> <florian> fantasai: I think whether or not we need a mode switch, we will have a syntax ???<br> <myles_> "use logical;"<br> <myles_> (instead of "use strict")<br> <emilio> lol<br> <florian> fantasai: the reason the shorthand resets 4 or 8 of the longhands is actually still an open issue<br> <florian> s/the reason/whether/<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1282#issuecomment-432184161 using your GitHub account
Received on Tuesday, 23 October 2018 10:06:19 UTC