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

On Thu, Feb 24, 2011 at 9:54 AM, fantasai <fantasai.lists@inkedblade.net> wrote:
> 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:
>
> http://www.w3.org/TR/CSS21/text.html#white-space-model
>
>  # 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.

Note that allowing <length>s is just a s/8 times the width of a space
(U+0020) rendered int he block's font/the tab size/.

~TJ

Received on Thursday, 24 February 2011 18:06:06 UTC