W3C home > Mailing lists > Public > www-style@w3.org > November 2012

Re: [css3-text] character-based alignment ambiguously defined

From: Kang-Hao (Kenny) Lu <kanghaol@oupeng.com>
Date: Thu, 29 Nov 2012 17:05:48 +0800
Message-ID: <50B7256C.5040302@oupeng.com>
To: WWW Style <www-style@w3.org>
(12/11/29 8:13), John Daggett wrote:
>>> Would the two examples below render with the decimal place at the
>>> same point?
>>>
>>>   td { text-align: "." right; }
>>>
>>>   <table id="table1">
>>>   <col width="40">
>>>   <tr><td> $1.30</td></tr>
>>>   <tr><td> $85</td></tr>
>>>   <tr><td> $.05</td></tr>
>>>   <table>
>>>
>>>   <table id="table2">
>>>   <col width="40">
>>>   <tr><td> $85</td></tr>
>>>   <tr><td> $1.30</td></tr>
>>>   <tr><td> $.05</td></tr>
>>>   <table>
>>
>> Yes
> 
> Sorry, this doesn't seem clear at all.  The "character-aligned
> contents" includes what exactly?  All cells that have some form of
> character alignment?  All cells that use character alignment and share
> the same "keyword alignment"?  Or all cells that have character
> alignment and share the same alignment character and "keyword
> alignment"?

The spec says

  # When multiple cells in a column have an alignment character
  # specified, the alignment character of each such cell in the column
  # is centered along a single column-parallel axis and the rest of the
  # text in the column shifted accordingly. (Note that the strings do
  # not have to be the same for each cell, although they usually are.)

which is pretty clear to me to mean your first guess. Anyway, I agree
that if there's a person who seriously reads the spec and couldn't
figure out the behaviors in a confident way then that's the problem of a
spec (I had and still have similar experience with css3-values).

Do you want to provide a change to the above paragraph?

My comments as follows:

"... and the rest of the text in the column shifted accordingly" seems
not very accurate but I am not sure what to do. Hacking it, like doing
s/in the column/in the corresponding line box/, would likely make it
unreadable.

s/strings/alignment characters/

Please define "character-aligned contents". I think it's probably
something like "inline-level boxes in line boxes where the alignment
character (could be different for differ cells) appears (for the first
time) or inserted."

> The spec seems to imply the grouping is based on the
> specific alignment character but it *only* specifies that for the case
> where the containing rectangle is smaller than the width of a cell.

Yes, I agree that's a problem.

> And, as you ask, what exactly happens when the contents don't satisfy
> the "insofar as possible without changing the width of the column"
> condition?  

Except if the alignment character is in a float of abs-pos, I actually
don't know how that can happen. I need an example here.

> Leave contents out of alignment?
> 
> Pathological case:
> 
>   td#a { text-align: "." center; }
>   td#b { text-align: "." right; }
>   td#c { text-align: "$" center; }
>   td#d { text-align: "$" right; }
> 
>   <table>
>   <col width="40">
>   <tr><td id="a"> $85</td></tr>
>   <tr><td id="b"> $1.30</td></tr>
>   <tr><td id="c"> $.05</td></tr>
>   <tr><td id="d"> $34567</td></tr>
>   <table>

I don't think this is a good case of the problem you just described and
the result is clear to me (module the fact that "center" has a MAY):

  |$85      | (a "." is inserted here at the end)
  | $1.30   | ("right" ignored. Not the first char-aligned cell)
  |   $.05  | ("center" ignored. Not the first char-aligned cell)
  |   $34567| ("right" ignored. Not the first char-aligned cell)

Having said that, in previous discussions people do say that they want
to align "." and "$" as separate groups[1]. But are examples like those
really useful?

> I still feel like I'm reading tea leaves when I read this section of
> the spec, I can't quite get a handle on the precise behavior that
> needs to be implemented.  Part of the problem is that the description
> is worded as an awkward list of "when condition X do Y" statements. 
> Given that this is effectively adding steps to the complex algorithm
> for table cell layout I really think this needs to be worded as a
> modification to that algorithm, including how to deal with all cases,
> not just a few select cases.

I share your pain in general. CSS modules are notoriously underspecified
and anti-algorithmic and I never know why. I found it quite funny that
the inline model written by David back in 2000[2] was many times more
underatndable than the current CSS 2.1.

Anyway, too off-topic, if anyone wants to craft some text, David's
message[3] might be a good starting point.

>>> I think the problem is that you're trying to set column-level
>>> attributes from within individual cells which is funky at best.
>>
>> But not all tables have <col>s so I don't see an alternative.
> 
> Defining column-level alignment only for tables and at the cell level
> are fundamental design flaws I think.  What you really want is a way
> of saying "align this character with that alignment axis", where the
> alignment axis is defined for a parent element. Something along the 
> lines of Peter's alternative grid proposal comes to mind. 

This reminds me that, as I said, Open Office doesn't have 'text-align:
<string>' in the spreadsheet mode but in the text processing mode. If
anyone knows the use cases there then it would be nice if that's shared.

> All in all, I think the feature as currently spec'ed is of very
> limited use and introduces way too much complexity for the
> functionality that it adds.

I agree. If there's an interest in keeping this feature in Level 3, I
suggest we drop the supplemental <keyword>. That is, it always defaults
to 'right'.



[1] http://lists.w3.org/Archives/Public/www-style/2008Dec/0229 item 4
[2] http://dbaron.org/css/2000/01/dibm
[3] http://lists.w3.org/Archives/Public/www-style/2008Dec/0235 at the bottom

Cheers,
Kenny
-- 
Web Specialist, Oupeng Browser, Beijing
Try Oupeng: http://www.oupeng.com/
Received on Thursday, 29 November 2012 09:06:16 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:03 GMT