- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 6 Nov 2015 08:43:27 +1100
- To: www-svg <www-svg@w3.org>
The minutes from a telcon today are here:
http://www.w3.org/2015/11/05-svg-minutes.html
and as text for bots, below.
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
05 Nov 2015
[2]Agenda
[2] https://lists.w3.org/Archives/Public/www-svg/2015Nov/0011.html
See also: [3]IRC log
[3] http://www.w3.org/2015/11/05-svg-irc
Attendees
Present
ed, heycam, Tav, stakagi, BogdanBrinza, AmeliaBR, nikos
Regrets
Chair
Cameron
Scribe
Cameron
Contents
* [4]Topics
1. [5]https://lists.w3.org/Archives/Public/www-svg/2015Oc
t/0036.html
2. [6]Removal of viewTarget attribute
3. [7]SVG 2 progress update
* [8]Summary of Action Items
__________________________________________________________
<trackbot> Date: 05 November 2015
FYI, the meeting access code has changed
644 384 016
<shepazu>
[9]https://mit.webex.com/mit/j.php?MTID=mfbd328afdc7c85003ed6c8
7919f43c67
[9] https://mit.webex.com/mit/j.php?MTID=mfbd328afdc7c85003ed6c87919f43c67
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
[10]https://lists.w3.org/Archives/Public/www-svg/2015Oct/0036.html
[10] https://lists.w3.org/Archives/Public/www-svg/2015Oct/0036.html
Removal of viewTarget attribute
AmeliaBR: viewTarget lets you identify a target element
... it was designed to allow extra highlighting styles
... right now it doesn't have an effect
... but it could be important and useful for making views
accessible
... right now when you define a view, you're defining a
rectangle that you're linking to, but that doesn't say anything
about what actual content is inside the content is interesting
... if you have a screen reader, it could theoretically try to
guess based on what's visible, but it's not going to be as
effective as simply having the author say "show this view, and
here's the important item in the view which is the focus of the
link"
... and that would allow screen readers to have that link be
meaningful
... right now, from a meaning perspective, and for
target/styling, you have to choose if you're targeting an
element or targeting a view
... if viewTarget was properly supported by screen readers, and
as originally intended for :target stylilng, then you'd be able
to do both
... here's a link to the document, here's the rectangle you
should display, and here's the content inside the rectangle
that it's going to
shepazu: we've tried to specify this before, maybe not all the
details you mentioned
... I don't think there's any problem with doing so
AmeliaBR: there are two sides of it. one is to trigger the
:target pseudoclass for CSS styling, and there's whether it
should have a meaningful connection for screen readers
... right now, afaik, screen readers don't do anything special
for views
... and it might end up being a dead link, as they don't see
<view> as something that is rendered
... afaik it is treated as a link to an element, and the screen
reader will you're assume you're "at" the <view> element in
terms of reading the document
shepazu: I'm all for specifying that kind of thing. are you
volunteering to do that?
AmeliaBR: the draft writeup is in the SVG Accessibility
Mapping, but it was based on the assumption that this
viewTarget="" was in SVG
... and as we were reviewing, we discovered the removal of the
attribute
heycam: what was I testing, do you recall?
AmeliaBR: the tests that you had were for viewTarget="" to
actually create a view based on an object bounding box, which
was never something that was in the spec
heycam: I see
AmeliaBR: that's one thing. the viewTarget="" doesn't actually
change the view, and was never supposed to. you'd still need to
use a viewBox="" to define the rectangle.
heycam: ok. on that basis I would be fine for it to be
reinstated.
AmeliaBR: are people interested in ensuring that viewTarget=""
triggers :target style?
shepazu: I think that's the cleanest way of doing it
heycam: how do implementations do with bare identiifier :target
styling?
AmeliaBR: it's mostly implemented as it works in HTML. I did
find that Firefox had an issue where it wouldn't recognise a
<view> element has having that class, so you can do it with the
sibling selector trick
... if you markup is correctly arranged
heycam: ok I guess now with inheriting from HTMLElement we get
class=""
... on <view>
... the only thing I could possibly imagine being a difficulty,
is if both the <view> and the viewTarget="" match :target
AmeliaBR: well, viewTarget="" also allows multiple elements to
be listed
... so it could be a problem for implementations
... but generally, :target is a host document language thing
... it's just the case that the way it works in HTML is what
CSS has been based on
... I don't think anyone ever implemented the xlink target
things, which could in theory do the same thing, but I don't
think there are practical implementations of it
BogdanBrinza: from your email, I quite like the aria attribute
approach
... in every screen reader that would need that functionality,
you'd need to add special handling for viewTarget, so ...
AmeliaBR: it would be part of the "SVG Accessibility Mapping"
spec, which is defining how native SVG elements get mapped to
ARIA-type behaviour
... so the browsers would have to know what an SVG <view> is
and how it affects the accessible representation of the
document, but individual screen readers would not
BogdanBrinza: if web authors provide already aria attributes
[is that enough?]
AmeliaBR: there will need to be specific rules for <view>s
anyway, as there are other ways in which they're unlike HTML
... as I said, we could put a lot of new authoring guidance out
there to encourage people to use a new authoring pattern, when
there's an existing authoring pattern in the spec, I'd rather
use that, and get some backwards compat from that
... the other thing is the svgView target fragment, if I'm as
an author using someone else's SVG image, and I want to
highlight a specific part of it, I can create a view in the URL
... and in that case there isn't an element in the document I
could put some aria- attributes on, it's only what I can put in
the URL, and again we have this previous spec that says you
could put a viewTarget in the URL
... so you would have both the rectangle and the element you're
interested in, and you could communicate both
... and there's no way to do that with aria without modifying
that document
shepazu: aria is also not meant to invoke special magical
behaviour, but rather just be instructions to an AT
BogdanBrinza: for the presentation aspect, it would be hard to
solve without those attributes
<ed> regarding the viewSpec syntax for links, is that
information typically exposed in screen readers?
BogdanBrinza: about existing patterns, at the meeting, people
were unclear about the use of viewTarget=""
... so I wonder whether it really is an existing known pattern
AmeliaBR: the intended purpose was for :target styling, and
that was never clearly defined/implemented
... so there's probably not a lot of content out there
... <view>s aren't used as much as they could be
shepazu: it's a bit chicken-and-egg
AmeliaBR: in all things accessibility-related, it's hard to
convince them to put things in the document without visible
impact
BogdanBrinza: specifically for viewTarget="", we couldn't
identify the functionality that was supposed to be associated
with it
... we didn't discuss the styling/metadata aspect
... different people had different expectations about what it
was meant to do
... and so I imagine authors would similarly be unclear about
what viewTarget="" is for
shepazu: is it similar enough in HTML or CSS that it could be
familiar, or is this just based on it being in the spec before?
AmeliaBR: if the alternative in aria doesn't have the potential
to be extended to the #svgView fragment syntax...
BogdanBrinza: I don't think aria- attributes will solve all
issues, like the presentation aspects here
... might it be worth talking with the a11y TF to find out what
kind of use cases we want to solve with it?
AmeliaBR: certainly having a clear description is one thing.
the fact that members of this WG weren't sure what it was
supposed to do is telling
... but as far as educating authors, the viewTarget="" has the
same meaning as the target you would use as an ID when linking
to an element
... SVG has added feature that you don't just scroll to that
element, you want to define a 2D view, so you link to the
<view>, and the viewTarget="" provides that extra connection to
the element in question
shepazu: in terms of familiarity to authors, I agree it's not
been traditionally used
... however this does seem to be the intuitive thing to do
BogdanBrinza: I don't have objections to specifying it this way
<ed> would viewTarget be different from the <svg> element that
contains the <view> element?
BogdanBrinza: but at the same time I feel like it might not be
enough to solve the problem
AmeliaBR: in the TF, we were trying to make sure that views are
meaningful
... because you often link to a view, you need to make sure
that when you follow that link, you end up somewhere meaningful
... and they don't end up in a random spot in the document, and
which is unrelated to the intended perspective that a visual
viewer would have
... if I as a visual viewer, and I click on a link and it zooms
to a specific section of the graph, I would expect the screen
reader to do something similar, and start reading from there
... so we need clear rules that views actually work that, so
that the screen reader perspective matches the visual
persecptive
... part of that is author guidance to use these extra
attributes, just like we suggest to use titles and
descriptions, etc.
... but part is also that browsers are able to go from the
visual view to the content
shepazu: and to be clear, not everybody has accessibility needs
is using AT, or if they are, they might be using say a screen
magnifiier, not a screen reader...
... can I suggest a path forward? maybe Amelia we can write up
some use cases for the a11y TF, say this is how was specified,
and then see if there might be a better way to define it
... and then come back to this group with a recommendation?
AmeliaBR: I can do that
... I was going to offer to rewrite up the text for the SVG
spec that would build on what was in SVG 1.1 but clarify things
a bit better than they had been, and at the same time I'll come
up with a couple of examples of how it should work if everythin
was implemented the way it want to be
... and examples of good authoring practice so that something
still makes sense even in an existing behaviour that doesn't
have the special rules
shepazu: I think Bogdan was making the point that if it was
specified at one point, it was underspecified, so let's look at
it again and see if it meets the use cases that modern authors
expect
... and come back to the group with that. it may or may not
match what the spec had before
BogdanBrinza: that sounds like a good plan
shepazu: Amelia I'll touch base with you on this one. there may
or may not be something from 1.2T to reuse here.
<scribe> ACTION: Amelia to draft text related to viewTarget and
some examples [recorded in
[11]http://www.w3.org/2015/11/05-svg-minutes.html#action01]
<trackbot> Created ACTION-3827 - Draft text related to
viewtarget and some examples [on Amelia Bellamy-Royds - due
2015-11-12].
SVG 2 progress update
heycam: let's just get an update on where people are with their
chapters
... Types and Style are done. Painting has two issues left: one
is about marker orientation, just needs copying some text into
the chapter, second is about the new vector-effects text, which
should probably move into the Coords chapter
Bogdan: no updates on my chapters
AmeliaBR: I took over some issues in the Linking chapter, still
some items on my todo list for that
... I'm testing implementations before we change things
... e.g. questions about links inside links
Tav: I'm making slow but steady progress on Text, getting
things updated for CSS 3
... I'm getting to a point where I could realise use heycam's
finished text layout algorithm
... I've got some baseline stuff to deal with
AmeliaBR: I was in the midst of writing a response to your
email about the Text issues. some I think we need to follow up
with CSS about
... there are two different CSS specs, one that is published
has a limited number of baselines, and there's another draft
that reintroduces all the other SVG keywords
Tav: all of them?
AmeliaBR: all the baselines are introduced but these other
keywords that nobody implemented got dropped
... we need to follow up and coordinate
Tav: the one baseline I thought was dropped that might be
interesting is ideographic
AmeliaBR: that should be there, if it's not in the one spec
it'll be in the other one
... but there were things like a keyword like "use-font" or
something, that got dropped
... I'll need to read the other changes you made, but I know we
need clear descriptions -- for example text on path doesn't
describe how RTL text works
... and is horrible and inconsistent in implementations
currently
Tav: shouldn't be any different from single normal lines of
text
AmeliaBR: shouldn't be, but startOffset=""...
Tav: so I think I'm close to being done with what's in SVG,
then I'll move my focus to the Shapes spec
nikos: Rendering Model is done
... I picked up the animVal change, which I finished off last
week
heycam: would you be willing to pick up the Coords chapter?
nikos: sure
Bogdan: in a Windows 10 update soon, we're adding external
resources for <use>. we identified some issues
... we couldn't find any reference to enforcing CORS
... and implementations are inconsistent
... in Firefox there aren't restrictions about domain
... in Edge it's same domain
... the elements that can be used in external resources are not
clear
... e.g. we don't allow <filter>, but we do allow <pattern>,
<use>
... all implementations don't allow script to run
... also, how many levels deep can you link to resources?
... in Firefox there are no restrictions, Edge/Chrome does have
... finally there's no way to handle errors loading external
resources
... some of these things might be too big for SVG 2, but others
like CORS need to be specified somewhere
... looks like the Linking chapter might be the best place to
put this
<ed> error events should fire according to SVG2 AFAIK, wasn't
explicitly required before
<ed> for the external loads
[12]http://www.w3.org/TR/svg-integration/
[12] http://www.w3.org/TR/svg-integration/
heycam: the Integration spec was the place we intended to put
things
Bogdan: that spec looks like a good place to put this, yes
... second question is whether inline <svg> is a replaced
element
... the good news is that Edge matches Firefox and Chrome,
mostly
... at the time it was implemented, in IE9 I think, all
browsers did something different
... but I think we arrived to a model that is pretty easy to
specify, an algorithm, how intrinsic sizing / ratio / viewport
in SVG integrates with CSS, etc.
... that does sound like something that does work correctly in
implemetnations but needs to be specified
... for a newer implementer it would be good to specify this
AmeliaBR: I would definitely +1 for getting that written down
... as you say, we've moved to a defacto standard with browsers
matching each other but it's not written down anywhere
... and it drives authors nuts they can't rely on existing
behaviour
Bogdan: we developed a massive number of tests, close to 500
with min-width, max-width, viewBox or not, etc.
AmeliaBR: there's a section in the SVG spec that describes how
SVG has an intrinsic size and/or aspect ratio
... but then it's connecting that up with the CSS and HTML
concept of a default size for replaced elements
Bogdan: there was a discussion this year about default replaced
element sizes. but this issue here is wider than that -- how
you calculate size given any amount of data, which includes
100s of different combinations of max-width, etc.
... I'm not sure where in the spec that would fall
... from an implementation perspective it's a very common use
case
... putting it in Integration might let it move faster
<AmeliaBR> Current text on intrinsic sizing:
[13]https://svgwg.org/svg2-draft/coords.html#IntrinsicSizing
[13] https://svgwg.org/svg2-draft/coords.html#IntrinsicSizing
<scribe> ACTION: Bogdan to write up text about sizing, either
in SVG 2 or Integration [recorded in
[14]http://www.w3.org/2015/11/05-svg-minutes.html#action02]
<trackbot> Created ACTION-3828 - Write up text about sizing,
either in svg 2 or integration [on Bogdan Brinza - due
2015-11-12].
<AmeliaBR>
[15]https://svgwg.org/svg2-draft/coords.html#IntrinsicSizing
[15] https://svgwg.org/svg2-draft/coords.html#IntrinsicSizing
AmeliaBR: looks like that section hasn't changed much from 1.1,
apart from adding issues
... if you wanted to flesh that out it might be a good starting
point
trackbot: end telcon
Summary of Action Items
[NEW] ACTION: Amelia to draft text related to viewTarget and
some examples [recorded in
[16]http://www.w3.org/2015/11/05-svg-minutes.html#action01]
[NEW] ACTION: Bogdan to write up text about sizing, either in
SVG 2 or Integration [recorded in
[17]http://www.w3.org/2015/11/05-svg-minutes.html#action02]
[End of minutes]
Received on Thursday, 5 November 2015 21:44:04 UTC