Re: spec complain: css letter-spacing in tabs not clear

On Tue, Jan 27, 2015 at 9:57 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 1/26/15 8:18 AM, -=}\*/{=- wrote:
>>
>> please help us on this bug, we are having spec interpretation issues:
>>
>>    https://bugzilla.mozilla.org/show_bug.cgi?id=1124344
>
>
> More precisely, the spec is clear but probably not very useful.

Agreed.  The current behavior is interoperable and well-specified in
the spec; there's not really room for argument as to what the spec
says to do.  What the spec should *say* is another question entirely.

> Specifically, if you have preformatted text in a block with letter-spacing,
> the spacing of tab stops is not affected by the letter-spacing per spec.
> Maybe it should be, because otherwise preformatted text with tabs in it ends
> up laying our all wrong.

Changing this would presumably only affect the 'tab-size: <int>' case,
not <length>, right?  Dunno how to interpret a <length> in order to
add in letter-spacing.

But yeah, I guess it makes sense for tabs sized with an integer to
take into account 'letter-spacing'.  There are two ways we could do
this:

1. As dbaron says in the bug, make the tabs respond to
'letter-spacing' on their nearest block ancestor, since the tab stop
positions are measured from the block edge.  (In other words, tabs are
not just some number of spaces, they're "move to the next offset from
the block edge".)

2. Make tabs respond to the 'letter-spacing' of their nearest
(possibly inline) ancestor, meaning there are potentially multiple
distinct tab-stop sets that different tabs would align to, each spaced
out according to different 'letter-spacing' values..

The stated use-case is using letter-spacing to make monospace fonts
look a little more "spread out", and wanting tabs to line up with the
resulting character spacing, so I don't see a use for the complication
of case #2.  We should go with case #1, then.

~TJ

Received on Tuesday, 27 January 2015 18:30:50 UTC