[css-logical] Add block-start and block-end to caption-side

[SebastianZ]

CSS Logical says

The existing top and bottom values 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

[Loirooriol]

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 top and bottom to be flow-relative, while left and right are line-relative:

Keyword	Type	Meaning
top, bottom	flow-relative	block-start, block-end
left, right	line-relative	line-left, line-right
inline-start, inline-end	flow-relative	inline-start, inline-end

If compat allows it, it could make more sense to treat top and bottom as line-over and line-under, and then add block-start and block-end as flow-relative:

Keyword	Type	Meaning
top, bottom	line-relative	line-over, line-under
left, right	line-relative	line-left, line-right
inline-start, inline-end	flow-relative	inline-start, inline-end
block-start, block-end	flow-relative	block-start, block-end

If the initial value is also changed to block-start, then this would only impact pages explicitly setting caption-side: top or bottom in a writing-mode: vertical-lr (or non-standard horizontal-bt in WebKit).

[Loirooriol]

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]

That said, it's maybe a bit strange for top and bottom to be flow-relative, while left and right are line-relative:

Thanks for pointing out that inconsistency!

If compat allows it, it could make more sense to treat top and bottom as line-over and line-under, and then add block-start and block-end as flow-relative

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.)

If the initial value is also changed to block-start, then this would only impact pages explicitly setting caption-side: top or bottom in a writing-mode: vertical-lr (or non-standard horizontal-bt in WebKit).

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]

On the other hand, given that nobody seems to implement left and right (I think only Firefox did, but no longer), and thus they don't implement inline-start and inline-end either, we could just remove all of these. Then there is no inconsistency.

[SebastianZ]

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]

On the other hand, given that nobody seems to implement left and right (I think only Firefox did, but no longer), and thus they don't implement inline-start and inline-end either, we could just remove all of these. Then there is no inconsistency.

Not sure that removing inline-start & inline-end values to prevent inconsistency is the best approach.

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.

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]

In addition, the current spec mentions that:

The mapping on this property uses the writing mode of the caption’s containing block (that is, the table wrapper box).

But when working with inline-start & inline-end values it should also consider the writing direction controlled by the CSS direction property on the HTML dir attribute.

[Loirooriol]

https://drafts.csswg.org/css-writing-modes-4/#writing-mode

A writing mode in CSS is determined by the writing-mode, direction, and text-orientation properties.

[fantasai]

Adding block-start and block-end aliases makes sense to me. The fact that top and bottom ended up interpreted flow-relative was an unfortunate consequence of left and right not being implemented (since they're substantially different, from a layout perspective, than top and bottom in horizontal-tb writing modes).

I don't think they should be aliased to over/under; that wouldn't make a lot of sense.

[Loirooriol]

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]

The usage of top vs bottom is much closer to block-start/inline-start than over/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.