W3C home > Mailing lists > Public > www-style@w3.org > February 2011

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

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 24 Feb 2011 09:54:37 -0800
Message-ID: <4D669B5D.708@inkedblade.net>
To: Brad Kemper <brad.kemper@gmail.com>
CC: Koji Ishii <kojiishi@gluesoft.co.jp>, David Singer <singer@apple.com>, Anne van Kesteren <annevk@opera.com>, W3C style mailing list <www-style@w3.org>, Christoph Päper <christoph.paeper@crissov.de>
On 02/24/2011 09:43 AM, Brad Kemper 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?

No, that doesn't get messed up because the tab stops are consistent
throughout the block:


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

The tab-size property doesn't change anything except the number in
that sentence.

Received on Thursday, 24 February 2011 17:55:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:56 UTC