Skip to content
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

[css-logical] Flow-relative syntax for margin-like shorthands #1282

Open
fantasai opened this issue Apr 23, 2017 · 48 comments
Open

[css-logical] Flow-relative syntax for margin-like shorthands #1282

fantasai opened this issue Apr 23, 2017 · 48 comments

Comments

@fantasai
Copy link
Collaborator

@fantasai fantasai commented Apr 23, 2017

CSS currently assigns the values in the margin/padding/border shorthand to their physical longhands, i.e.

  margin: 1em 2em 3em 4em;

is equivalent to

  margin-top: 1em;
  margin-right: 2em;
  margin-bottom: 3em;
  margin-left: 4em;

I'm pretty sure we want some equivalent syntax for assigning into the logical longhands instead, but what should that be?

The current proposal is to put a keyword in front of the 4 values, like

  margin: relative 1em 2em 3em 4em;

Another possibility is to use a !keyword:

  margin: 1em 2em 3em 4em !relative;

or to create a new property in its place:

  margin-relative: 1em 2em 3em 4em;

or use some entirely as-yet-unused symbol or syntax.

And of course the exact keyword, if one is used, is up for debate as well; shorter would be better. People will be drawing up entire style sheets that use almost exclusively flow-relative properties, so this needs to be designed for comfort under frequent use.

Ideas welcome~

@chharvey
Copy link

@chharvey chharvey commented Apr 23, 2017

I agree with the current proposal, a keyword in front of the values. I personally like relative better than logical, because I don't think this spec really has anything to do with "Logic" per se… (the study of truth and argument forms).

