Repository navigation
[css-logical] border-block/border-inline syntax #3519
Description
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.
Activity
Loirooriol commentedon Jan 15, 2019
Note that
border-block-startis a multi-valued shorthand.I think so, just like
borderdoes not let you specify different width, style or color for different sides.fantasai commentedon Jan 16, 2019
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 asborder-inline: solid orange 5px dotted orange 5pxwhich is the same asborder-inline: orange 5px solid dotted. It's not a pattern we've followed before, though.Thoughts from anyone else?
Loirooriol commentedon Jan 17, 2019
I would rather keep it simple and not allow this.
Instead of
border-inline: solid orange 5px dotted, people can usewhich seems much clearer to me.
MatsPalmgren commentedon Jan 17, 2019
@Loirooriol
I don't think
borderis the correct analog here.border-horizontal/verticalwould 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
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 commentedon Jan 17, 2019
borderis 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-blockandborder-inline, probably I would also want it inborderfor consistency.This way the separation is more obvious. However, I would expect
to be treated as
instead of as
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 agree with this, in fact
borderalready has this note:css-meeting-bot commentedon Jan 23, 2019
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 restrictionThe full IRC log of that discussion
<dael> Topic: border-block/border-inline syntax<dael> github: https://github.com//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//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
[css-logical] Clarify that border-inline/block set both affected side…
fantasai commentedon Sep 14, 2020
@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.
SebastianZ commentedon Nov 19, 2025
@fantasai In your change you added the note as HTML comment. I think that note should be made reader-visible to make the intention clear and avoid future questions.
Sebastian