See also: IRC log
<scribe> ScribeNick: krit
[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.....
shepazu: you are not scribing krit!
ed_tpac: isolation used in SVG image
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?
krit: but it can be changed?
cabanier: yes, it can be changed
Rossen_: do you have a test case?
dino: I think we should isolate images
cabanier: it would be terrible if iframe isolate
Rossen_: from your perspective, you can think of iframe to be isolated
shepazu: from the rendering tree
... 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
... 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
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
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
... 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]
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
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?
jcraig: I think it does
... but is still based on SVG 1
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
... 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
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
... 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
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
... 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
... 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.
richardschwerdtfeger: this would be non-normative?
shepazu: we could normatively
... 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
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
... 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]