Re: Inline elements should be affected by 2D Transforms

1. The desired behavior is very dependent upon your application.   If you
want to rotate an entire paragraph, then it's inappropriate to transform
line-by-line.  On the other hand, for blocks of text that reflow across
region or page boundaries, transforming line-by-line is the only sensible
approach.

Clearly authors need to be able to describe a block of text that flows in
the correct manner but that is kept together.  This, of course, is one of
the purposes of inline-block. Hence restricting transforms to situations in
which author intent is clear (e.g. when they have explicitly marked text as
a single unit by placing it in a display:inline-block span) is very
sensible.

2. It is true that some artifacts are introduced when using inline-block on
single characters.  These artifacts are:
  a. space characters are collapsed when isolated in a span
  b. word boundaries are not respected when words are split across multiple
spans with different display settings.
It is possible that one or both of these could be considered bugs - I don't
know enough of the specifics of word boundary detection to be
sure. Nevertheless it is completely possible to work around these issues,
e.g. for the purpose of slightly transforming individual characters in a
word.  For example:

.word {
  display: inline-block;
}

.transformMe {
  display: inline-block;
  transform: ...;
}

This is <span class="word">s<span class="transformMe">o</span>me</span> text

Reflows exactly as you would expect and works very nicely.

Cheers,
    -Shane

On Sat, Jun 4, 2011 at 4:27 AM, Brad Kemper <brad.kemper@gmail.com> wrote:

>
>
> On Jun 3, 2011, at 10:58 AM, Boris Zbarsky <bzbarsky@MIT.EDU> wrote:
>
> > On 6/3/11 1:49 PM, Brad Kemper wrote:
> >> Ah. I would expect "TXET" to stay put, and "some" and "WERBEH" to rotate
> as a unit, with the "s" at the top and the "H" at the bottom.
> >
> > Hmm...  OK.
> >
> >> If the span had, say, a green background, you'd see that "some" and
> "WERBEH" were two separate boxes, right?
> >
> > Absolutely.
> >
> >> Yet, being a single element, they rotate as a unit, just as changing the
> color once affects both of the two boxes.
> >
> > Ok.
> >
> >> There's probably some more complications if there is a line break in
> there somewhere, too, right? Throw another one at me and I'll tell you what
> my intuition says.
> >
> > Well, one obvious complication is that changing the color changes it for
> all the boxes for the span, across all lines, but you sound like you would
> apply the transform on each line separately....
>
> Yes. If I change the bg color, I can see that there is another box on the
> next line that is not physically connected to the first. So it is not
> unreasonable to treat it separately  The reason I would do so, with per-line
> transformations within a single element, is so that transform-origin gives
> reasonable results for :hover-ed text.
>
> > As for the interaction of bidi and linebreaks, my bidi fu is not strong
> enough to poke the edge cases.
>
> Yeah, I'm in the same boat (with my Fu poking).
>
> > Would be nice if someone who understands that stuff could step in.
>
> Agreed.
>
> > Note that the line case, unlike the bidi one, can happen with blocks too
> (columns), so we sort of need an answer to it no matter what.
>
> Right. And there it would be even more evident that you'd want two
> different origins for the transform, if you are using it to call attention
> to text that is being hovered. You don't want the text to jump away from the
> cursor, you just want it to get bigger (or whatever) underneath the cursor.
>