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

Re: Agenda, 9 January 2014 SVG WG telcon

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 10 Jan 2014 08:35:11 +1100
Message-ID: <52CF160F.6040700@mcc.id.au>
To: "www-svg@w3.org" <www-svg@w3.org>
Minutes from the 9 January 2014 meeting are below.

http://www.w3.org/2014/01/09-svg-minutes.html



    [1]W3C

       [1] http://www.w3.org/

                                - DRAFT -

                     SVG Working Group Teleconference

09 Jan 2014

    [2]Agenda

       [2] http://lists.w3.org/Archives/Public/www-svg/2014Jan/0021.html

    See also: [3]IRC log

       [3] http://www.w3.org/2014/01/09-svg-irc

Attendees

    Present
           Doug_Schepers, Thomas_Smailus, krit, [IPcaller],
           birtles, ed, heycam, stakagi, nikos_, Tav, cabanier

    Regrets
    Chair
           ed

    Scribe
           Cameron

Contents

      * [4]Topics
          1. [5]Definition of rendered SVG elements
          2. [6]viewbox property
          3. [7]Intrinsic sizing problems
      * [8]Summary of Action Items
      __________________________________________________________

    <trackbot> Date: 09 January 2014

    <scribe> Chair: Erik

    <scribe> Scribe: Cameron

    <scribe> ScribeNick: heycam

Definition of rendered SVG elements

    <ed>
    [9]http://lists.w3.org/Archives/Public/www-svg/2013May/0000.htm
    l

       [9] http://lists.w3.org/Archives/Public/www-svg/2013May/0000.html

    birtles: this is a mail that was sent to the list last May
    which we didn't follow up

    <birtles>
    [10]https://svgwg.org/svg2-draft/struct.html#WAIARIAAttributes
    <-- "Rendered SVG elements can have role attributes"

      [10] https://svgwg.org/svg2-draft/struct.html#WAIARIAAttributes

    birtles: to summarise, according to our descriptions of the
    aria attributes, is says rendered elements can have role
    attributes
    ... the version of the spec that mail linked to said the same
    thing for aria attributes. but the recent version doesn't say
    that.
    ... the other issue that's related is in the table of
    attributes, there are lots of inconsistencies

    <birtles> this table
    [11]https://svgwg.org/svg2-draft/attindex.html#RegularAttribute
    s has lots of inconsistencies

      [11] https://svgwg.org/svg2-draft/attindex.html#RegularAttributes

    birtles: it says animateColor can have the role attribute,
    hkern can but vkern can't
    ... in definitions.xml, we haven't added the aria attribute
    groups to a lot of elements
    ... the email suggests that we make anything that inherits from
    SVGGraphicsElement have aria attributes, with the possible
    exceptions of defs and view

    <birtles> HTML:
    [12]http://www.whatwg.org/specs/web-apps/current-work/multipage
    /elements.html#wai-aria

      [12] 
http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#wai-aria

    birtles: I've had a look at HTML, and it says that you can use
    role and aria attributes on html elements, it doesn't restrict
    it
    ... I wanted to ask people familiar with accessibility whether
    there is any reason to restrict the attributes
    ... or if they should be allowed on all elements

    ed: SVGGraphicsElement doesn't include the <svg> element,
    right?

    heycam: I think it does
    ... my first thought is that if html allows it everywhere, and
    there is more accessibility focus in html, we should assume
    that it's ok for now

    <ed> to be clear, I wanted to make sure that you can use role
    on <svg>

    shepazu: we should ask rich when he's around
    ... I've heard people want to have aria attributes on
    animations
    ... if there are meaning animations, people would want to know
    what's going on
    ... what that actually means, not sure

    Thomas_Smailus: that sounds like a good goal

    shepazu: we do already allow aria attributes on SVG elements
    ... let's say a <circle> is animated, moving from left to right
    ... there might be some aria way of describing the scene
    ... it would be complex, it might be difficult to describe it
    in a meaningful way, but I have heard people say they'd like to
    see that
    ... maybe we only allow it on rendered elements first, and
    extend it to animation elements later

    birtles: I just don't know if there's any benefit to restrict
    it
    ... maybe there are elements where it doesn't make much sense
    to put a role, but is there a need to restrict that?

    shepazu: if you have a group that is in a <defs>, it's not a
    rendered element, but it's a graphics element
    ... the <g> element should allow role too

    <birtles> btw, here is an example of an SVG with roles and it
    uses them on <g>s:
    [13]https://static.mozilla.com/moco/en-US/images/mozilla_eoy_20
    13_EN.svg

      [13] 
https://static.mozilla.com/moco/en-US/images/mozilla_eoy_2013_EN.svg

    heycam: it's not really clear what "rendered element" means

    birtles: next step would be to get Rich's feedback

