Re: [css3-text] Tab U+0009 expansions to 8 spaces

On Thu, Feb 24, 2011 at 9:43 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
> On Feb 24, 2011, at 9:38 AM, fantasai wrote:
>> On 02/24/2011 07:08 AM, Brad Kemper wrote:
>>> I think it needs to have a<length>  if it is to be definable at all.
>>> That is more normal for tabs (in word processing, graphic design, etc.)
>>> than counting out space characters.
>>
>> Tabs in word processing and graphic design aren't fixed lengths,
>> they're fixed positions. Using tabs in this way is a layout system,
>> and there are much better proposals for doing that using elements
>> and properties rather than tab characters. When you're using a
>> tabbed layout system, you want to set positions and alignment,
>> leader characters, etc. It's not about the size of the tab character.
>> So I consider such use cases to be out-of-scope for this feature.
>
> Even if the commonest use case is to show lines of code, isn't it still important that the tabs line up from line to line? And doesn't that get messed up if you are not using a monospace font and have a few lines in bold, or in slightly larger type for emphasis?

If all the tabs occur at the start of lines, no, the font used on the
line won't screw up alignment.

But anyway, Anne pointed out privately that I'm wrong here.  Tabs *do*
act like tabstops.  Specifically, in
<http://www.w3.org/TR/CSS21/text.html#white-space-model> we have the
line "2. All tabs (U+0009) are rendered as a horizontal shift that
lines up the start edge of the next glyph with the next tab stop. Tab
stops occur at points that are multiples of 8 times the width of a
space (U+0020) rendered in the block's font from the block's starting
content edge.".

Given this, I don't see a good reason to restrict tab size to just
<integer>s.  They should be specifiable as <length>s, too.
Implementation difficulty should be identical - while <integer> tab
stops may be easier to implement in monospace fonts if the block's
font is the same as the text's font, the general case doesn't benefit
at all from this restriction.

Fantasai's point about general tab-stop behavior being more complex
and being out-of-scope here is valid, but I believe it's irrelevant
for the specific feature being discussed here.

~TJ

Received on Thursday, 24 February 2011 18:01:32 UTC