W3C

- DRAFT -

TPAC 2014 day 1

30 Oct 2014

Agenda

See also: IRC log

Attendees

Present
Doug_Shephards, nikos, Tav, stakagi, smailus, ed, birtles, BogdanBrinza, krit, dino, cabanier, fujisawa, Cyril, Rossen_
Regrets
Chair
ed
Scribe
krit

Contents


<scribe> ScribeNick: krit

review agenda

<ed_tpac> 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.....

https://wiki.csswg.org/planning/tpac-2014

shepazu: you are not scribing krit!

https://twitter.com/w3cmemes/status/527621337481609216

blending issue

ed_tpac: isolation used in SVG image

<cabanier> 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> 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> SVG2 Accessibility API Mappings Editors´Draft

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> Core Accessibility API Mappings 1.1 Editors´ Draft

james: there are a lot of possibilities

<dino> that demo was 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> Accessible Name and Description: Computation and API Mappings 1.1 Editors´ Draft

jcraig: I think it does
... but is still based on SVG 1

<jcraig> https://www.webkit.org/blog/3302/aria_and_accessibility_inspector/

<jcraig> 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> 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: http://www.w3.org/TR/SVGTiny12/interact.html#navigation

<shepazu> focus: 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: 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 scribe.perl version 1.138 (CVS log)
$Date: 2014-10-30 23:25:12 $

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 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 BogdanBrinza krit dino cabanier fujisawa Cyril Rossen_
Agenda: 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: http://www.w3.org/2014/10/30-svg-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


[End of scribe.perl diagnostic output]