- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 24 Feb 2011 09:54:37 -0800
- 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: 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. ~fantasai
Received on Thursday, 24 February 2011 17:55:15 UTC