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

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

From: John Daggett <jdaggett@mozilla.com>
Date: Wed, 28 Nov 2012 16:13:03 -0800 (PST)
To: www-style list <www-style@w3.org>
Message-ID: <898799170.1913607.1354147983161.JavaMail.root@mozilla.com>
Kenny Lu wrote:

> > Where is the alignment character placed when 'right' or 'left'
> > values are used?
> I think this is clear enough:
>   # when the column is wide enough that the character alignment
>   # alone does not determine the positions of its character-aligned
>   # contents. In this case the keyword alignment of the first cell
>   # in the column with a specified alignment character is used to
>   # slide the position of the character-aligned contents to match
>   # the keyword alignment insofar as possible without changing the
>   # width of the column.
> where "character-aligned contents" = "containing rectangle", I
> suppose. Relevant feedback: this prose is suffering from the same
> problem 'text-align' currently has[1]. In other words, it doesn't
> say what to do when the column isn't wide enough for the containing
> rectangle.
> > 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 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.
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?  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; }

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

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 don't know table algorithms well enough to comment
> > authoritatively but it seems like this feature as specified is
> > going to introduce some hairy column adjustment code into table
> > implementations.  
> I kind of agree, but without this this feature would seem to not be
> very usable.
> > 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.

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.


John Daggett
Received on Thursday, 29 November 2012 00:13:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:23 UTC