[css3-writing-modes] Random comments

This is a bit disorganized, sorry…


So, I went through the whole spec. Everything seems pretty sensible, 
except for section 7.3 "Orthogonal Flows" where I’m very confused.

There is a lot of technical terms like "fill-available extent". It would 
help if they were all linked to their respective definition. In some 
cases like "available extent", I don’t know if this is a concept 
introduced by this spec or if it refers to something else (maybe in Sizing?)

I find unclear whether "orthogonal flow" refers just to the boundary 
between an element and its perpendicular containing block, or also the 
element’s descendants. I think the <dfn>’d term should be [an element] 
"establishes an orthogonal flow". (Drop "be in" which is not used anyway.)

In 7.3.1 and 7.3.2, it is unclear that we’re still talking about the 
same element as in the beginning of 7.3. Each subsection should start 
with "If an element <i>establishes an orthogonal flow</i>, …"

More generally, every time you have "the element", which element is 
this? Make sure the context is not too far, at least in the same 
sub-section.

Do I understand correctly that 7.3.2 triggers multicol even when all 
column* properties have their initial value?


In section 7.2:

> As a corollary, percentages on the margin and padding properties,
> which are always calculated with respect to the containing block
> width in CSS2.1, are calculated with respect to the measure of the
> containing block in CSS3.

Perhaps s/CSS3/CSS Writing Modes Module Level 3/?


Section 7.3.1 links to
http://www.w3.org/TR/css3-sizing/#fill-available-fit
but Sizing does not define fill-available-fit (anymore?)


In 7.3.3:

> Note that if content spills outside the pagination stream established
> by the root element, the UA is not required to print such content.

This is specific to orthogonal flow. Should we generalize to any kind of 
overflow in the inline direction of the root?


In 7.7:

> 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 ‘top’
> and ‘bottom’ as ‘start’, when the table is in a vertical writing
> mode.

Is it deliberate that the two physical values map to the same logical 
value? If so, just adding "both" can clarify.


-- 
Simon Sapin

Received on Tuesday, 11 June 2013 15:38:58 UTC