A couple of points:

  1. the !relative keyword isn't already part of the standard CSS syntax and doesn't (and shouldn't) apply to all properties like the !important keyword does.
  2. adding a new property like margin-relative would have to set (or reset) its sub-properties, but sub-property names are usually extensions of the shorthand. So a margin-relative shorthand would imply its sub-properties are things like margin-relative-block-start, margin-relative-block-end, etc. There are exceptions, though, in the case of grid-gap setting grid-row-gap and grid-column-gap—property names that still make me mad!
@MurakamiShinyu
Copy link

@MurakamiShinyu MurakamiShinyu commented Apr 26, 2017

margins for logical shorthand -- is this bad idea?
I think plural word for shorthand makes sense, and columns is shorthand for column-* .

@chharvey
Copy link

@chharvey chharvey commented Apr 26, 2017

@MurakamiShinyu — I see where you are going with this, but it could potentially become often confused with margin, which already exists. (Did they mean to put margins or was that a typo? Which one is relative again, I can't remember? etc etc…)

I think with a keyword such as relative prepended to the values, the code indicates very clearly and unambiguously what was intended—at the cost of just a few more bytes.

columns is okay because there is no column property, but in retrospect I would probably have preferred column for consistency.

@MurakamiShinyu
Copy link

@MurakamiShinyu MurakamiShinyu commented Apr 27, 2017

I admit it's a crazy idea: 'margins' stands for "margin's writing-mode relative shorthand". But there is one advantage: 'margins' is easier to type than 'margin-relative' or 'margin: relative ...'. My concern is that people may feel troublesome to type a lot of 'relative' when css-logical-props becomes widely available.

@bradkemper
Copy link

@bradkemper bradkemper commented Apr 27, 2017

I like the idea of !keyword that could be added to any 4-value clockwise shorthand (and their 3-value, 2-value, and 1-value versions). How about just an unadorned !, to make it an even easier, quicker switch? So...

border-radius: 2em 1em 4em / 0.5em 3em !;

is equivalent to

border-block-start-inline-start-radius:  2em 0.5em;
border-block-start-inline-end-radius:    1em 3em;
border-block-end-inline-end-radius:      4em 0.5em;
border-block-end-inline-start-radius:    1em 3em;

Adding the ! to a 1-value version, like margin: 0 ! wouldn't have any noticeable effect, but should be allowed.

@cork
Copy link

@cork cork commented Apr 27, 2017

Why not go the same route as for box-sizing? So something like margin-mode: relative;

Then when the support gets common you could just do:

* { margin-mode: relative; }

div {
  margin: 1em 2em 3em 4em;
}

#exception {
  margin-mode: physical;
  margin: 1em 2em 3em 4em;
}
@SebastianZ
Copy link
Contributor

@SebastianZ SebastianZ commented Apr 27, 2017

Having a margin-mode property would go hand in hand with the current proposal of margin: relative 1em 2em 3em 4em;, i.e. be another longhand property for margin. The disadvantage of this is that its value infuences the handling of the other values, which might be unexpected.

I totally agree with @chharvey's comment that !relative (or ! for the same reason) and margin-relative have downsides.

Sebastian

@inoas
Copy link

@inoas inoas commented Apr 27, 2017

If I got the ticket right (because the opening post doesn't really explain):

I think I have already answered via twitter... but I am suggesting transpose again.
And from an author point of view I would not care it it was margin-transpose: val val val val or margin: val val val val transpose;

@chharvey
Copy link

@chharvey chharvey commented Apr 27, 2017

@cork I do like your idea of margin-mode. That way the syntax of the margin property would not have to change. The syntax of margin-mode would be

syntax:    [ physical | relative ] | inherit | initial | unset

initial:   physical

inherited: true

One upside would be that you wouldn't have to change the margin property when you want to change the mode—taking advantage of the Cascade, resulting in more readable diff.

Alas, a recent change of the spec indicates a different order when relative values are used.

p {
  margin: 1px 2px 3px 4px;
  /* equivalent to standard order (top, right, bottom, left)
  margin-top:    1px;
  margin-right:  2px;
  margin-bottom: 3px;
  margin-left:   4px; */
}
p.relative {
  margin-mode: relative; /* <-- added */
  /* equivalent to new order:
  margin-block-start:  1px; `top`    in LTR-TB
  margin-inline-start: 2px; `left`   in LTR-TB
  margin-block-end:    3px; `bottom` in LTR-TB
  margin-inline-end:   4px; `right`  in LTR-TB */
}

So in the example above, by adding margin-mode: relative;, you would still have to add margin: 1px 4px 2px 3px; in the second ruleset to keep things the same.

Another downside: you would have to have corresponding "mode" properties for the following, which could be a bit much:

  • padding-mode
  • border-width-mode
  • border-style-mode
  • border-color-mode
  • border-radius-mode (related: #491)
@MatsPalmgren
Copy link

@MatsPalmgren MatsPalmgren commented Apr 27, 2017

I suspect margin-mode might be hard to implement - it's easier if you know at parse time how a property is supposed to be interpreted.

I like the !relative or ! proposal best so far. It would make it possible for multi-value properties to have both physical/logical values in the same declaration (if we want that). For example:
background-position: 10px, ! 20px, 30px, ! 40px;

I'm concerned though, that this might lead to new CSS properties being defined as physical-first and require ! for logical values. This would be unfortunate since logical values are superior in most cases. Perhaps ! could be interpreted as a general physical/logical switch though, so that for example grid-gap: ! 10px 20px; would set 10px on the longhand that corresponds to the vertical axis?

@MurakamiShinyu
Copy link

@MurakamiShinyu MurakamiShinyu commented Apr 28, 2017

I like the idea of #1279: margin-block is shorthand for margin-block-start + margin-block-end, and margin-inline is shorthand for margin-inline-start + margin-inline-end.
These will be often more useful than single margin flow-relative shorthand, and I am ok with adding 'relative' keyword when the margin shorthand is needed. Or how about the following syntax:

  margin: [ block <'margin-block'> || inline <'margin-inline'> ]

e.g.

  margin: block 1em 3em inline 2em 4em;
@inoas
Copy link

@inoas inoas commented Apr 28, 2017

I have to raise my voice and say that short symbolic like a punctuation (!) mark are really not good practice IMHO. The gains in saved typing are minimal and the symbol does not transport its meaning. It pretty much feels regexpy and IMHO CSS should not be.

I'd favour extra logical properties. Aka margin and padding are absolute and margin-relative and padding-relative are not (dimensions for position and dimensions-relative or similar could be added later).

That is a very clear and easy interface for authors and there is no clash between old properties and new properties. Authors can also use margin and margin-relative independent of each other and thus are not breaking css parsing of older browsers!

So I really like @fantasai initial proposal.

@fantasai
Copy link
Collaborator Author

@fantasai fantasai commented Apr 28, 2017

Wow, okay! Here's some responses:

  • I think it's pretty sure we are not doing a separate property to control interpretation of shorthands. First, as @MatsPalmgren mentions, this is harder to implement--we really want a switch that's syntactically part of the declaration and lets us handle this at parse time. Secondly, it creates an "action at a distance" effect, which is likely to result in confusion and errors as multiple parts of a stylesheet interact.
  • Agree that margin vs margins is going to be confusing and we shouldn't go that route. :) For languages that pluralize with s such as English, it's a mostly-unnoticeable morpheme and not something we ever want to be a distinguishing factor in any CSS syntax.
  • I agree with @inoas that using just ! alone is likely a bit too obscure (and also a bit too general, imho, as we use !keyword for other things like !important). However, I also agree with the concerns about !relative or relative or -relative potentially being too much of a typing burden; as I mentioned in the OP, we do expect this to become the default mode of assignment for many authors, so I'd say it's fair to trade a bit of obscurity for a bit of typing efficiency.
  • Wrt @MatsPalmgren’s comment about moving to flow-relative directions... new CSS models like Grid and Flexbox tend to use flow-relative directions to begin with, however for anything that's analogous to an existing CSS feature like margin or background-position, consistency is a more important consideration. Hence scroll-snap-margin is physical, even though we would have preferred it to be flow-relative.
  • transpose is not a bad name, the main downside is that it doesn't indicate what the mapping is! There's a distinct possibility that more mappings could be added in the future--Writing Modes already includes both flow-relative and line-relative mappings.
  • Fwiw, margin-block and margin-inline were resolved to add already, I just forgot to make the edits. :( I'll go do that now. ;)
  • Wrt interleaving keywords... one of the great things about the 4-value shorthand syntax is the way that it can use 1, 2, 3, or 4 values to assign to the four sides, and pairs things up in ways that both correspond to common use cases and yet also unroll syntactically in a consistent way. I think we want to keep those qualities; and also be consistent with Grid which already has a 4-value shorthand in grid-area.
@MurakamiShinyu
Copy link

@MurakamiShinyu MurakamiShinyu commented Apr 29, 2017

Agree with @fantasai. Now I feel original relative keyword or -relative suffix were better. However, I think the word relative also has obscurity. People may think the relative is related to position: relative, and may not notice that it is about "flow-relative-directional".
(For this reason I think logical keyword might be better then relative)

How about margin-bi (suffix -bi, stands for "block and inline")? I know this is exceptional in CSS property naming convention (avoid abbreviations and use complete words), but has the following advantages:

  • easy to type, only three additional characters to the original name
  • we have *-block and *-inline properties, and making the combined shorthand names using the first letters of "block" and "inline" will be easy to understand
  • "bi" indicates the order of values, block is first then inline, and convenient to remember the value syntax

and CSS already has abbreviations in some keywords, e.g., "rl" (for "right to left direction") in vertical-rl value of writing-mode, and using "bi" for "block and inline directions" will be not too bad.

@fantasai fantasai closed this in 1cc3fc2 Apr 30, 2017
@fantasai
Copy link
Collaborator Author

@fantasai fantasai commented Apr 30, 2017

Sorry; typo in commit message. :/

@fantasai fantasai reopened this Apr 30, 2017
@chharvey
Copy link

@chharvey chharvey commented May 7, 2017

If the keyword route is decided upon, can the syntax allow it to be at the beginning or end of the declaration? Inspired by box-shadow inset (that is, inset of the box-shadow, not the new inset positioning property).

So for margin it would be

relative? && [ <length> | <percentage> | auto ]{1,4}
@bradkemper
Copy link

@bradkemper bradkemper commented May 22, 2017

Weird. My comment was posted to the wrong page

@bradkemper
Copy link

@bradkemper bradkemper commented Jun 9, 2017

I really don't think we should have margin-* or *-margin as a property or !keyword for this. Because then you would need to do it for padding, border (and border-width, border-style, and border-color), border-radius, and many others. It should be a single !keyword that can be used for all (I agree that action-at-a-distance is bad for this).

If it is to be typed a lot (and really, that is the hope, that authors are considering bi-di and writing mode all the time), then it needs to be very short. I would say no more than 2-3 letters long. I still prefer an unadorned ! for that reason, even though it would more likely lead to authors adding it without understanding why.

@fantasai fantasai changed the title [css-logical] Syntax for margin-like shorthands [css-logical] Flow-relative syntax for margin-like shorthands Jun 20, 2017
@jonjohnjohnson
Copy link

@jonjohnjohnson jonjohnjohnson commented Apr 11, 2018

I know there are multiple arguments against having a separate property that controls interpretations of shorthands for reasons like implementation difficulty or "action at a distance", but isn't that akin to how box-sizing works? I know there have been discussions about properties like box-size (#820), so wouldn't something like box-mode: [ physical | relative ] be what we'd all get behind if this was part of the initial proposal for box shorthands?

I'd imagine anyone who wants to use logical features would be "all in", not needing to set individual "modes" and wanting something like box-mode to cascade/inherit and set interpretation for ALL shorthand box properties such as border-width,padding,margin,border-radius, background-position, etc...

@xfq
Copy link
Contributor

@xfq xfq commented May 13, 2018

@fantasai wrote:

I agree with @inoas that using just ! alone is likely a bit too obscure (and also a bit too general, imho, as we use !keyword for other things like !important). However, I also agree with the concerns about !relative or relative or -relative potentially being too much of a typing burden; as I mentioned in the OP, we do expect this to become the default mode of assignment for many authors, so I'd say it's fair to trade a bit of obscurity for a bit of typing efficiency.

Even if we expect this to become the default mode of assignment for many authors, I would still prefer clarity & readability to typing efficiency, because the latter can be mitigated by code completion and code snippets in authoring tools, and IMHO shouldn't be a major concern (comparing with readability & less surprise for authors who are not familiar with flow-relative properties) when designing a language like CSS.

@fantasai
Copy link
Collaborator Author

@fantasai fantasai commented Aug 17, 2018

I agree strongly with @bradkemper’s comment: this needs to be generic enough that it doesn't get confused with property-specific value spaces, and it also needs to be convenient enough that authors using flow-relative syntaxes are not at a significant ergonomic disadvantage compared to authors using physical syntaxes.

Another option would be to have a longer per-declaration !keyword (for clarity) but also a higher-level syntax similar to @namespace (changing the default interpretation of an entire stylesheet) or @media (changing the default interpretation in a block). This would be the most convenient, at the cost of making it possibly confusing if someone is copy-pasting style rules out-of-context.

@fantasai
Copy link
Collaborator Author

@fantasai fantasai commented Aug 17, 2018

A third option would be to have some other not-currently-used single punctuation character somewhere in the declaration, to indicate flow-relative mapping, e.g.

margin: 1em 2em 3em 4em; /* physical mapping */
~margin: 1em 2em 3em 4em; /* logical mapping, option A */
margin ~: 1em 2em 3em 4em; /* logical mapping, option B */
margin :~ 1em 2em 3em 4em; /* logical mapping, option C */

This is convenient to type and safe for out-of-context quoting, at the cost of being more obscure.

@elad2412
Copy link

@elad2412 elad2412 commented Nov 30, 2018

I think let's make life easier!
The Idea(use some of the idea of @fantasai and @chharvey ):
add a new property that will declare the type of properties and will have inherit as default.
add now all the page will be according to the HTML definition.

flow-mode: physical /default value/ or logical;

html{
   flow-mode:physical; 
       /*or*/
   flow-mode:logical;
}

.box{
  /*will be according to the HTML flow-mode value*/
   margin:10px 5px 6px 3px;
  padding:5px 10px 2px 7px;
}
@Loirooriol
Copy link
Collaborator

@Loirooriol Loirooriol commented Nov 30, 2018

The problem is that it's bad if you need to know whether the shorthand will expand into physical OR logical longhands at specified-value time, but this depends on the computed value of flow-mode (or writing-mode in your second idea, but this would be too hacky).

However, something similar to https://drafts.csswg.org/css-variables-1/#variables-in-shorthands could be done:

  • The shorthand expands into all physical AND logical longhands (the order does not matter)
  • The specified value of the longhands is set to a special, unobservable to authors "pending-logical-resolution value"
  • This value must then be cascaded as normal
  • At computed-value time, the shorthand must be parsed and the longhands must be given their appropriate values at that point according to the computed value of flow-mode.
  • Pending-logical-resolution values must be serialized as the empty string, if an API allows them to be observed.

It think this would more or less work, but it would be a breaking change:

element.style.margin = "1px 2px 3px 4px";
element.style.marginTop;

Currently it produces "1px", but would become "" because at specified-value time it's not known whether the 1px will be set to margin-top or margin-block-start.

So IMO it would be simpler and less problematic to decide between logical or physical via syntax instead of via the computed value of another property.

@argyleink
Copy link
Contributor

@argyleink argyleink commented Jun 9, 2020

What if the scope of the request to opt into logical resolutions was file scoped? Then it couldn't leak out into other uses of margin (imports, 3rd party styles, etc) while still allowing current shorthand to upgrade.

Here's a terrible example but hopefully it articulates the intent for us to talk and bikeshed about it?

@logical;

p {
  margin: 1ex 1ch;  
}

/* 
p {
  block-start: 1ex; 
  inline-end: 1ch; 
  block-end: 1ex; 
  inline-start: 1ch; 
}
*/

Open questions:

  1. do we have any file scoping mechanisms at the moment or is this asking for a lot of browser internal work?
  2. is leaking only something I'm concerned about when thinking about options like
    html { 
      flow-mode: logical;
    }

I'd also love to see this thread spin up again! Share your thoughts 👍

@una
Copy link
Contributor

@una una commented Jun 9, 2020

I think it makes sense to set the flow-mode on an element instead of on a file. File settings aren't common in CSS like they are in JS and feel more arbitrary than setting flow-mode on a specific parent. We shouldn't be conflating file architecture with flow intention, especially since a common CSS architecture includes includes (no pun intended). This feels more confusing than it needs to be.

I feel that the example from @elad2412 makes the most sense in this case, with

html{
   flow-mode:physical; 
       /*or*/
   flow-mode:logical;
}

I don't think this necessarily competes with element.style.margin = "1px 2px 3px 4px";. That would still be valid, inclusive of flow-mode.

@Loirooriol
Copy link
Collaborator

@Loirooriol Loirooriol commented Jun 9, 2020

I don't think this necessarily competes with element.style.margin = "1px 2px 3px 4px";

@una What if then you read element.style.marginTop? How do we expand the margin shorthand at specified-value time if the expansion depends on the computed value of flow-mode?

@una
Copy link
Contributor

@una una commented Jun 9, 2020

@Loirooriol

@una What if then you read element.style.marginTop? How do we expand the margin shorthand at specified-value time if the expansion depends on the computed value of flow-mode?

element.style.marginTop would act like marginStart if the parent has a flow-mode: logical.

@Loirooriol
Copy link
Collaborator

@Loirooriol Loirooriol commented Jun 9, 2020

Ah, so you want the expansion to depend on the computed flow-mode of the parent element, instead of the element itself? Then, what if the flow-mode of the parent changes after expanding margin: 1px 2px 3px 4px? Should we keep track of the original shorthand declaration, so that it can be expanded again with the new mode? Or should we just keep the longhands of the old expansion?

@una
Copy link
Contributor

@una una commented Jun 9, 2020

@Loirooriol yes, I would expect if at any point, logical flow was added to the parent, the margins would become logical. This would also make it easier to port over codebases that set styles in JS to logical properties.

Order wouldn't matter here in terms of when the properties are adjusted -- the browser would parse the margins differently based on flow-mode. flow-mode will inherit to the parent, unless it is reset on the given element, so it's possible to have logical flow in a parent and physical flow in a child.

For the expansion example, the expanded sequence will always be rendered in the same flow-mode as any other margin set on the element, so it shouldn't collide. This is true for physical margin properties (top, left, bottom, right) as well ad logical properties.

In the case that flow-mode is set to physical, and a logical value is set (margin-inline-start, margin-block-start, etc.), the logical value will be converted to its physical counterpart of margin-left, margin-top, etc.

When no flow-mode is set on any element up the tree, the default flow modes for margin-top vs. margin-block-start apply.

@faceless2
Copy link

@faceless2 faceless2 commented Jun 9, 2020

Funny, I hadn't seen this thread until its resurrection. I've recently been dealing with the equivalent properties in PDF, which are always ordered in logical order - and personally, I hate it. Mainly for the reason that @Loirooriol raises two posts above - the meaning of the property value now cannot be determined without going up through the hierarchy to check the writing-mode of the ancestors. It makes it harder to visually inspect CSS to know what it means, it makes it harder to move nodes around in the tree, and it makes it harder to import styles from external sources.

This last point matters; if we were doing something like this 20 years ago it would be different. But I think it's fair to say there's an established body of CSS out there that uses the margin shorthand. If the way that property is parsed can now be changed by altering an ancestor, I predict that for someone, somewhere, it will cause an awful lot of pain (note I'm presuming that flow-mode is inherited, which seems to be the intent).

For that reason, I agree 100% with @Loirooriol's points above, and personally would lean towards @fantasai's original proposal of using a magic ident: margin: logical 1px 2px 3px 4px or similar. If you have to do this every time you want to specify margins, paddings or borders in logical order, it's a bit more verbose. That sucks, but only a little. However on the plus side, it's completely bulletproof against unintended side-effects.

tzhelyazkova added a commit to wmde/wikit that referenced this issue Aug 4, 2020
We can't use margin and padding because css logical properties
does not support them yet
w3c/csswg-drafts#1282
tzhelyazkova added a commit to wmde/wikit that referenced this issue Aug 5, 2020
We can't use margin and padding because css logical properties
does not support them yet
w3c/csswg-drafts#1282
tzhelyazkova added a commit to wmde/wikit that referenced this issue Aug 5, 2020
We can't use margin and padding because css logical properties
does not support them yet
w3c/csswg-drafts#1282
wiese added a commit to wmde/wikit that referenced this issue Aug 5, 2020
We can't use margin and padding because css logical properties
does not support them yet
w3c/csswg-drafts#1282
@r12a
Copy link
Contributor

@r12a r12a commented Sep 30, 2020

Logical shorthands really ought to be used by everyone, every time they set up margins, because even if content is in a horizontal, LTR text flow it may be translated into something else that isn't. I've been thinking how to make it as easy as possible for content authors to switch.

Ideally, we'd just make margin adopt logical rather than physical ordering. However, although it would probably make less breakage than you might expect, it will probably still cause some. So it would be good to come up with something that is as close to that as possible, and is very simple to type.

Initially, typing 'logical' appealed to me, since it's clear, but then i realised that it positions this approach as the exception, rather than the rule. It's also a pain to type 'logical' every time you want to define a margin with a shorthand (which for me is much of the time).

So how about something like creating an lmargin property name? It's 1 extra character only. Maybe that's as close as we can get to making this painless for content authors to adopt?

@MurakamiShinyu
Copy link

@MurakamiShinyu MurakamiShinyu commented Sep 30, 2020

I wrote a similar idea, #1282 (comment):

How about margin-bi (suffix -bi, stands for "block and inline")? I know this is exceptional in CSS property naming convention (avoid abbreviations and use complete words), but has the following advantages:

  • easy to type, only three additional characters to the original name
  • we have *-block and *-inline properties, and making the combined shorthand names using the first letters of "block" and "inline" will be easy to understand
  • "bi" indicates the order of values, block is first then inline, and convenient to remember the value syntax

I think the naming margin-* is better than lmargin because:

  • we have already margin-block and margin-inline shorthand properties, and the naming lmargin is not consistent with those.
  • lmargin will be mistaken for the left margin.
  • when property names are alphabetically sorted, lmargin and other margin properties become separated, so suffix is better than prefix.

If "-bi" suffix is not good, other candidates would be:

  • margin-fr - "fr" stands for "flow relative"
  • marginf - shorter suffix for "flow relative". I think the suffix "f" is better than "l" (logical) or "r" (relative) that will be mistaken for "left" or "right"
@r12a
Copy link
Contributor

@r12a r12a commented Oct 15, 2020

we have already margin-block and margin-inline shorthand properties, and the naming lmargin is not consistent with those.

Point taken.

lmargin will be mistaken for the left margin.

Possibly, though i think people will learn pretty quickly.

when property names are alphabetically sorted, lmargin and other margin properties become separated, so suffix is better than prefix.

Good point.

If "-bi" suffix is not good, other candidates would be:

Hmm. I think the shorter the better. Personally i'd much rather not reach for the hyphen, if possible. (I often miss.)

@Dan503
Copy link

@Dan503 Dan503 commented Oct 15, 2020

What about margin-logical: 10px 20px?

I think that is better than margin: logical 10px 20px.

margin-logical can be auto-completed with autocomplete in every editor that features CSS autocomplete. It also aligns with margin-block and margin-inline.

margin: logical on the other hand is much less likely to be widely supported in CSS autocompletion implications.

@normanr
Copy link

@normanr normanr commented Oct 16, 2020

Building on @argyleink's suggestion, it could also be written as a nested at-rule, eg:

@flow-mode(logical) {
  p {
    margin: 1ex 1ch;  
  }
}
@r12a
Copy link
Contributor

@r12a r12a commented Oct 16, 2020

margin-logical can be auto-completed with autocomplete in every editor that features CSS autocomplete. It also aligns with margin-block and margin-inline.

After consideration, i do rather like this, even though it has a hyphen, for the reasons @Dan503 mentions. It also gets around the difficulties of finding single letter abbreviations that convey the intended meaning.

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

Successfully merging a pull request may close this issue.

None yet