W3C home > Mailing lists > Public > www-svg@w3.org > December 2014

Re: SVG 2 high value use cases based on StackOverflow questions

From: Paul LeBeau <paul.lebeau@gmail.com>
Date: Fri, 5 Dec 2014 03:44:14 +1300
Message-ID: <CACfsppDOFkZehwYa0-zR5OTBZvzQ9UYQAzUn_UcUaGMng5oKKw@mail.gmail.com>
To: Erik Dahlström <ed@opera.com>
Cc: www-svg <www-svg@w3.org>
What I neglected to mention in my first email was that I was aware that
some of these were being discussed and addressed  My motivation was to
enumerate all the common use cases I could think of, that appear regularly
in StackOverflow.  (a) so that people have info on what use cases are
common, and (b) so we don't have a situation after SVG2 is released where
people say "hey everyone knew this was an issue, why wasn't it addressed?".

If I had thought about this a year ago, I would have kept some metrics.
Rather than relying on memory :)


> On the positive side (in the shorter term), you can find some really nice
articles written recently on this topic

Just to be clear, I, myself, am familiar with how viewBox works.  I've
explained it enough times on SO. :)  And I knew about "auto".  That's why I
mentioned it.  I hope it makes it into the spec.


> If all the baseline properties in SVG 1.1 were supported, would that be
enough to address these use-cases? If so, what browsers have bugs blocking
the use of this? If there are bugs, is the spec clear enough?

None of the baseline properties cover the case of exact vertical centering
of a glyph at a given point  Using alignment-baseline="middle" kind-of
works for a line of text if you have a mix of ascenders and descenders.
But doesn't really work for single characters.

Example question:
http://stackoverflow.com/questions/26600027/center-a-character-in-svg/

Another recent poster (I can't find the link right now) was dynamically
generating a line graph where each point was labelled with a number inside
a circle.  alignment-baseline doesn't work in this case because the digits
will be positioned too high in the circle (because they don't have
descenders).  You can reposition by a few pixels or by "0.3em" etc, but the
whole shebang is font dependent.  And it breaks again if the specified font
is not present.

And you can't fix it with JS either because getBBox() doesn't return the
tight bbox, and there is no access to font metrics.

There is one ugly workaround, which is to embed the character using
<foreignObject> and use vertical-align="middle".  But that is horrible, and
now you have to teach people how to use foreignObject. :)


> Does https://svgwg.org/svg2-draft/painting.html#VectorEffects address the
non-scaling part sufficiently in your opinion?

Quite possibly.  I haven't yet looked closely enough at it to be sure.

What I think I might do now is start gathering responsive SVG questions
from SO, so we have a corpus of use cases.  And see how many can be
achieved with what is in SVG2 already.


Paul



On 4 December 2014 at 22:31, Erik Dahlström <ed@opera.com> wrote:

> Hi Paul,
> thank you for bringing this up, this is good feedback.
>
> A small request from me (to everyone): if you are proposing new features
> for svg2, I'd like to ask that you please first check the list of svg2
> requirements[1] that were collected before starting on svg2.
>
> If the feature has been requested/proposed before, please feel free to
> bring up the topic again, but also include a link to the existing proposal
> from [1] and the associated issue number if any (since tracker picks it up
> and links to your mail automatically if you include this as text like
> ISSUE-nnnn).
>
> On Thu, 04 Dec 2014 03:37:00 +0100, Paul LeBeau <paul.lebeau@gmail.com>
> wrote:
>
> ...
>
>> *viewBox*
>>
>> ViewBoxes seem to be an endless source of confusion.  Trying to explain
>> how
>> to calculate a viewBox can be hard.  I think that supporting
>> viewBox="auto"
>> would be very useful to SVG beginners.
>>
>
> This has come up in previous discussions as ISSUE-2378 [2]. I agree that
> this is can be a pain point for new users. Also see the proposal to make a
> view-box property [3], which also included this feature.
>
> On the positive side (in the shorter term), you can find some really nice
> articles written recently on this topic, see [4], and there have been
> others in the past too including pretty much every book on svg in
> existence, one recent example is the SVG Pocket Guide [5].
>
>  *Vertical centering of text*
>>
>> People are always wanting to center text in circles and rectangles.  At
>> the
>> moment there is no reliable way of vertically centering.
>>  alignment-baseline support is not universal and depends on the font (?),
>> and doesn't support the most common use case.  Usually people want to
>> perfectly center the glyph bbox (not the Em box).
>>
>
> We've had requests for exposing more font-metrics, which was deemed to be
> outside the scope of SVG. But vertical centering of text in svg is
> certainly something we could address, and I have seen a number of people
> asking how to do this.
>
> I think needs some more evaluation, if all the baseline properties in SVG
> 1.1 were supported, would that be enough to address these use-cases? If so,
> what browsers have bugs blocking the use of this? If there are bugs, is the
> spec clear enough?
>
>  *Responsive sites*
>>
>> This is a biggie.  Common things people want to do when using SVG in
>> responsive websites include:
>>
>> - Elements whose scale is not affected by preserveAspectRatio
>>       - circles that don't squash
>>       - clipped images - clip squashes but not the image it is clipping
>> - Patterns that whose scale is not affected by preserveAspectRatio
>> - Percentage path coordinates
>>
>> Example:
>> http://stackoverflow.com/questions/27070929/certain-
>> parts-of-typography-letters-respond-to-width-height-of-window
>>
>
> Does https://svgwg.org/svg2-draft/painting.html#VectorEffects address the
> non-scaling part sufficiently in your opinion?
>
> Percentages in paths opens up the question of whether we should support
> all units inside the path data syntax. Discussed previously [6][7], and
> also in the context of the Motion path Module [8].
>
>  *Relative positioning*
>>
>> Another common request is being able to position elements relative to
>> other
>> elements.  Not sure how I feel about this, but it comes up quite a lot.
>> People are used to the HTML layout model, I guess.
>>
>
> There are some old editor's drafts for this[9][10], but note that these
> have not been published as working drafts, and aren't active atm.
>
>
> [1] https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_
> Mailing_List_Feedback
> [2] http://www.w3.org/Graphics/SVG/WG/track/issues/2378
> [3] http://lists.w3.org/Archives/Public/www-svg/2013Dec/0080.html
> [4] http://sarasoueidan.com/blog/svg-coordinate-systems/
> [5] http://svgpocketguide.com/book/
> [6] http://lists.w3.org/Archives/Public/www-svg/2013Oct/0003.html
> [7] http://www.w3.org/2014/08/26-svg-minutes.html#item10
> [8] http://dev.w3.org/fxtf/motion-1/#funcdef-path
> [9] http://dev.w3.org/SVG/modules/layout/publish/SVGLayout.html
> [10] http://dev.w3.org/SVG/modules/layout/publish/SVGLayoutReqs.html
>
> --
> Erik Dahlstrom, Web Technology Developer, Opera Software
> Co-Chair, W3C SVG Working Group
>
>
Received on Thursday, 4 December 2014 14:45:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:58 UTC