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 13:19:18 +0000
Message-Id: <1357219158.9016.140661172876305.04F530BD@webmail.messagingengine.com>
To: Simon Sapin <simon.sapin@kozea.fr>, www-style@w3.org
On Wed, Jan 2, 2013, at 16:30, Simon Sapin wrote:
> [reordered]
> Le 02/01/2013 13:29, Nick Gravgaard a écrit :
> > I didn't get any feedback on this and suspect it was because I posted it
> > on the weekend before the holidays.
> >
> > If I sent my proposal to the wrong mailing list could someone suggest a
> > more appropriate one?
> This is the right mailing list. It helps to tag the subject with the 
> short name of the spec (like I did here.)

Thanks Simon.

> > I believe my proposal below is compatible with 'tab-size' (from the
> > current W3C Working Draft), more modern, more useful and is easy to
> > implement.
> I don’t know about easy to implement. Elastic tab stops feel a lot like 
> tables, which are many things but easy.

My proposal is not to add elastic tabstops to the W3C spec, but to
replace the 'tab-size' attribute with 'tabstop-widths'. If there are
working implementations of 'tab-size' it should be easy to modify them
to support 'tabstop-widths' instead.

> But reading your first message again tells me something that I missed 
> the first time: your proposal is *not* to add elastic tab stops to CSS, 
> but "only" multiple (different) values for tab-size, which presumably 
> would be generated by a JavaScript editor. This sounds much more
> reasonable.

That's right.

> That said, I don’t know if the use case is strong enough to justify 
> adding this.

There are other use cases than just my invention (which is why similar
functionality exists in many text widget APIs). What about a browser
based rich text editor with draggable tabstops (like any basic word
processor)? That's a pretty obvious and compelling usecase off the top
of my head.

> I personally don’t care enough to implement it in 
> WeasyPrint (we don’t even have integer tab-size yet), but I don’t know 
> about other vendors. I can only notice that even <length> values for 
> tab-size are marked "at risk" in the draft.
> By the way, the em unit is not the width of the 'm' glyph.

My bad - I was thinking of the old typographic meaning. This shouldn't
detract from my main point however.

> It equals 
> font-size, the height of the "em box". Integer values for tab-size are 
> in multiples of the width of the U+0020 space. The ch unit is often much 
> closer to that than em, but might still be different for non-monospace 
> fonts.
> http://dev.w3.org/csswg/css3-values/#ch-unit

But space characters (like all characters) still differ in width from
one non-monospaced font to another. Assuming all characters are the same
width and thus asking us to specify widths in multiples of the space
character's width is a bit silly IMO. This sort of thing only ever made
any sense in the days of old character mapped displays and that was many
decades ago.

> In any case, your tabstop-widths proposed property could also accept 
> integer values. No need for a new unit.

Isn't an integer without a specified unit unusual in CSS? Anyway, my
main concern is that it should take a list of widths (instead of just
one), and that those widths can optionally be specified as px values.

Any more thoughts?

Received on Thursday, 3 January 2013 13:19:41 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:07 UTC