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

minutes, 27 February 2014 SVG WG telcon

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 28 Feb 2014 08:30:03 +1100
Message-ID: <530FAE5B.4080202@mcc.id.au>
To: "www-svg@w3.org" <www-svg@w3.org>
Minutes from this week's telcon are below.



       [1] http://www.w3.org/

                                - DRAFT -

                     SVG Working Group Teleconference

27 Feb 2014


       [2] http://lists.w3.org/Archives/Public/www-svg/2014Feb/0091.html

    See also: [3]IRC log

       [3] http://www.w3.org/2014/02/27-svg-irc


           Thomas_Smailus, krit, [IPcaller], ed, stakagi, birtles,
           heycam, Tav, nikos, Doug_Schepers, Rich_Schwerdtfeger,




      * [4]Topics
          1. [5]Another update on Leipzig meeting venue
          2. [6]Why does SVGMatrix.rotateFromVector(x, y) throw on
             y=0? (ISSUE-2457)
          3. [7]Review of feature needs & use cases for
             technical/engineering diagrams using SVG
          4. [8]Canvas element: should fallback content be name
             spaced for HTML content?
          5. [9]CSS Masking review request
      * [10]Summary of Action Items

    <trackbot> Date: 27 February 2014

    <scribe> Scribe: Cameron

    <scribe> ScribeNick: heycam

