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

On Thu, Jan 3, 2013, at 14:10, Simon Sapin wrote:
> Le 03/01/2013 14:19, Nick Gravgaard a écrit :
> > 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.
> 
> Integer values are not as common as length, but they are used in CSS 
> counters, orhpans/widows, z-index, etc.

Yes, you're right but that's because in those examples units don't make
sense. Surely the distance between tabstops should be measured in what
the spec calls "Distance Units"? In this case surely positive
font-relative length units (‘em’, ‘ex’, ‘ch’, ‘rem’) and positive
absolute length units (‘cm’, ‘mm’, ‘in’, ‘pt’, ‘pc’, ‘px’) make sense?

> Integer tab stops make sense with monospace fonts (although the ch unit 
> now covers that use case.) But more importantly this is about 
> compatibility with existing content. If your proposal is accepted, I 
> think that tab-size should become a shorthand property for 
> tabstop-widths. So the latter must have equivalents for all of the 
> former’s valid values.

Yes, I was going to mention something along these lines. If this was
done I suppose integers without units should have the old meaning.

Alternatively integers without units could be assumed to be 'ch' units.
Reasons:
  * The width of the "0" glyph will be the same as a space character's
  width for a monospaced font, and surely everyone who's currently using
  this attribute is using it with monospaced fonts (as it currently
  doesn't make much sense for non-monospaced fonts).
  * The meaning of the 'ch' unit is better known than "the measure as
  multiples of the space character's advance width (U+0020)", so this
  makes use of a more commonly used unit type rather than having one
  that's only used by this attribute.
  * On non-monospaced fonts the space character is usually very thin
  (but this is moot anyway as using the existing attribute with
  non-monospaced fonts is silly).

Either way, as stated before, it is important that the attribute should
take a list of widths (instead of just one), and that those widths can
optionally be specified as px values.

Received on Thursday, 3 January 2013 15:00:37 UTC