W3C home > Mailing lists > Public > www-style@w3.org > February 2011

Re: [css3-text] Tab U+0009 expansions to 8 spaces

From: Xaxio Brandish <xaxiobrandish@gmail.com>
Date: Thu, 24 Feb 2011 11:48:05 -0500
Message-ID: <AANLkTi=tMZKTA+tupTO0BXXMR_h4Fhifg2KP+Vyj-5EF@mail.gmail.com>
To: Brad Kemper <brad.kemper@gmail.com>
Cc: Koji Ishii <kojiishi@gluesoft.co.jp>, David Singer <singer@apple.com>, Anne van Kesteren <annevk@opera.com>, W3C style mailing list <www-style@w3.org>, Christoph Päper <christoph.paeper@crissov.de>
Good morning,

I'd just like to throw in my thoughts.  Building on what David said, the
width of a space can vary by font, font-size, character set, kerning, etc.
depending on the UA (correct?).  I am neither here nor there about length
being defined in other than "ch" at the moment (my only interest in this
matter is variable tab size, which was added to the draft).

With all of that being said, if having a non-character-width value is an
interest, it sounds like there's a good chance that it will provide a way to
standardize the amount of tab space used between renderings.

Let me present a couple of cases.

Case 1 (characters):

An outline is being made in a fixed-width word processor.  The outline is
transferred as-is to a UA, where it is rendered correctly using the CSS
white-space-collapsing value "pre" or "preserve".  The spacing in the UA
differs from that of the original word processor, so the tab length (in
characters) is increased in order to preserve the original look and feel as
much as possible without having to add outline formatting markup.

Case 2 (length):

Data is present in a tab-delimited file used for inter-system data
transfer.  The data is sometimes reviewed by human eyes before being
imported.  Because this data is occasionally viewed remotely, the UA uses a
mobile media stylesheet in those cases to shorten the tab length.

In order to save as much space as possible, the font used on the mobile
device is not fixed-width.  The author of the mobile stylesheet wishes to
base his/her spacing as a percentage of the device viewport width rather
than the font used.


On Thu, Feb 24, 2011 at 10:08 AM, Brad Kemper <brad.kemper@gmail.com> wrote:

> I think it needs to have a <length> if it is to be definable at all. That
> is more normal for tabs (in word processing, graphic design, etc.) than
> counting out space characters.
> On Feb 23, 2011, at 11:33 AM, Koji Ishii wrote:
> > Thank you all for the information for the implementations. We have added
> the property to the Editor's Draft[1].
> >
> > We didn't add <length> version though, as existing implementations don't
> support it, and we could add it in future if we've got enough interests from
> implementers.
> >
> >
> > Regards,
> > Koji
> >
> > [1] http://dev.w3.org/csswg/css3-text/#tab-size
> >
> > -----Original Message-----
> > From: www-style-request@w3.org [mailto:www-style-request@w3.org] On
> Behalf Of David Singer
> > Sent: Tuesday, February 22, 2011 2:25 AM
> > To: Anne van Kesteren
> > Cc: W3C style mailing list; Christoph Päper
> > Subject: Re: [css3-text] Tab U+0009 expansions to 8 spaces
> >
> >
> > On Feb 21, 2011, at 4:22 , Anne van Kesteren wrote:
> >
> >> On Mon, 21 Feb 2011 13:15:25 +0100, Christoph Päper <
> christoph.paeper@crissov.de> wrote:
> >>> Robert O'Callahan:
> >>>> Gecko already supports a "-moz-tab-size: <number>" property.
> >>>
> >>> Wouldn't <length> be more useful, preferably given with proposed unit
> 'ch'?
> >>
> >> No need to make something simple so complex. Tab expansion is defined as
> number of spaces pretty much universally.
> >
> > It's pretty universally defined to allow for vertical alignment.  That's
> pretty rarely a fixed number of spaces, specially when spaces have a 'soft'
> width (e.g. in justified-right text).  Even microsoft word sets them on a
> regular ruler...
> >
> >
> > David Singer
> > Multimedia and Software Standards, Apple Inc.
> >
> >
> >
Received on Thursday, 24 February 2011 16:59:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:43 UTC