Re: FW: ACTION-18: vertical alignment values

Alex Mogilevsky wrote:
> Thanks Fantasai, now I can recall the discussion.
> 
> Attached is a draft text for property definition which reflects what I believe we have agreed on or have considered. It also calls out a few open issues.
> 
> Please comment!

0) Re the name 'block-vertical-align'

The word "vertical" is useful to remind one of the similar but different 
'vertical-align' property, but in the light of use in vertical text, 
maybe it is nevertheless better to omit that word and call the property 
'block-align'?



1) Re 'justify':

Equally spacing a series of boxes might be nice, but maybe it can be 
simulated sufficiently with 'leader(space)' from the GCPM Module as 
follows. If the document fragment is like this:

     <div class=container>
       <div>...</div>
       <div>...</div>
       ...
       <div>...</div>
     </div>

the style may be like this:

     div.container {height: 40em; block-progression: rl}
     div.container > div {block-progression: tb; display: inline-block}
     div.container > div::before {content: leader(space)}
     div.container > div:first-child::before {content: none}

(OK, it's complex, and I'm not even sure it is complete... :-) )

Extended margin properties may be another approach still, see point 5 below.



2) Re priority over 'vertical-align':

The text should probably explain better what that means. I think it 
means that the 'auto' value, when applied to a table cell, defers to the 
value of 'vertical-align'.



3) Re when content is bigger than the container:

Why make this exception? Why can't content be aligned to the top, middle 
or bottom when it is bigger than the content box? Indeed, this seems a 
very useful feature: you can create a box with a scrolling mechanism and 
initialize it to show the center part of the content. Moreover, if you 
have several boxes side by side, all of which have 
'block-vertical-align: middle', it will look rather ugly if one of them 
is *not* centered.



4) Re vertical text:

I think we also need values 'left' and 'right'. Those values can be 
treated as 'top' when in horizontal text (and, conversely, 'top' and 
'bottom' can be treated as 'right' in 'rl' and as 'left' in 'lr). 
Treating them as 'auto' is probably less desirable, because 'auto' 
doesn't create a flow root ("block formatting context root" in CSS 2.1 
terminology).

I've never seen a use case for 'start'/'end' (or 'before'/'after') and I 
can't imagine anybody creating a style that can just be rotated 90 
degrees and still look good. People's eyes are side by side, and thus 
reading vertical text requires different typography than reading 
horizontal text. But learning two more keywords is a relatively low cost 
for users, so if somebody finds a use case, they are easy to add to the 
spec.



5) Doing without the property:

For the horizontal position (or more generally: line progression 
direction), we use 'auto' margins on child boxes to align content to the 
edges or the center of a container box. (Although that functionality is 
broken for large boxes since CSS 2.1.)

Maybe we should have the same method for aligning block children 
horizontally and vertically. If one uses the margins, than so should the 
other (and if one uses a property, than so should the other).

If we use the margins, we could have keywords such as 'fill' or 'any' 
(as 'auto' is unfortunately not reliable anymore):

     /* Prohibit margin collapsing and insert an elastic margin */
     div { margin-top: fill }

The metaphor for 'fill' may be a spring: it's attached somewhere high 
above the DIV and is pushing the DIV down as far as it can go. If there 
is a spring at the bottom as well, the result is to push the DIV to the 
center. The 'leader()' value from GCPM is a similar idea.

     /* Align to the right */
     div { margin-left: fill }

If we use a property, e.g., 'block-align', it could look like this:

     div { block-align: center left }
     div { block-align: auto } /* default */
     div { block-align: bottom right }

(But using a property interferes with the existing 'auto' margins. It 
can get rather confusing and using auto margins as fallback for old 
browsers doesn't work as well as the 'fill' solution.)



Bert
-- 
   Bert Bos                                ( W 3 C ) http://www.w3.org/
   http://www.w3.org/people/bos                               W3C/ERCIM
   bert@w3.org                             2004 Rt des Lucioles / BP 93
   +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Wednesday, 7 May 2008 13:25:55 UTC