- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 24 Feb 2011 09:13:48 -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 Thu, Feb 24, 2011 at 7:08 AM, Brad Kemper <brad.kemper@gmail.com> wrote: > On Feb 23, 2011, at 11:33 AM, Koji Ishii wrote: >> Thank you all for the information for the implementations. We have added the property to the Editor's Draft[1]. >> >> We didn't add <length> version though, as existing implementations don't support it, and we could add it in future if we've got enough interests from implementers. > > 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. The behavior of word processors is different from what this property does, though - they use the "tab stop" behavior, where tabs themselves are variable length, whatever is required to put their end at the next tab stop. I see nothing wrong with a future property defining the tab-stop behavior rather than tab-character widths, but that's not a necessary feature for this property to address at this time, I think. (I suspect the most common use of tabs in preformatted text is to indent source code, which is a use-case that doesn't actually care whether tabs are done as a set length or via tabstops.) ~TJ
Received on Thursday, 24 February 2011 17:18:37 UTC