W3C home > Mailing lists > Public > public-svg-wg@w3.org > October to December 2014

Minutes SVG @ TPAC 2014 Day 1

From: Erik Dahlstrom <ed@opera.com>
Date: Thu, 30 Oct 2014 17:11:08 -0700
To: "www-svg@w3.org" <www-svg@w3.org>
Message-ID: <op.xokisuzrgeuyw5@meh>
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:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:20 UTC