Another update on Leipzig meeting venue

    krit: I checked two different venues in Leipzig

    birtles: takagai-san also found one venue

    krit: there are different possibilities

    birtles: KDDI have offered to help with the cost of hosting for
    the meeting room

    krit: there are different meeting rooms that we/KDDI can choose

    birtles: some people have already travel assuming those dates
    we originally decided on

    krit: 10th or 9th?

    heycam: Monday-Thursday, whatever those dates were

    birtles: he would like to keep those dates

    heycam: I think it's fine to leave those dates

    ed: do we have a name of the venue that KDDI found?

    krit: I will pass on my finds to takagi-san, and will update
    the wiki page when we've decided


      [11] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Leipzig_2014

    heycam: I can bring teleconference equipment

    <scribe> ACTION: Cameron to set up Leipzig meeting
    questionairre [recorded in

    <trackbot> Created ACTION-3596 - Set up leipzig meeting
    questionairre [on Cameron McCormack - due 2014-03-06].

Why does SVGMatrix.rotateFromVector(x, y) throw on y=0? (ISSUE-2457)

    ed: I was reading through the matrix things and found this one,
    which is defined in SVG differently from how it's defined in
    the new DOMMatrix spec
    ... was wondering if this was something we might change in our
    spec, or if we should just reference DOMMatrix from SVG 2

    krit: the idea is that we replace SVGMatrix with DOMMatrix
    ... which of course depends on how fast we can progress
    ... there is some pushback form other orgs
    ... we can update the SVGMatrix for now, to use the definition
    we have in DOMMatrix
    ... the reason why SVGMatrix has the issue is that it is a
    division by zero for certain rotations
    ... I think we should just change it

    ed: the y parameter you don't really need to divide by 0

    <ed> ISSUE-2457?

    <trackbot> ISSUE-2457 -- Why does
    svgmatrix.rotatefromvector(x,y) throw on y=0? -- raised


      [13] http://www.w3.org/Graphics/SVG/WG/track/issues/2457

    heycam: what do we do for (0, 0)?

    krit: DOMMatrix says the matrix is unmodified
    ... we treat that as angle 0



    <ed> the issue link has links to the various spec defintions
    (and atan)

    heycam: I think it's fine to just update SVG 2 with this change
    and wait to reference DOMMatrix once it's more stable/accepted

    <scribe> ACTION: Erik to define SVGMatrix.rotateFromVector(0,0)
    in SVG 2 not to throw [recorded in

    <trackbot> Created ACTION-3597 - Define
    svgmatrix.rotatefromvector(0,0) in svg 2 not to throw [on Erik
    Dahlström - due 2014-03-06].

Review of feature needs & use cases for technical/engineering
diagrams using SVG

    ThomasSmailus: I've broken out some things I talked about at
    the F2F
    ... still working with some of the graphics engineers here at
    Boeing for some more precise examples
    ... closer to be able to nail down a concrete explanation of
    the features
    ... what I wanted to get from the group was some guidance on
    the right process to propose the additions to the spec to make
    this happen
    ... also objections/issues with the use cases, would be glad to
    hear those

    heycam: can you summarise the features which aren't supported

    ThomasSmailus: text height, as an analog to the textWIdth=""
    ... this isn't as critical, but it's a nice to have, where more
    precise control of text height would be important
    ... next is non-scaling line widths, dash/line patterns, and
    hatch patterns
    ... where the displayed pattern/stroke appears the same at any
    zoom level
    ... finally the engineering line types/definitions

    <ed> (for reference, this is the document discussed:


    ThomasSmailus: talking with folks here, some of the line types
    they can be done with stroke-dasharray
    ... some you can't, since they have some unique characteristics
    ... coming up with an enhanced way to define line styles than
    implementing an enumerated set of line styles

    heycam: I agree with having a general mechanism

    Tav: variable stroke width would work for the curved and
    zig-zag lines

    heycam: yes if we allow the "both sides of the stroke go to one
    side of the stroke middle"

    ThomasSmailus: if the various line styles are not defined in a
    consistent way it makes it difficult to import/export

    ed: do you have any insight into which of these new things
    would be more important? a priority list?

    ThomasSmailus: I'm still working on that
    ... I'm trying to get some concrete examples from within
    Boeing, and to get a feel of which of these are truly important
    ... and which happen rarely
    ... I suspect the patterns and line styles would be most

    ed: as long as there's some information coming on that, that's

    krit: for most of these things it's important to have uniform
    scaling, horiz/vert axis scaling the same
    ... how do we define if that's not the case?
    ... or if you have skew?

    heycam: I think that's an open question for the non-scaling
    stroke that we already have

    ThomasSmailus: my gut feeling is that for hatch pattern they'd
    also be non-rotating
    ... there's a legend those goes with them, and that pattern
    should match even after rotation

    krit: ok, so no transformation at all

    Tav: you can already do that with patterns can't you?

    krit: not really, they're in the coordinate space of the

    heycam: you can't say userSpaceOnUse and choose the root coord

    ed: not without ref() transforms or something like that

    Tav: so we'd add a third option? to use the root coordinate

    krit: should we go extreme and allow the user to select the
    user coordinate system?

    heycam: that's one thing I didn't like about ref(svg) from SVG
    Tiny 1.2, would rather allow selecting the target coord system

    ThomasSmailus: any opposition to any of these proposals?

    Tav: the only one I might question is the text, might be hard
    to do
    ... the other ones I think we should do

    krit: what's the problem with text?

    Tav: the text height
    ... the boxed-cap, boxed-all ...

    krit: why is that difficult?

    ed: doesn't canvas already have that?

    heycam: don't think so?
    ... I don't think that feature should be too hard

    krit: do you feel these should be implemented in the browser?
    ... there might be viewers which implement certain features,
    and browsers that implement a different set of features

    ThomasSmailus: our vision is that all viewers/browsers would
    implement the features
    ... if some don't implement, it's not a feature we want to
    use/rely on

    krit: we need to specify what happens when you have a
    non-uniform scale
    ... it's not an issue for you, since you're always doing a
    uniform scaling with your schematics

    ThomasSmailus: not hearing any opposition, so I'll proceed to
    gather more precise examples, and prioritise them

    <shepazu> q+

    ThomasSmailus: then based on that come up with some proposed

    Tav: would you have resources to add these to a browser?

    ThomasSmailus: no :)

    shepazu: I don't want there to be features in SVG that aren't
    in the browser
    ... I think we're all on board with there being one SVG

    heycam: yes

    krit: yeah

Canvas element: should fallback content be name spaced for HTML

    IOW, what happens with <canvas><p> ... </p></canvas>

    richardschwerdtfeger: in HTML we assume fallback content is
    HTML, of course, and what we're doing is using that to populate
    the accessibility APIs that corresponds to content that is
    drawn on canvas
    ... what do we want to do for fallback content under SVG's
    <canvas>, and how do we support HTML in there?
    ... namespaced in the fallback content?
    ... I don't think it's quite addressed

    shepazu: I'd like to understand more about fallback canvas

    richardschwerdtfeger: the fallback content is used to populate
    the accessibility tree, and there's a one-to-one matching
    between fallback content and the significant objects in the
    ... also, in HTML, the fallback content goes into the tab order


      [17] https://svgwg.org/svg2-draft/embedded.html#CanvasElement

    richardschwerdtfeger: so the question I have is, what do we
    want to do with SVG on this?
    ... if we're using <canvas> to render something, we have to
    make it accessible, can we put HTML in the fallback content?
    ... saw this when I was going through the "intrinsic host
    language semantics for SVG elements in ARIA"

    heycam: do we require <foreignObject> child of <canvas> to put
    HTML in there?

    krit: sounds like <canvas> is a bit like <div>, given you can
    tab right into it
    ... we could make <canvas> a grouping element, so similar

    heycam: those children aren't going to be rendered though

    krit: which would allow <foreignObject> as well

    richardschwerdtfeger: so <canvas><foreignObject><p> ... ?

    krit: either that or SVG children directly

    heycam: I think that would be the most logical thing given how
    we allow HTML in SVG content currently
    ... so Dirk if you make it a "grouping element" in terms of the
    content model allowed in <canvas>, that makes sense

    shepazu: at one point we were discussing allowing an <html>
    element, rather than <foreignObject>
    ... what's the fallback for canvas in HTML?
    ... if we have canvas in SVG, we don't want to have one set of
    best practices for making accessible fallback in HTML and one
    in SVG
    ... should be the same
    ... if you have a <canvas> element in HTML, there's going to be
    a set of guides on how to make fallback content for that
    ... and typically it would be HTML fallback content
    ... I would expect they'll have a richer toolkit in HTML than
    in SVG

    krit: we wouldn't disallow it, but we could still do various
    fallback things in SVG -- tabindex, aria, etc.
    ... but you could also choose to use HTML with <foreignObject>

    shepazu: there are going to be authoring tools that help you
    make accessible content for canvas
    ... I seriously doubt those tools will also do SVG equivalents
    ... so while I don't think SVG has the full range of
    characteristics -- you can't reproduce all of HTML in SVG just
    using aria

    krit: we just add one more step, you have to use
    <foreignObject>, then all the HTML content would be allowed in

    shepazu: if we're importing these things one piece at a time, I
    think we should answer the question soon, what are we doing
    about HTML
    ... and foreignObject is not a good solution
    ... it's an ugly element, and it doesn't allow you to simply
    use HTML in there, you have to use namespaces, etc.
    ... I think to address Rich's question, which is how we handle
    accessibility fallback in canvas in SVG, we should answer the
    question of how to handle HTML in SVG in general
    ... so why not have <html> instead of <foreignObject>

    krit: given you still need to add one more element, does it
    make it easier for the authoring tool?
    ... I am sympathetic to the <html> element
    ... but I think it makes no difference for this accessibility
    ... I feel this is independent of this issue
    ... as <html> would just be another element we'd support

    shepazu: so we don't want to do anything special here

    krit: yes

    shepazu: I think addressing how we handle HTML in SVG means we
    don't have to go into a special solution for <canvas>
    ... foreignObject is harder to use, that's my point
    ... let's not keep avoiding the issue of HTML in SVG
    ... then issues like this won't come up

    krit: so should we agree to allow the SVG content model within
    <canvas>? and in the future if we add <html> it would be
    allowed in there?

    shepazu: yes

    <richardschwerdtfeger> yes

    RESOLUTION: We will allow the standard container element
    content model within SVG <canvas>.

    Tav: what happens if you put a <rect> inside a <canvas>?

    heycam: it wouldn't be rendered

    cabanier: unless the canvas rendering is turned on

    shepazu: so there are somethings you can do in SVG you can't do
    in canvas. elements that are clickable. they're in the DOM.
    ... a canvas element in SVG might have some interesting
    possibility for combining SVG/HTML stuff to make the canvas
    more accessible
    ... I could imagine making a rect/circle for hit testing
    ... and they're rendering that thing in canvas, but the hit
    testing is done in the fallback content
    ... I think we should think more about that

    cabanier: I think that is already supported

    richardschwerdtfeger: there are hit regions in canvas, what
    happens if you're trying to use both that and the fallback
    content providing the hit regions
    ... in HTML they're DOM elements, but if they have a location,
    then there are spatial things to be concerned about as well

    shepazu: I think there are interesting possibilities here

    <scribe> ACTION: Cameron to change the content model of
    <canvas> in SVG to allow the same child elements as <g>.
    [recorded in

    <trackbot> Created ACTION-3598 - Change the content model of
    <canvas> in svg to allow the same child elements as <g>. [on
    Cameron McCormack - due 2014-03-06].

CSS Masking review request

    krit: CSS Masking is back in WD again
    ... it has already been for 2 weeks, and would like to ask for
    a new LCWD soon
    ... but would like as much review before that as possible

    <krit> [19]http://www.w3.org/TR/css-masking-1/

      [19] http://www.w3.org/TR/css-masking-1/

    krit: if anyone who has time, please look over the current WD

    ed: is there a date for comments?

    krit: a lot of things changed
    ... end of next week, but willing to delay if there are
    requests for longer view period

    trackbot, end telcon

Summary of Action Items

    [NEW] ACTION: Cameron to change the content model of <canvas>
    in SVG to allow the same child elements as <g>. [recorded in
    [NEW] ACTION: Cameron to set up Leipzig meeting questionairre
    [recorded in
    [NEW] ACTION: Erik to define SVGMatrix.rotateFromVector(0,0) in
    SVG 2 not to throw [recorded in

    [End of minutes]
Received on Thursday, 27 February 2014 21:30:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:55 UTC