viewbox property

    <ed>
    [14]http://lists.w3.org/Archives/Public/www-svg/2013Dec/0093.ht
    ml

      [14] http://lists.w3.org/Archives/Public/www-svg/2013Dec/0093.html

    <birtles> I posted a summary:
    [15]http://lists.w3.org/Archives/Public/www-svg/2014Jan/0023.ht
    ml

      [15] http://lists.w3.org/Archives/Public/www-svg/2014Jan/0023.html

    birtles: I posted a summary yesterday of the feedback, 24hrs
    ago, since then a number of other bits of feedback have come in
    ... I was going to go through each of these issues and see if
    there is further input
    ... Doug I'll want your input in particular, as there are a lot
    of questions about the auto sizing
    ... to summarise the feature, there are two things
    ... first, promoting viewBox to a property, and second adding
    an auto sizing keyword
    ... first issue is the name
    ... I gave two options, "viewbox" or "view-box"; don't know if
    anyone here has any suggestions
    ... I lean towards no dash, but the tricky bit is if you have
    SVG in standalone documents you need to use the capital B

    heycam: have you asked CSS people about the name/

    birtles: had Tab's input, he didn't seem to mind without the
    dash
    ... Daniel Holbert said one thing to be aware of is that if you
    don't have a dash, then the property in the CSSOM will have a
    lowercase b
    ... that's the only input from CSS people

    <shepazu>
    [16]http://www.w3.org/TR/2012/REC-media-frags-20120925/

      [16] http://www.w3.org/TR/2012/REC-media-frags-20120925/

    shepazu: I've been thinking recently that maybe we should be
    integrating things from media fragments
    ... wondering if we should consider using syntax from media
    fragments
    ... they don't use "viewbox", they use "xywh"

    <shepazu> "xywh=160,120,320,240 "

    shepazu: in that way, it's also passed as a parameter in a url
    ... I wonder if there's any value in consistency in syntax
    between the URL syntax and the property
    ... we could also consider the other media fragment syntaxes --
    time for example, and relate them to our animations

    birtles: you're suggesting that is the name of the property?

    shepazu: which could then be overridding by the value in the
    URL fragment

    birtles: I'd like to see a bit more of the detail, can't quite
    see how it fits together

    shepazu: let's imagine the CSS property is called "xywh"
    ... it takes the same syntax as xywh in Media Fragments
    ... that would be your default
    ... if somebody gave a media fragment with xywh, we'd define it
    so that it overrides the value from the document
    ... the syntax of the value is the same, it's four numbers

    birtles: if you specify the viewBox attribute and xywh...

    shepazu: the idea that you could override the viewport with the
    Media Fragment, we could do that even if we did name it viewbox
    ... we don't have to have the same name. I just think the
    symmetry/consistency would be nice.

    Thomas_Smailus: is the intent that inside the document the
    Media Fragment would then take up the whole viewbox?

    shepazu: that section of the SVG takes up the whole viewbox,
    it's the same thing

    birtles: so it just sets the viewbox
    ... so do we name it to match the media fragment name or to
    match the viewBox attribute

    ed: you don't think it would be confusing with width and height
    attributes?
    ... and x and y?

    <svg x="10" y="10" widht="40" height="40" xywh="20 30 40 50">

    scribe: I would probably find that more confusing than viewbox

    shepazu: I don't think one is necessarily clearer, given a
    particular audience

    krit: there's not necessarily a win from the xywh name

    shepazu: if I did xywh on a video, it would show me the viewbox
    of that video. I'd like there to be some consistency with other
    kinds of media and SVG.
    ... doesn't mean we have to name it xywh

    krit: the thing I think is confusing is that SVG still do have
    media fragments on the outside
    ... but it wouldn't mean exactly the same thing as xywh on the
    <svg> element
    ... the media fragment one is like a clipping region
    ... the xywh/viewbox on the <svg> is some kind of a transform
    ... with translation and scaling

    shepazu: let me do some more research and I'll come back to you
    about that

    <shepazu>
    [17]http://www.w3.org/TR/2012/REC-media-frags-20120925/#naming-
    space

      [17] http://www.w3.org/TR/2012/REC-media-frags-20120925/#naming-space

    shepazu: the interesting things in there is that you can pass
    in parameters and you can pass in units
    ... px, or %
    ... which is not something we can do with viewbox
    ... maybe we shouldn't, I don't know
    ... but I found it interesting that you can pass in different
    units
    ... maybe this is orthogonal, perhaps we allow both viewbox and
    xywh as properties

    birtles: I don't know if it's possible to have media fragments
    add viewbox as an alias....

    shepazu: media fragments is not widely deployed
    ... I want there to be some relationship between media
    fragments and what we do with viewbox

    birtles: I'm concerned about the syntax thing, so if we're
    defining a property we shouldn't use "percentage:..."
    ... so assuming we don't make an xywh property name, any other
    input we have about viewbox vs view-box?

    shepazu: without the dash

    birtles: I don't know anything about how this mapping works
    ... is it feasible about adding an exception to standalone SVG
    so that it can parse viewbox with a lowercase b?

    shepazu: I feel that we should define a "viewbox" attribute
    with a lowercase b, and just say it's an alias or whatever we
    need to say to allow that

    heycam: it's always possible to just add another "viewbox"
    lowercase-b attribute

    Thomas_Smailus: what's the motivation?

    shepazu: it's a super common typo

    Thomas_Smailus: is camel case common?

    shepazu: common but inconsistent

    Thomas_Smailus: if reinventing from the ground up, I'd make it
    all consistently camel case or lowercase

    krit: atm SVG is based on XML, but for something based on HTML
    it wouldn't matter

    shepazu: I think we should have both attributes

    Tav: I'm a bit worried about that
    ... if we allow it there we might need to allow it everywhere
    ... it's a bit of a floodgate
    ... there is code that assumes presentation attribute names
    match the property

    shepazu: you could change the code pretty easily

    Tav: I was in the opposite direction. the basic thing is to put
    the document through the validator.

    shepazu: SVG in HTML, when you encounter <svg viewbox> it
    treats it like <svg viewBox>
    ... viewbox is the one attribute I've heard people have
    problems with

    Tav: so that attribute's the exception?

    shepazu: yes, for now
    ... in the future if we wanted to allow lowercase attribute
    names we'd solve that in a different way

    birtles: the other issues are less significant
    ... there's been a bit of feedback about the auto sizing
    behaviour
    ... and concern about using the stroked bounding box
    ... if you have an animated dash pattern, it's constantly
    changing
    ... I haven't gone through all the feedback yet
    ... I want to check that that property value is worthwhile
    having, given the issues surrounding it

    shepazu: I'd have to read the feedback
    ... if it's implementors whinging about a bit of extra code...

    birtles: some of that and author feedback
    ... let's leave that to the list then, follow up there

