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

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

From: Simon Sapin <simon.sapin@kozea.fr>
Date: Wed, 02 Jan 2013 17:30:52 +0100
Message-ID: <50E460BC.1030806@kozea.fr>
To: Nick Gravgaard <me@nickgravgaard.com>
CC: www-style@w3.org
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.)

> 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.

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 said, I donít know if the use case is strong enough to justify 
adding this. 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. 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 


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

Simon Sapin
Received on Wednesday, 2 January 2013 16:31:21 UTC

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