- From: Xaxio Brandish <xaxiobrandish@gmail.com>
- Date: Thu, 24 Feb 2011 11:48:05 -0500
- 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>
- Message-ID: <AANLkTi=tMZKTA+tupTO0BXXMR_h4Fhifg2KP+Vyj-5EF@mail.gmail.com>
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. --Xaxio 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