W3C home > Mailing lists > Public > www-svg@w3.org > January 2016

Re: Text issues for Sydney F2F

From: Sebastian Zartner <sebastianzartner@gmail.com>
Date: Fri, 29 Jan 2016 12:14:32 +0100
Message-ID: <CAERejNYoE2sgXxLqkeV84DKek6=UQC31pqT7yPv=kpiMsQHezw@mail.gmail.com>
To: Tavmjong Bah <tav.w3c@gmail.com>
Cc: David Dailey <ddailey@zoominternet.net>, www-svg <www-svg@w3.org>
On 29 January 2016 at 09:46, Tavmjong Bah <tav.w3c@gmail.com> wrote:
> On Thu, 2016-01-28 at 17:14 -0500, David Dailey wrote:
>> -----Original Message-----
>> From: Tavmjong Bah
>> Sent: Thursday, January 28, 2016 3:33 PM
>>
>> I've written up most of my text issues for the Sydney meeting. Please
>> have a look at:
>>
>>       http://tavmjong.free.fr/SVG/TEXT_SYDNEY_2016/
>>
>> ---------
>>
>> Hey Tav,
>>
>> Looks good. I would agree that " Stand-alone SVG renderers should not
>> need to deal with this extra level of complexity. " SVG should not be
>> made any more dependent than it is on having a full-fledged browser
>> running since that is not the only environment in which it is used,
>> authored, displayed, etc. Perhaps opinions of users are of
>> increasingly less interest to the working group, since nowadays we
>> hear that implementation (as driven by browsers) drives new features
>> rather than interest, use cases, or principles of good architecture
>> (whatever those might be).
>>
>> However, I don't see among your examples, stuff dealing with aligning
>> text to alternative or dual baselines, as discussed at say here [1]
>
> I think there is definitely interest within the group for this but we
> have limited resources and needed to make a hard cut on what is going
> to be in SVG 2 or it would never get out.

To 1:
I agree with SVG Text uses CSS, SVG Text is not CSS text. Having said
that, SVG Text should be based on CSS Modules were applicable and only
outline any differences. That makes it easier for spec. authors like
you, Tav, as they have to write less, and it makes it easier for web
authors/users, because the differences between both will be minimized,
i.e. the "why does this behave different in SVG than in CSS" effect
will be reduced.

To 3.1:
I favor Chrome's behavior ignoring any line grid. This allows to use
the available space optimally. If predictability of where the first
line is placed is wished (e.g. to allow aligning text inside a shape
vertically with one outside of it), I suggest to introduce a CSS
property to control that.
In any case, the behavior must be specified to avoid having different
results in different UAs.

To 3.2:
I'm in favor of solution 2 with the constraint that it should be
controllable whether to clip the text, show an ellipse or display it
outside the shape. Though solution 3 proposed by CSS Shapes 2 sounds
bad to me (at least if that was the default), as the text outside the
shape may overlap other contents.
Note that CSS Shapes 2 doesn't currently define where the overflowing
text is placed exactly. This may not necessarily be below the
rectangular bounds but could also be above or besides the element.

To 3.3:
'wrap-flow' should get a new value specifying that the text can be
split into parts in those cases.

To 3.4:
Yes, CSS Regions seems to be the right place, maybe in combination
with CSS Shapes. Though to work in SVG it looks like CSS Regions needs
some work in regard of how named flows are created.

Greetings,

Sebastian
Received on Friday, 29 January 2016 11:15:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:43 UTC