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

Re: [css3-2d-transforms][cssom-view] Transforming text from the baseline

From: Thomas Phinney <tphinney@cal.berkeley.edu>
Date: Mon, 21 Feb 2011 16:06:23 -0800
Message-ID: <AANLkTind8m5VOMxtTV=92cYpOPqg5f1SROf=Ymu1dvb9@mail.gmail.com>
To: Dean Jackson <dino@apple.com>
Cc: Jon Rimmer <jon.rimmer@gmail.com>, www-style list <www-style@w3.org>
I assume the intent is to have it be the baseline of the first line of text
in the block (mainly useful for single-line text blocks). You might want to
be explicit about that, though. It does seem quite useful in certain cases.

Cheers,

T

On Mon, Feb 21, 2011 at 1:50 PM, Dean Jackson <dino@apple.com> wrote:

> I think this is an interesting idea, and worth considering. The
> transform-origin property matchs background-position, so I think the
> discussion is not limited to transforms.
>
> Dean
>
> On Feb 20, 2011, at 2:50 PM, Jon Rimmer wrote:
>
> > I have recently been experimenting with using CSS3 to animate text[1]
> > in the manner termed 'kinetic typography'[2]. One problem I've
> > encountered is creating transforms whose origin is the baseline of
> > some text[3]. While there are workarounds, I think it would be very
> > useful if CSS supported declaratively setting a transform's origin to
> > be the baseline, and programatically retrieving the position of a
> > baseline for an element. I'm not aware if there has already been any
> > work in this area, but my proposals would be as follows:
> >
> > Allow the transform-origin property to have a value of 'baseline':
> >
> > #element {
> >   transform-origin: left baseline;
> > }
> >
> > In the case of an inline-level element, this would cause the origin of
> > the transform to be the position of the baseline in the element's
> > first inline box. For a block-level element, the origin would be the
> > position of the baseline in the first inline box of the block's first
> > inline-level element (which might be anonymous). If the block
> > contained no inline-level elements at all, it would be equivalent to
> > the default value of 50%.
> >
> > This could be extended further, to allow specifying other line
> > positions such as sub or super, or non-dominant baselines via some
> > syntax like baseline(ideographic), but it seems like just allowing
> > 'baseline' would cover 99% of the likely use-cases.
> >
> > I also propose making it possible to retrieve the baseline position
> > via script. I was quite surprised that there did not seem to be a
> > standard, non-hacky, way to do this. If there is, and I'm just not
> > aware of it, please disregard this. Otherwise, I suggest an additional
> > extension to the HTMLElement interface, similar to those already
> > defined in the CSSOM View Module. Something like 'baselineOffset'
> > that, when called on an element, would return the size of the gap
> > between the baseline and the top of the element's first inline box's
> > content-area, where the inline box is determined in the same manner as
> > described above, and 'top' is whichever edge is appropriate as per
> > bidi requirements (which I won't pretend to understand).
> >
> > I'm hopeful that, given that the baseline information must already
> > exist within layout engines, implementation would not be unreasonably
> > hard.
> >
> > Any questions? Comments?
> >
> > [1] http://www.brillskills.com/fu/ (requires a webkit-based browser)
> > [2] http://en.wikipedia.org/wiki/Kinetic_typography
> > [3] http://www.brillskills.com/kinetic/
> >
> > Jon Rimmer
> >
>
>
>


-- 
“Puritanism: The haunting fear that someone,
 somewhere, may be happy.”
 —H.L. Mencken
Received on Tuesday, 22 February 2011 00:06:58 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:37 GMT