Re: Inline elements should be affected by 2D Transforms

On Jun 2, 2011, at 7:00 PM, Sylvain Galineau wrote:

> [Brian Blakely:]
>> Boris,
> 
>> That is why support for inline elements was originally removed.  Which is silly.
> 
> With respect, that is not quite why. A bunch of implementations producing differing
> outcomes given the same input can also be the symptom of a bigger problem: a lack of
> use-cases to define what the proper behavior should be. I think this is one of those
> and so do others on the WG; thus it would be most helpful if assertions of what should 
> happen were backed up with examples that demonstrate why a particular solution is the
> most desirable behavior. There are many examples in the real world that involve 
> transforming a block element. Transformations of inline spans inside a larger body of
> text is far less common afaik. But if you have several examples that concur then by
> all means let's talk about them.

Originally, I was talking about a bounding box around the whole inline element, not separate ones around each piece. But in thinking about it more, I think it should be more like what you are saying, where it is basically each continuous section of the line box that transforms. That is, the lengths of linebox that each contain as much of the inline element as is on that line, as it is visually laid out, even if some of it is bidi.

The most obvious use case I can think of is transforming the scale of some text in a link as you hover over it, making it zoom out larger (probably animated a bit). For something like that, you'd really want the transform origin to be inside the piece of text you are hovering over, which I think is Alan's point too. It wouldn't look so nice if the horizontal origin was in the middle of the whole line instead of just the piece at the beginning or ending of the line that you hovered over.

Some more esoteric (and entirely theoretical) use cases:

• A text editor, in which deleting text causes the text to shrink down and fly into a garbage can icon in the corner of the window. This also requires transforming from 'left:auto; top:auto;' to some whatever the coordinates of the icon are. In this case, treating each line as having separate chunks to transform and animate works well, but so can treating them as though they are both within a single bounding box that transforms.

• A text puzzle, in which spans of text, some broken over two lines, are scattered about a surface with various rotations. Then, clicking on the correct spot in the paragraph block causes the right one to animate from its current translation and rotation back into their default values. In this case, it would be important to keep the shape of each entire multi-line span the same as if it was still untransformed in the paragraph, breaks and all.

These last two are pretty fanciful, but show how being able to transform and animate inline elements can open up new powerful abilities to creative authors. I'm sure there are many others. Perhaps what we need is a way to choose which way an inline element should be animated, through a new property or new (compound?) values for transform-origin.

Received on Friday, 3 June 2011 16:38:03 UTC