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

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


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

http://dev.w3.org/csswg/css3-values/#ch-unit

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

Cheers,
-- 
Simon Sapin

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