See also: IRC log
<scribe> ScribeNick: krit
<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
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
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
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]