- From: Erik Dahlstrom <ed@opera.com>
- Date: Thu, 30 Oct 2014 17:11:08 -0700
- To: "www-svg@w3.org" <www-svg@w3.org>
Minutes:
http://www.w3.org/2014/10/30-svg-minutes.html
as text:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
TPAC 2014 day 1
30 Oct 2014
[2]Agenda
[2] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2014/Agenda
See also: [3]IRC log
[3] http://www.w3.org/2014/10/30-svg-irc
Attendees
Present
Doug_Shephards, nikos, Tav, stakagi, smailus, ed,
birtles, BogdanBrinza, krit, dino, cabanier, fujisawa,
Cyril, Rossen_
Regrets
Chair
ed
Scribe
krit
Contents
* [4]Topics
1. [5]review agenda
2. [6]blending issue
3. [7]Task Force for accessibility
* [8]Summary of Action Items
__________________________________________________________
<scribe> ScribeNick: krit
review agenda
<ed_tpac>
[9]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2014/Agenda
[9] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2014/Agenda
[discussion about the general agenda schedule]
TabAtkins: we should discuss text stuf
dino: we should have a quick overview over charta and general
agenda and status of SVG
krit: Rossen_: agree
<smailus> Agenda is being updated from the Agenda Proposal
page.... everyone is standing by with bated breath.....
[10]https://wiki.csswg.org/planning/tpac-2014
[10] https://wiki.csswg.org/planning/tpac-2014
shepazu: you are not scribing krit!
[11]https://twitter.com/w3cmemes/status/527621337481609216
[11] https://twitter.com/w3cmemes/status/527621337481609216
blending issue
ed_tpac: isolation used in SVG image
<cabanier> [12]http://www.w3.org/TR/compositing-1/
[12] http://www.w3.org/TR/compositing-1/
cabanier: how mix-blend-mode is handled when you link an SVG
image with <img>
... we have two implementations that do not follow the rule
... we assumed that it was hard to implement
... it seems we can fix the issue from spec
krit: the content of the SVG can blend with the HTML content?
Tav: what is the default behavior?
cabanier: right now it is defined that a blend mode on one
element ni the SVG element should not blend with anything from
HTML
... right now the spec special cases the <img> element
krit: why does it need to?
... I think we do not want the content that has blending
specified with the HTML content
... I would agree with the behavior if you have inline SVG
nikos: you can not control the behavior from the outside
anymore
cabanier: you could still have isolation behavior with the
isolation property on <img>
krit: I think this is unexpected behavior
<TabAtkins> krit: be there in a second
krit: what if UAs ever want to optimize by making a bitmap of
the SVG element and then they don’t blend elements anymore?
cabanier: why would they? They don’t at the moment?
krit: but they might want in the future
nikos: I think the behavior that cabanier wants is expected
Tav: I disagree… I think an <img> is isolated.
krit: you can use inline svg or even <object> if you don’t want
it to be isolated. <img> can reference resource cross domain
cabanier: why does that matter?
krit: WebAppSec asked us to not let cross-domain stuff affect
the current browser context. So maybe we should ask them first?
cabanier: I am not sure why you bring up cross domain now. We
have that with iframe already
krit: do we?
cabanier: yes, this is the case in browsers that they do blend
conent with HTML context
... right now the spec says only stacking context isolates
Tav: which browser doesn’t do that?
cabanier: firefox
krit: but it can be changed?
cabanier: yes, it can be changed
Rossen_: do you have a test case?
cabanier: yes
<cabanier>
[13]https://github.com/w3c/csswg-test/blob/master/compositing-1
/svg/mix-blend-mode-in-svg-image.html
[13]
https://github.com/w3c/csswg-test/blob/master/compositing-1/svg/mix-blend-mode-in-svg-image.html
dino: I think we should isolate images
cabanier: it would be terrible if iframe isolate
krit: why?
Rossen_: from your perspective, you can think of iframe to be
isolated
TabAtkins: agree
shepazu: from the rendering tree perspective
... I have a circle with blending in an iframe does it blend
with the HTML content?
cabanier: no if iframe is a stacking context as TabAtkins
discribes
dino: I want the image element behave similar
... I do not want content of the SVG image blend with the HTML
content
TabAtkins: I agree
birtles: I disagree that an iframe is always opaque as
mentioned before
... it is not in iFrame in Firefox
[birtles demonstrates]
TabAtkins: oh, you are right, it does not need to be opaque
... something that references external things (speaking for
iframe, object or embed) creates a stacking context
dino: browsers should change and we can remove the at risk part
cabanier: ok
ed_tpac: do we need and action?
RESOLUTION: <img> should isolate and we remove the at-risk item
of the spec
Task Force for accessibility
richardschwerdtfegerardschwerdtfeger: We need to do a number of
things
... we need to agree on the charta
... techsumity
... we would like to be able to use graphics on a level they
never have before
... we need a greeter level of specificity
... based on a core API mapping mechnism
... which we will share with HTML and SVG and was initially
done with ARIA and
... CSS now
... first thing is to add experts in this area
shepazu: we don’t know if it will be a normative document or
not
richardschwerdtfegerardschwerdtfeger: probably not
shepazu: the benefit for a normative doc is a way to validate a
document
katie: don’t think we want that initially
richardschwerdtfegerardschwerdtfeger: the URL to the document
changed
janna: I want to do an overview of the strategic direction and
we will do talk with HTML as well
jcraig: I’ll do a small overview
[jcraig persenting an embedded video]
<MichaelC> [14]SVG2 Accessibility API Mappings Editors´Draft
[14] https://rawgit.com/w3c/aria/master/svg-aam/svg-aam.html
jcraig: accesiblliy mapping for screen readers to svg
... lot of the data is in chat and map format
... the data should be aware of the needs
<MichaelC> [15]Core Accessibility API Mappings 1.1 Editors´
Draft
[15] https://rawgit.com/w3c/aria/master/core-aam/core-aam.html
james: there are a lot of possibilities
<dino> that demo was
[16]https://www.webkit.org/blog/3302/aria_and_accessibility_ins
pector/
[16]
https://www.webkit.org/blog/3302/aria_and_accessibility_inspector/
james: currently it is just in WebKit but others will follow
krit: the demo had ARIA and tabindex?
<MichaelC> [17]Accessible Name and Description: Computation and
API Mappings 1.1 Editors´ Draft
[17] https://rawgit.com/w3c/aria/master/accname-aam/accname-aam.html
jcraig: I think it does
... but is still based on SVG 1
<jcraig>
[18]https://www.webkit.org/blog/3302/aria_and_accessibility_ins
pector/
[18]
https://www.webkit.org/blog/3302/aria_and_accessibility_inspector/
<jcraig>
[19]https://www.webkit.org/blog-files/aria1.0/africa_large.svg
[19] https://www.webkit.org/blog-files/aria1.0/africa_large.svg
richardschwerdtfegerardschwerdtfeger: we have 4 for the API
mapping in the document, how things change, how events get
fired and so on
... when we go over to SVG we have things that are activated
when we go over the element
... we do not have accessible elements to make browsers
performant
... in HTML and SVG spec we will use that
... with differences like title and desc in sVG
... we have to look at this more with CSS later the week
... I and one from PF will co-chair the TF
... shepazu talked about connectors
... is that something SVG will do or should we do?
shepazu: it needs review
jcraig: it is great that we have tabindex
... connectors is another aspect
... we can describer a path context from one element to another
... so we can have display adaption
... like a bezier curve that stays connected while moving an
element around
<Tav> [20]http://tavmjong.free.fr/SVG/CONNECTORS/index.xhtml
[20] http://tavmjong.free.fr/SVG/CONNECTORS/index.xhtml
shepazu: Tav and I do that in the next months
Tav: I have a proposal as well.
krit: the HTML WG wanted to remove priorities for tabindex, is
that a problem?
fesch: we want to have different orders of exporing
... we should not use tabindex but alternatives like key
listeners
<shepazu> navigation:
[21]http://www.w3.org/TR/SVGTiny12/interact.html#navigation
[21] http://www.w3.org/TR/SVGTiny12/interact.html#navigation
<shepazu> focus:
[22]http://www.w3.org/TR/SVGTiny12/interact.html#focus
[22] http://www.w3.org/TR/SVGTiny12/interact.html#focus
shepazu: In SVGT we had a focusable attribute to make an
element focusable
ed_tpac: : anchors and elements that have keyboard listeners
shepazu: in SVG we have 1) focusable elements and 2)
navigtations
... nav has compass directions (up, right, top, down)
... I belive we had the notion of a navigation order between
elements
... nav-previous and nag-next like a flow
... I think connectors are more interesting here to connect
elements
richardschwerdtfegerardschwerdtfeger: you want users to give a
choice where to go next
shepazu: right, nav* are attributes
... with the REC you can just name the next element or previous
but no semantics or descrition
... connectors could have it
... lets explore using connectors for that first
... I think there are cases where the keyboard does not let you
navigate correctly
[shepazy gives an example]
??: there are cases where you need dir and nag and others
??: there is no linear connection
janna: not everything is a peer
??: I can show you a dem
shepazu: the focusable attribute… we wanted to do what HTML
did, that is why we used tabindex, but focusable is intuitive.
... and is interesting for annotations with an SVG drawn
musical note
... or diagrams of building where you select particular rooms
... so focusabel and connectors seem to be aligned
... we do not have a selection model for SVG unlike HTML
... and we should have a selection model
richardschwerdtfegerardschwerdtfeger: what is the time frame
for SVG
2
shepazu: we should have a more aggressive time frame
richardschwerdtfegerardschwerdtfeger: it might take us a bit
longer
... we get tabindex is good for some SVG content
... but more complex examples need more
jamesn0000: there are different kind of connectors, like
grouping connectors and so on
... you get siblings, traditional connectors and a bunch of
other
shepazu: yes, In my model there are super graphs with
hierarchies
jamesn0000: yes, that is kind of how we do it
shepazu: some things should be moveable in any order you want
and somethings just need special connectors
... I think this all stuff we can talk about in the context of
connectors.
krit: this is something that we need to discuss more and in
more detail in the future
shepazu: maybe implementations don’t want to implement
connectors so this is all high level at the moment
richardschwerdtfeger: I want to know who is interested in
joining
fetsch: what is the scope? Does it include color aspects or
just blind users?
shepazu: what does distinguish mean for you?
Cims: for and background color / contrast is important but
doesn’t require anything in the spec but the authors
<TabLES_AS_LAYOUTkins> (Btw, cool contrast-ratio app:
[23]https://leaverou.github.io/contrast-ratio/)
[23] https://leaverou.github.io/contrast-ratio/)
shepazu: we should talk about authoring guidelines
... we bring that to you (PF)
... and we won’t revisit in the SVG WG
cims: SVG just doesn’t have the technique to support it
... like alternative for colors and so on and we should figure
out what really is needed technically in SVG
... the mechanisms shouldn’t be different but the actual usages
can be different
shepazu: we want to have a spec that gives accessibility to SVG
but we should have it as an external document.
krit: agre
e
richardschwerdtfeger: this would be non-normative?
shepazu: we could normatively require it
... lets talk about that more
... I think we need focus, selectability, navigation stuff
krit how would selectability look like in SVG?
shepazu: I can’t right now, but SVG 1.1 has at least text
selection
fesch: I want to present some navigation charts to show what we
do at IBM and where we want to go with SVG
janna: I think we should take a minute to disucss what we want
to say the HTML WG
richardschwerdtfeger: Some semantics is done in script, HTML
and CSS
... they can give semantics
fesch: also for Canvas?
richardschwerdtfeger: that would be fine to have
... I think there is a lot of overlap with what the SVG and
HTML WG want to do
... we want to provide some kind of role and what ever gets
into HTML should go to SVG as well
krit as long as it goes to Element object, then it is in SVG as
well
<ed_tpac> role reflection, getComputedRole and getComputedLabel
richardschwerdtfeger: We are almost at the point where title
element and so on is getting rather difficult.
... for tools it would be great to have labels on elements
beside <title>
... a lot of the things we do for HTML, SVG, CSS we want to
unify
<ed> we're in #fx for the fxtf
Summary of Action Items
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [24]scribe.perl version
1.138 ([25]CVS log)
$Date: 2014-10-30 23:25:12 $
__________________________________________________________
[24] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[25] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11
Check for newer version at [26]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/
[26] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/beaver/behavior/
Succeeded: s/jamesr/jcraig/g
Succeeded: s/jamesc/jcraig/g
Succeeded: s/HMTL/HTML/g
Succeeded: s/TabAtkins/Tav/
Succeeded: s/??/fesch/
Succeeded: s/??/fesch/
Succeeded: s/ancors/anchors/
Succeeded: s/ntoe/drawn musical note/
Succeeded: s/??/Cims/
Succeeded: s/rich/richardschwerdtfeger/g
Found ScribeNick: krit
Inferring Scribes: krit
Present: Doug_Shephards nikos Tav stakagi smailus ed birtles BogdanBrinz
a krit dino cabanier fujisawa Cyril Rossen_
Agenda: [27]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2014/Agenda
_proposals#SVG_topics
Got date from IRC log name: 30 Oct 2014
Guessing minutes URL: [28]http://www.w3.org/2014/10/30-svg-minutes.html
People with action items:
[27]
https://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2014/Agenda_proposals#SVG_topics
[28] http://www.w3.org/2014/10/30-svg-minutes.html
WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.
[End of [29]scribe.perl diagnostic output]
[29] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
--
Erik Dahlstrom, Web Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Received on Friday, 31 October 2014 00:11:39 UTC