W3C home > Mailing lists > Public > www-style@w3.org > August 2015

Re: [css-writing-modes-3] 7.7 Table Caption Mappings: caption-side

From: Gérard Talbot <www-style@gtalbot.org>
Date: Tue, 11 Aug 2015 14:56:25 -0400
To: Jonathan Kew <jfkthame@gmail.com>
Cc: Koji Ishii <kojiishi@gluesoft.co.jp>, Elika Etemad <fantasai.lists@inkedblade.net>, W3C www-style mailing list <www-style@w3.org>
Message-ID: <2a5b2a2670ba7a885a1214b18ffbd016@gtalbot.org>
Le 2015-08-11 05:05, Jonathan Kew a écrit :
> On 11/8/15 04:44, Gérard Talbot wrote:
>> Hello,
>> 
>> "
>> Implementations that support the top and bottom values of the
>> caption-side property but do not support side captions (i.e. left and
>> right captions in horizontal writing modes) must treat both top and
>> bottom as block-start, when the table is in a vertical writing mode.
>> "
>> 7.7 Table Caption Mappings: the caption-side keywords
>> http://www.w3.org/TR/css-writing-modes-3/#caption-side
>> https://drafts.csswg.org/css-writing-modes-3/#caption-side
>> 
>> I see 2 problems with such sentence.
>> 
>> 1-
>> If an implementation supports top and bottom values of the 
>> caption-side
>> property but do not support side captions (i.e. left and right 
>> captions
>> in horizontal writing modes), why it should not treat top as 
>> block-start
>> on one hand and bottom as block-end on the other hand? Why treat both
>> top and bottom as block-start?
>> 
>> 2-
>> The way the sentence is written could also be subject of 
>> interpretation.
>> If an implementation supports top and bottom values of the 
>> caption-side
>> property, then it must do "x" regardless of its support of side
>> captions. The sentence could suggest that there will be a different
>> normative procedure when an implementation supports side captions...
>> when there should not be any difference.
>> 
>> - - - - - - -
>> 
>> 
>> "For implementations that do support side captions (i.e. the left and
>> right values from the obsolete CSS 2.0 specification [CSS2]), this
>> module also introduces the inline-start and inline-end values, which
>> behave similarly and which position the caption on the inline-start 
>> and
>> inline-end sides of the table box, calculated with respect to the
>> writing mode of the table box. For such implementations, the top and
>> bottom values must place the caption on the top and bottom sides of 
>> the
>> table box, respectively.
>> "
>> 7.7 Table Caption Mappings: the caption-side keywords
>> http://www.w3.org/TR/css-writing-modes-3/#caption-side
>> https://drafts.csswg.org/css-writing-modes-3/#caption-side
>> 
>> Here, I suggest to clarify the last sentence:
>> 
>> Current is: (...) the top and bottom values must place the caption on
>> the top and bottom sides of the table box, respectively.
>> 
>> Proposing: (...) the top and bottom values must place the caption at 
>> the
>> logical top and logical bottom sides of the table box, respectively.
>> 
>> I wonder why the sentence did not just say what should have been said 
>> a
>> paragraph before, which is "must treat top as block-star and bottom as
>> block-end" or something similar...
> 
> I don't agree with this. It seems clear to me that the spec is
> intending the existing physical values 'top' and 'bottom' to remain
> physical, regardless of writing mode; they are NOT to be reinterpreted
> as 'logical top' and 'logical bottom'.

I did not understand such intent (existing physical values 'top' and 
'bottom' to remain
physical) when reading the spec. It was not clear to me.

> Otherwise, why would it introduce the new block-* values at all?

That is one consequence of maintaining physical the 'top' and 'bottom' 
caption-side values.

> And then it's reasonable that in an implementation that does not
> support side captions, both 'top' and 'bottom' (which would correspond
> to the inline-start and inline-end sides of a vertical table) fall
> back to being treated as block-start.

That's another consequence of maintaining physical the 'top' and 
'bottom' caption-side values.

One other consequence is that testing 'caption-side: top' (and 
'caption-side: bottom') is going to be more complex as there can be 2 
possible rendered layouts: one for implementations that support side 
captions and one for implementations that do not support side captions.

> This makes caption positioning similar, from an author's point of
> view, to things like margin, where we have existing physical
> properties that remain physical regardless of writing mode, and
> parallel logical properties that adapt. I think that makes sense.
> 
> JK

It makes sense now, after reading your explanation.

I must add that I anticipate and believe web authors in general - with 
regards to the whole CSS3 Writing modes spec - are going to find it very 
difficult to understand what is logical, logicalized and physical and 
untangle all this properly.

One last thing. Old versions of IE were supporting side captions but 
without CSS 'caption-side' property; with the align attribute. And I 
have an old test page that should (will?) work with IE7 demonstrating 
this. I do not think that requesting or expecting trident (and now edge) 
based browsers to support side captions via CSS 'caption-side' was a big 
thing. I do not think that requesting or expecting webkit-based browsers 
to support side captions was a big thing.

Gérard
Received on Tuesday, 11 August 2015 18:56:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 11 August 2015 18:56:57 UTC