Repository navigation
[css-logical] Add block-start and block-end to caption-side #9623
Description
CSS Logical says
The existing
topandbottomvalues are idiosyncratically redefined as assigning to the block-start and block-end sides of the table, respectively.
regarding the caption-side keywords.
For consistency - also because the spec. defines inline-start and inline-end - we should define the keywords block-start and block-end explicitly and let the physical values map to them.
@ramiy already created a PR to add them.
Sebastian
Reacted by Rami Yushuvaev
Reacted by Rami Yushuvaev
Reacted by Rami Yushuvaev
Reacted by Rami Yushuvaev
Reacted by Rami Yushuvaev
Reacted by Rami Yushuvaev
Activity
Loirooriol commentedon Nov 22, 2023
If they don't bring any new functionality, I'm not convinced this is worth it.
That said, it's maybe a bit strange for
topandbottomto be flow-relative, whileleftandrightare line-relative:top,bottomleft,rightinline-start,inline-endIf compat allows it, it could make more sense to treat
topandbottomas line-over and line-under, and then addblock-startandblock-endas flow-relative:top,bottomleft,rightinline-start,inline-endblock-start,block-endIf the initial value is also changed to
block-start, then this would only impact pages explicitly settingcaption-side: toporbottomin awriting-mode: vertical-lr(or non-standardhorizontal-btin WebKit).Loirooriol commentedon Nov 22, 2023
For reference, this was discussed in https://lists.w3.org/Archives/Public/www-style/2015Sep/0113.html and https://lists.w3.org/Archives/Public/www-style/2015Sep/0158.html
SebastianZ commentedon Nov 24, 2023
Thanks for pointing out that inconsistency!
I agree with that. Doing so, authors have the freedom to choose between flow- or line-relative alignment for their caption. (Though I have to say, I lack the knowledge of vertical and RTL languages and their requirements.)
That needs to be checked for web compat. And if pages exist, the question is whether that new initial value would actually be better in those cases.
Sebastian
Loirooriol commentedon Nov 24, 2023
On the other hand, given that nobody seems to implement
leftandright(I think only Firefox did, but no longer), and thus they don't implementinline-startandinline-endeither, we could just remove all of these. Then there is no inconsistency.SebastianZ commentedon Nov 24, 2023
Removing them is also an option if they are really not implemented anywhere anymore/it is web compatible and there are no strong use cases for adding them back.
Sebastian
ramiy commentedon Nov 27, 2023
Not sure that removing
inline-start&inline-endvalues to prevent inconsistency is the best approach.I suggested this feature for Interop 2024, therefore browsers may add support for this feature and improve web compatibility.
As for use cases, I see a lot of use cases for this feature. For example, caption position may add more possibilities to CSS frameworks like Charts.css which relies on HTML tables.
ramiy commentedon Nov 29, 2023
In addition, the current spec mentions that:
But when working with
inline-start&inline-endvalues it should also consider the writing direction controlled by the CSSdirectionproperty on the HTMLdirattribute.Loirooriol commentedon Nov 29, 2023
https://drafts.csswg.org/css-writing-modes-4/#writing-mode
fantasai commentedon Dec 1, 2023
Adding
block-startandblock-endaliases makes sense to me. The fact thattopandbottomended up interpreted flow-relative was an unfortunate consequence ofleftandrightnot being implemented (since they're substantially different, from a layout perspective, thantopandbottomin horizontal-tb writing modes).I don't think they should be aliased to
over/under; that wouldn't make a lot of sense.Loirooriol commentedon Dec 1, 2023
Why wouldn't it make sense to define top/bottom as line-over/line-under if left/right are defined as line-left/line-right?
fantasai commentedon Dec 1, 2023
The usage of
topvsbottomis much closer toblock-start/inline-startthanover/under. Over/under is useful within a line box, but once you start getting to the block level, it's not a very useful concept for real content.css-meeting-bot commentedon Jun 17, 2026
The CSS Working Group just discussed
[css-logical] Add `block-start` and `block-end` to `caption-side`, and agreed to the following:RESOLVED: add the block-start and block-end to the caption-side property and to behave as top and bottom respectivelyThe full IRC log of that discussion
<ydaniv> oriol: if caption side prop in CSS2 it had to and bottom keywords, some impls had left and right<ydaniv> ... top and bottom were refined to use logic
<ydaniv> ... and line-left and line-right to use logic as well
<ydaniv> ... Sebastian suggested [missed]
<ydaniv> ... situation is inconsistent with flow-relative, so we could define top/bottom to line-above and line-under and provide different keywrods for flow relative
<ydaniv> ... I'm fine with not doing what I proposed, we could add block-start and block-end as aliases, or keep as is, which will not behave as physical but in flow-relative
<TabAtkins> (I'm a little confused about the use-case for caption-side's left/right being line-relative anyway.)
<ydaniv> fantasai: I'm in favor to adding the aliases, which would be more consistent
<TabAtkins> (Is this about inline-table?)
<romain> +1 to adding the aliases
<ydaniv> ... maybe in the future we could do something more interesting
<TabAtkins> +1 to block-start/end tho
<kurt> Should this apply to the other properties in https://drafts.csswg.org/css-logical (e.g. https://drafts.csswg.org/css-logical/#float-clear)?
<ydaniv> fantasai: the left and right alignment and the start left/right text begins is the line-left side, so it would be line-relative, since top/bottom are line-relative
<fantasai> s/line-relative/logical
<ydaniv> ... perhaps if physical to begin with would work to make it physical
<fantasai> s/physical to/we had all 4 directions to/
<TabAtkins> (ohhhhhh right i forgot what exactly line-relative meant. writing-mode responsive, just left/right in some way in the inline axis)
<ydaniv> fantasai: currently only top/bottom supported, we had to make them logical/physical
<ydaniv> fantasai: float don't have these issues since these are line-relative
<ydaniv> astearns: so not aliases, but equivelant keywords?
<ydaniv> fantasai: yes
<ydaniv> fantasai: maybe we'll find there's not enough content...
<ydaniv> oriol: so they compute to how much...
<ydaniv> fantasai: they're independent
<ydaniv> PROPOSED: add the block-start and block-end to the caption-side property and to behave as top and bottom respectively
<ydaniv> astearns: objections?
<ydaniv> RESOLVED: add the block-start and block-end to the caption-side property and to behave as top and bottom respectively