SVG Working Group Teleconference -- 27 Feb 2014

<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 from

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

<ed> 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 http://www.w3.org/2014/02/27-svg-minutes.html#action01]

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

<trackbot> 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

<krit> http://www.w3.org/TR/matrix/#widl-DOMMatrix-rotateFromVector-DOMMatrix-unrestricted-double-x-unrestricted-double-y

<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 http://www.w3.org/2014/02/27-svg-minutes.html#action02]

<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 currently?

ThomasSmailus: text height, as an analog to the textWIdth="" attribute
... 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: https://www.w3.org/Graphics/SVG/WG/wiki/images/d/d8/Features_needed_in_SVG2_for_Technical_Diagrams.pdf)

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 important

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

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 element

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

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

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

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 behaviour

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 content?

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 content

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 canvas
... also, in HTML, the fallback content goes into the tab order

<ed> 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 there

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 case
... I feel this is independent of this issue
... as <html> would just be another element we'd support everywhere

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 http://www.w3.org/2014/02/27-svg-minutes.html#action03]

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

- DRAFT -

SVG Working Group Teleconference

27 Feb 2014

Attendees

Contents

Another update on Leipzig meeting venue

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

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

Canvas element: should fallback content be name spaced for HTML content?

CSS Masking review request

Summary of Action Items

Scribe.perl diagnostic output