W3C home > Mailing lists > Public > www-style@w3.org > January 2013

Re: [css3-text] A proposal to replace 'tab-size' with 'tabstop-widths'

From: Nick Gravgaard <me@nickgravgaard.com>
Date: Thu, 03 Jan 2013 23:37:22 +0000
Message-Id: <1357256242.14694.140661173144361.5385D8D8@webmail.messagingengine.com>
To: fantasai <fantasai.lists@inkedblade.net>, www-style@w3.org
On Thu, Jan 3, 2013, at 17:14, fantasai wrote:
> On 12/21/2012 06:24 PM, Nick Gravgaard wrote:
> > I would like to suggest something which is more powerful than 'tab-size'
> > (http://www.w3.org/TR/css3-text/#tab-size) but should be easily
> > implementable and would work like ''tab-size' when given one value. I
> > propose a new attribute called 'tabstop-widths' which takes a list of
> > widths measured in em and/or px values.
> I think this would be quite easy to spec as an extension to the
> existing 'tab-size' property to have it accept multiple values,
> rather than as a separate property.

I don't mind really. I think 'tabstop-widths' is more appropriate, but I
understand if it makes sense to keep the old name.

I just care that the attribute should be able to take a list of widths
and that those widths can optionally be specified in px and other
absolute length units.

> The open question is whether anyone would want to implement that.

Are you asking why this is a good idea? If so, I think I can make a case
for it...

There is currently demand for it - for a start some Ace (widely used
browser based text editor) users and developers want to implement
elastic tabstops and that requires the ability to set tabstops to
different non-uniform widths. These are the guys who are pushing the
text part of the CSS spec.

More generally, there are a couple of excellent rich text editor
projects and it seems highly likely to me that they might want to
implement draggable tabstops (like word processor applications have had
since the 1980s).

And then of course there's just the fact that a 'tab-size' attribute
which just takes one repeating value and only works with monospaced
fonts was state of the art in the 1960s. Is that the level we want to
aim for? Is there any other part of the HTML/CSS spec which only works
properly with monospaced fonts?

So I think people do want and will appreciate an implementation.
Received on Thursday, 3 January 2013 23:37:44 UTC

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