ISSUE-53:block vertical alignment

This continues the discussion on block vertical-aligment, started from ACTION-18 [0].
The only comment on the first writeup [1] is from Bert Bos [2] -- thanks Bert!

I'll try to comment (sorry, way overdue) on the initial feedback from Bert Bos:  [2]

> 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'?

There are two approaches to universal values (such as left/right/start/end). One is to favor mathematically correct (start/end), another is to use “logical”.

CSS is all physical (consistency which I love). Continuing that trend it would be more than expected to make “vertical-align” mean “logical horizontal align” when in vertical text. However there is a precedent – “vertical-align”, and it is clearly related to baseline, therefore clearly logical.

Also the scenarios for this new property are logically-vertical. Orthogonal direction (line-flow direction) is already covered with margins and text-justify (and BTW the deprecated HTML ‘align’ property, which deprecated or not can be relied upon forever).

Property name can follow the precedent or it can be universal (block-progression-align?)

That said, I tend to agree with Bert that introducing yet another property that is really logical but uses physical language feels wrong.

How about (not kidding) “block-progression-align”? I know it is mouthful, but we developers type fast :)

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

I have nothing against introducing the concept of vertical justification (especially since I was part of one implementation of that). I think it is fine as long as precise behavior is left to UA. We can expect good interop without obstacles/pagination, but not beyond that...

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

I agree

> 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?

It certainly could. I believe it must be achieved with a separate set of values though.

The most desired use case for vertical-align is centering content within viewport. But if the viewport is not big enough, there has to be a way to scroll to all of the content...

True-center/true-middle has been proposed...

> 4) Re vertical text:
>
> I think we also need values 'left' and 'right'.
> ...
> 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...

That is correct. However there is already a way to align and center horizontally but not vertically. Since this is dealing with only one problem, it is best to add complexity in only one direction. Therefore I think this should stay logical. As much as it is not what the rest of CSS is doing...

> 5) Doing without the property:

Interesting. In fact the existing interference of HTML ‘align’ and the various margin settings forces us to create yet another set of margins to deal with the alignment. That is somewhat confusing for implementer but not necessarily for the author.

I am not sure I am agreeing with you on this point, but I think it would be interesting to formalize the extra margins added to implement <center> via CSS:
        img
        {
               outer-margin:auto
        }

(this would center in both directions, always)

(yes, there was more to it that I didn’t respond to...let’s keep talking...)


[0] http://www.w3.org/Style/CSS/Tracker/actions/18
[1] http://www.w3.org/mid/04F36FB4ED0F85459AA447F72711526F013C91E6F7C5%2540DF-GRTDANE-MSG.exchange.corp.microsoft.com
[2] http://www.w3.org/mid/4821ADB5.6080908%2540w3.org