- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 10 Jan 2014 08:35:11 +1100
- 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:47 UTC