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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 24 Feb 2011 09:13:48 -0800
Message-ID: <AANLkTinKpKzDj3=ZauGfoHaKWV9-Gzpwn6si0fU0GeBV@mail.gmail.com>
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.)

Received on Thursday, 24 February 2011 17:18:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:43 UTC