See also: IRC log
<trackbot> Date: 05 November 2015
FYI, the meeting access code has changed
644 384 016
<shepazu> https://mit.webex.com/mit/j.php?MTID=mfbd328afdc7c85003ed6c87919f43c67
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
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 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].
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
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: 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 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> 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
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: Cameron Found ScribeNick: heycam Default Present: ed, heycam, Tav, stakagi, BogdanBrinza, AmeliaBR, nikos Present: ed heycam Tav stakagi BogdanBrinza AmeliaBR nikos Agenda: https://lists.w3.org/Archives/Public/www-svg/2015Nov/0011.html Found Date: 05 Nov 2015 Guessing minutes URL: http://www.w3.org/2015/11/05-svg-minutes.html People with action items: amelia bogdan[End of scribe.perl diagnostic output]