language feature request, block versions of css shorthand

[xenoterracide]

context, I'm a full stack developer (including ops) but I spend most of my time doing backend programming. This means that when it comes to (s)css I often have to look things up because it is sometimes months between doing any real frontend programming.

I especially have problem with idiomatic css for the various 4/2 arg properties, I'm referring to margin/padding. The fact that padding-top: padding-left, isn't the exact same thing as setting the 4/2 param versions doesn't really help. I can also never remember the order. I'd like to be able to write the following in scss

margin: {
    top: 25px
    right: 50px
    bottom: 75px
    left: 100px
}

and have it compile to

    margin: 25px 50px 75px 100px;

excluded properties should compile to 0.

I can see an argument made for allowing this as well ( I don't like top-bottom, but a better term currently escapes me... (colleague proposed x/y or x-axis/y-axis)

margin: {
    side: 5px; // maybe right-left: instead
    top-bottom: 10px;
}

which could compile to

margin: 10px 5px;

I think perhaps in the case where you want to override a single property in something that has been written like this...

@mixin myMargin {
    top: 25px
    right: 50px
    bottom: 75px
    left: 100px
 }
.bar {
   margin: { @include myMargin; top: 50px; }
}

would compile to

    margin: 50px 50px 75px 100px;

padding would be the same.

for flexbox

flex: none | [ <'flex-grow'> <'flex-shrink'>? || <'flex-basis'> ]

 flex: {
    grow: ...
    shrink: ...
    basis: ...
}

otherwise behaving as above.

I think that this allows code to be more readable, if more verbose, while still compiling to a consistent variant

[xzyfer]

This is very close to nest properties. http://sass-lang.com/documentation/file.SASS_REFERENCE.html

…

On Thu., 24 May 2018, 7:08 pm Caleb Cushing, ***@***.***> wrote: context, I'm a full stack developer (including ops) but I spend most of my time doing backend programming. This means that when it comes to (s)css I often have to look things up because it is sometimes months between doing any real frontend programming. I especially have problem with idiomatic css for the various 4/2 arg properties, I'm referring to margin/padding. The fact that padding-top: padding-left, isn't the exact same thing as setting the 4/2 param versions doesn't really help. I can also never remember the order. I'd like to be able to write the following in scss margin: { top: 25px right: 50px bottom: 75px left: 100px } and have it compile to margin: 25px 50px 75px 100px; excluded properties should compile to 0. I can see an argument made for allowing this as well ( I don't like top-bottom, but a better term currently escapes me... (colleague proposed x/y or x-axis/y-axis) margin: { side: 5px; // maybe right-left: instead top-bottom: 10px; } which could compile to margin: 10px 5px; I think perhaps in the case where you want to override a single property in something that has been written like this... @mixin myMargin { top: 25px right: 50px bottom: 75px left: 100px } .bar { margin: { @include myMargin; top: 50px; } } would compile to margin: 50px 50px 75px 100px; padding would be the same. for flexbox flex: none | [ <'flex-grow'> <'flex-shrink'>? || <'flex-basis'> ] flex: { grow: ... shrink: ... basis: ... } otherwise behaving as above. I think that this allows code to be more readable, if more verbose, while still compiling to a consistent variant — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2524>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjZWBSDtqjhaGsJjcC8y3bqC1Mijb0sks5t1ukbgaJpZM4UMpI2> .

[ArmorDarks]

I recommend just to not use shorthands at all. You would save a lot of time, especially when it comes to background and font shorthands, which are overriding more than some could think.

In other words, just always use:

margin-top: 25px;
margin-left: 15px;
margin-right: 15px;

This way you'll be sure you won't ever override margin-bottom, declared in shorthand just by accident, and it doesn't have mention shorthand obscurity.

And, by following this patter, this feature request doesn't bring any useful syntax sugar. More of it, it's harmful, due to a proposal to fill undeclared values with some defaults (like 0 for margins). How to determinate such defaults? For instance, in some cases margin: 1px 2px 3px 0; will produce completely unexpected result, due to upper declaration override.

Or how to treat this?

.test {
  background: {
    image: url('test.png');
  }
}

This will produce background: url('test.png'), which seems to be fine. But by doing that you've unexpectedly overridden any declared above background-color to be none.

Add on top of it parsing complexity due to determinating is margin in your example a custom HTML element or a shorthand declaration.

[xenoterracide]

This is very close to nest properties.

relevant (and in fact a feature I didn't even know existed) hmm... maybe what I really want is a way to compile all these varying syntaxes to a preferred "style" so that in addition to being readable... the override rules make more sense, and allow to compile to the tersest version... instead of being able to generally mix styles... (note: I'd be ok with making it a compiler flag) I guess, is there a fundamental difference other than what it compiles to, in my request?

I recommend just to not use shorthands at all.
In other words, just always use:

I would agree with you, except there's some weird overriding stuff for that does when mixed with the shorthand ( don't exactly remember, I just know if you start mixing them you can end up in weird override hell). It's hard to control what other people write, and especially if you're extending someone else's scss where you didn't choose the style they chose to write. Obviously this doesn't completely placate that.

Or how to treat this?

.test {
  background: {
    image: url('test.png');
  }
}

This will produce background: url('test.png'), which seems to be fine. But by doing that you've unexpectedly overridden any declared above background-color to be none.

is it though? I mean if you define background: url('test.png') it would do that... right? also, if nested properties are a thing... doesn't this already work?

[nex3]

This would require Sass knowing every shorthand property, how it maps to longhand, and when it's safe to use it without overriding other properties that the user didn't explicitly specify. We try to keep Sass's knowledge of CSS semantics as limited as possible so the implementation isn't tightly coupled to CSS specs, and this would violate that principle for very little gain.

If you're concerned about file size, I recommend using a dedicated minifier.

[ArmorDarks]

It's hard to control what other people write

Fortunately, there is a Stylelint. There you can forbid some shorthands.

I mean if you define background: url('test.png') it would do that... right? also, if nested properties are a thing... doesn't this already work?

I meant it would make it even more obscure, because when some people will write nested background property with image, they will expect it to produce background-image while others — background. Those results have different consequences, and we can't know what user wanted.