[css-logical] border-block/border-inline syntax

[MatsPalmgren]

https://drafts.csswg.org/css-logical/#border-shorthands

Name: border-block, border-inline Value: <‘border-block-start’>

It appears the above value syntax only allows specifying a single value. Is this intentional? Normally, these types of shorthands allows specifying a single value (used for both axes) or both values. If it's intentional, then we should probably add a note to clarify that.

[Loirooriol]

It appears the above value syntax only allows specifying a single value

Note that border-block-start is a multi-valued shorthand.

Is this intentional?

I think so, just like border does not let you specify different width, style or color for different sides.

[fantasai]

I technically don't remember what I was thinking, but I'm sure @Loirooriol's comment is right. :)

Parsing border-inline: solid orange 5px dotted, it isn't clear where the first value ends and the second one starts. We could define that each type of value (color, style, width) is independently duplicated as needed, rather than resetting missing second values to their initial value. Then the above declaration would be the same as border-inline: solid orange 5px dotted orange 5px which is the same as border-inline: orange 5px solid dotted. It's not a pattern we've followed before, though.

Thoughts from anyone else?

[Loirooriol]

I would rather keep it simple and not allow this.

Instead of border-inline: solid orange 5px dotted, people can use

border-inline: orange 5px;
border-inline-style: solid dotted;

which seems much clearer to me.

[MatsPalmgren]

@Loirooriol

just like border does not let you specify different width, style or color for different sides.

I don't think border is the correct analog here. border-horizontal/vertical would be, if they existed. Anyway, I'm not sure if comparing to legacy physical properties is that useful here. My point is that modern axis-relative shorthands normally allows specifying one or two values.

@fantasai

it isn't clear where the first value ends and the second one starts

Right, we can't use space as a separator. It needs to be some other character like "/".

We can skip it if authors don't find it a useful feature of course. But I'd like the spec to make a note of it if so, since it's an exception to common praxis. (Fwiw, it's really trivial to add parsing for an optional second value so there's no cost for implementors.)

[Loirooriol]

I don't think border is the correct analog here. border-horizontal/vertical would be

border is still a great analog. The difference is that it maps to 4 sides instead of 2, but the number is not that important. What matters is that they are shorthands for multiple sides, and the property for each side is also a multi-valued shorthand.

In fact, if this is added to border-block andborder-inline, probably I would also want it in border for consistency.

It needs to be some other character like "/".

This way the separation is more obvious. However, I would expect

border-inline: solid orange 5px / dotted;

to be treated as

border-inline: solid orange 5px / dotted currentColor medium;

instead of as

border-inline: solid orange 5px / dotted orange 5px;

which is what fantasai proposed and seemed more useful to me, because I rarely want the initial border values. Not sure which behavior you are proposing.

I'd like the spec to make a note

I agree with this, in fact border already has this note:

Unlike the shorthand margin and padding properties, the border property cannot set different values on the four borders. To do so, one or more of the other border properties must be used.

[css-meeting-bot]

The CSS Working Group just discussed border-block/border-inline syntax, and agreed to the following:

• RESOLVED: Close this issue and add a note to the spec saying this is an intentional restriction

The full IRC log of that discussion

<dael> Topic: border-block/border-inline syntax
<dael> github: https://github.com/w3c/csswg-drafts/issues/3519
<dael> fantasai: Mats pointed out they only let you set one value which assigns to both sides. Asking if we should allow setting 2 different values. Short answer is I htink no because border prop includes color, length, and border style. Shorthand that deals with that doesn't allow 4 sides. So you can only set both sides to same thing.
<dael> fantasai: I think that's fine. I think Oriol thinks it's fine. But we could do that.
<fantasai> https://github.com/w3c/csswg-drafts/issues/3519#issuecomment-454987242
<dael> astearns: Given we have not done it for border property I don't think we should do this for border-block and border-inline
<oriol> I agree with fantasai
<dael> rachelandrew: Agree. It's less confusing if it's the same as 4 value
<dael> TabAtkins: Yeah
<dael> astearns: Prop: Close this issue and add a note to the spec saying this is an intentional restriction
<dael> astearns: Obj?
<dael> RESOLVED: Close this issue and add a note to the spec saying this is an intentional restriction
<dael> astearns: Thanks everyone for calling in

[fantasai]

@MatsPalmgren I adjusted the phrasing a bit to make it clearer that it sets both sides to a single value, but didn't add a note about rationale since I didn't think it warranted most readers' attention. Did add a comment in the source for future spec editors pointing at this discussion, though.

Let me know if you think these edits are acceptable, or if you'd prefer a note explaining the rationale.