- From: Simon Sapin <simon.sapin@exyr.org>
- Date: Tue, 11 Jun 2013 16:38:33 +0100
- To: fantasai <fantasai.lists@inkedblade.net>
- CC: www-style <www-style@w3.org>
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