Re: SVG text wrapping (was: minutes, Tokyo 2013 SVG F2F Day 2, 4 June 2013)

Hi, Brian, Alex-

On 6/6/13 4:10 AM, Alex Danilo wrote:
> Hi Brian,
>
> --Original Message--:
>> (2013/06/04 18:20), Cameron McCormack wrote:
>>>      krit: what about using the text area element from 1.2?
>>>
>>>      heycam: the name is bad
>>>
>>>      shepazu: in 1.2 we define an algorithm and I don't think that's
>>>      a good idea for what I'm proposing
>>>      ... I just want to make it super easy to use and intuitive and
>>>      rely on the behaviour that comes out of CSS
>>>
>>>      krit: the switch of behaviour of the text element with
>>>      exclusion or width and height is confusing to me
>>>      ... for shapes suddenly x and y are not relevant anymore
>>>      ... and for your propsal y changes meaning
>>
>> Sorry, I guess I wasn't following the conversation properly at this
>> point but I just want to second Dirk's point here.
>>
>> I find the idea that x/y change meaning depending on the presence of the
>> width attribute surprising. I can certainly imagine authors cursing SVG
>> at the top of their lungs when their carefully positioned textbox
>> suddenly shifts up because they removed a width attribute (which may not
>> have even been having a noticeable effect depending on its value).
>>
>> (And I can likewise imagine WONTFIXing the corresponding bugs they file
>> on UAs when they finally discover the link between the vertical jump and
>> the presence/absence of the width attribute.)
>>
>> But perhaps I have misunderstood the proposal?
>
> Actually this isn't Doug's proposal. It's how Cam prototyped an implementation.
>
> Doug originally intended that the x, y stay the same regardless of the presence of a width
> attribute. Cam just did a quick implementation and I guess for expedience made the
> x,y the flow bound box origin.
>
> So, the text would not jump based on the presence of the width attribute.

Thanks, Alex! Yes, that's correct, and I agree with you, Brian.

I've now clarified my proposal on this point (see "Positioning (x and y)"):
  http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Wrapping_Text

Another flaw to shifting the y-origin be default is that it is worse for 
the fallback case, where a browser doesn't yet support width.

However, I agree with Cameron that empowering authors to explicitly set 
the y-origin to align to the top of the rendering area is a good idea, 
and alignment-baseline:top will let them do that (as I mention in the 
updated proposal).



>> If not, is it too late to consider <textbox>, <textrect> or some other name?
>
> I wish that 1.2 Tiny had never chosen textArea and stuck with the original naming
> since that would have been so much better. It's actually a very useful primitive
> for embedded engines doing TV guides and the like - but alas that's not the
> general web...

I proposed <textshape> for SVG Tiny 1.2, but alas, my feedback came too 
late for existing implementations.

I still maintain that allowing authors to specify a width for <text> is 
more intuitive and has a better fallback than a new dedicated element, 
and I don't think it results in behavior any more confusing than any 
other property that changes the text positioning... for example, 
alignment-baseline or text-anchor.


Brian, does this address your concerns? Do you still have worries about 
this proposal?

Regards-
-Doug

Received on Thursday, 6 June 2013 14:08:34 UTC