Intrinsic sizing problems

    birtles: I don't know if we can get through this in 10 minutes
    ... I prepared a summary
    ... a lot of tools write out SVG with an absolute width/height
    ... then documents don't resize as authors often want
    ... this came up in the context of the viewbox property
    ... someone thought it would be confusing to say viewbox:auto
    and then you wouldn't have this responsive behaviour because
    the authoring tool set width/height on the root <svg>
    ... in terms of the sizing/aspect ratio of the SVG, as soon as
    you specify absolute values for width/height, that determines
    the intrinsic size/aspect ratio
    ... otherwise the viewbox does

    <birtles> here is the mail:
    [18]http://lists.w3.org/Archives/Public/www-svg/2013Dec/0093.ht
    ml

      [18] http://lists.w3.org/Archives/Public/www-svg/2013Dec/0093.html

    birtles: that's the current behaviour

    <birtles> .my-hardcoded-svg {

    <birtles> width: auto !important;

    <birtles> height: auto !important;

    <birtles> viewbox: auto;

    <birtles> }

    birtles: Alex suggests a way to override it using an !important
    rule

    <birtles> ^ That is the proposed syntax

    birtles: there is also the proposal to promote
    preserveAspectRatio to a property, so that you can override
    what the authoring tool output
    ... there's also object-fit

    <birtles> my follow up mail:
    [19]http://lists.w3.org/Archives/Public/www-svg/2014Jan/0024.ht
    ml

      [19] http://lists.w3.org/Archives/Public/www-svg/2014Jan/0024.html

    heycam: I thought we had decided to use object-fit as our
    preserveAspectRatio-like property

    birtles: it seems to work at a different level
    ... object-fit sets the aspect ratio, then it determines a
    concrete object size
    ... that's given to SVG as a viewport
    ... then we use pAR to fit in to that viewport
    ... I guess you could specify object-fit in two places?
    ... when you're sizing an SVG image into an HTML <img> element
    ... if we were to make the property for pAR be object-fit,
    you'd need to specify it both on the <img> and on the root of
    the <svg>
    ... I'll follow up on the list; the one thing to come out of it
    is that interop is still not very good
    ... Alex had suggested that we have a concrete algorithm for
    calcaulting the viewport
    ... not sure if that's the answer, or if we need new tests, but
    his point is right that interop isn't great
    ... especially with replaced content
    ... no action to come out of this, but I'll follow up with Alex

    ed: might be good to have the summary on the wiki somewhere?
    ... I'm finding it hard to follow the threads and get a clear
    view of what's going on

    Tav: also a few demonstrations

    <scribe> ACTION: Brian to summarise sizing issues on the wiki
    [recorded in
    [20]http://www.w3.org/2014/01/09-svg-minutes.html#action01]

    <trackbot> Created ACTION-3556 - Summarise sizing issues on the
    wiki [on Brian Birtles - due 2014-01-16].

    <Tav> My connection just timed out...

    birtles: I won't promise to add any examples there, don't have
    time to do that, but I'll at least summarise the discussion

    <ed> trackbot, end telcon

Summary of Action Items

    [NEW] ACTION: Brian to summarise sizing issues on the wiki
    [recorded in
    [21]http://www.w3.org/2014/01/09-svg-minutes.html#action01]

    [End of minutes]
      __________________________________________________________
Received on Thursday, 9 January 2014 21:35:48 UTC

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