20:29:16 <RRSAgent> RRSAgent has joined #svg
20:29:16 <RRSAgent> logging to http://www.w3.org/2014/02/27-svg-irc
20:29:18 <trackbot> RRSAgent, make logs public
20:29:18 <Zakim> Zakim has joined #svg
20:29:20 <trackbot> Zakim, this will be GA_SVGWG
20:29:20 <Zakim> ok, trackbot, I see GA_SVGWG(SVG1)3:30PM already started
20:29:21 <trackbot> Meeting: SVG Working Group Teleconference
20:29:22 <trackbot> Date: 27 February 2014
20:29:54 <Zakim> +[IPcaller]
20:29:57 <birtles> birtles has joined #svg
20:30:04 <ed> Zakim, [IP is me
20:30:04 <Zakim> +ed; got it
20:30:33 <Zakim> +??P6
20:30:34 <ed> Agenda: http://lists.w3.org/Archives/Public/www-svg/2014Feb/0091.html
20:30:36 <krit> zakim, who is on the call?
20:30:36 <Zakim> On the phone I see Thomas_Smailus, krit, ed, ??P6
20:30:43 <ed> chair: ed
20:30:45 <Zakim> +[IPcaller]
20:30:54 <stakagi> Zakim, ??P6 is me
20:30:54 <Zakim> +stakagi; got it
20:30:57 <birtles> Zakim, [ is me
20:30:57 <Zakim> +birtles; got it
20:31:04 <Zakim> +[IPcaller]
20:31:05 <heycam> Zakim, [ is me
20:31:05 <Zakim> +heycam; got it
20:31:50 <ed> Zakim, pick a scribe
20:31:50 <Zakim> Not knowing who is chairing or who scribed recently, I propose stakagi
20:32:37 <heycam> Scribe: Cameron
20:32:40 <heycam> ScribeNick: heycam
20:32:53 <heycam> Topic: Another update on Leipzig meeting venue
20:33:18 <heycam> krit: I checked two different venues in Leipzig
20:33:23 <heycam> birtles: takagai-san also found one venue
20:33:29 <heycam> krit: there are different possibilities
20:33:40 <nikos> nikos has joined #svg
20:33:50 <heycam> birtles: KDDI have offered to help with the cost of hosting for the meeting room
20:33:54 <Zakim> +Tav
20:34:08 <heycam> krit: there are different meeting rooms that we/KDDI can choose from
20:34:50 <heycam> birtles: some people have already travel assuming those dates we originally decided on
20:35:06 <heycam> krit: 10th or 9th?
20:35:12 <heycam> heycam: Monday-Thursday, whatever those dates were
20:35:31 <Zakim> +??P10
20:35:38 <nikos> Zakim, ?P10 is me
20:35:38 <Zakim> sorry, nikos, I do not recognize a party named '?P10'
20:35:41 <heycam> birtles: he would like to keep those dates
20:35:43 <nikos> Zakim, ??P10 is me
20:35:43 <Zakim> +nikos; got it
20:35:54 <heycam> heycam: I think it's fine to leave those dates
20:36:02 <heycam> ed: do we have a name of the venue that KDDI found?
20:36:17 <heycam> krit: I will pass on my finds to takagi-san, and will update the wiki page when we've decided
20:37:06 <ed> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Leipzig_2014
20:37:11 <heycam> heycam: I can bring teleconference equipment
20:37:17 <Zakim> +Doug_Schepers
20:37:27 <shepazu> q+
20:38:04 <Zakim> +Rich_Schwerdtfeger
20:38:24 <Zakim> +cabanier
20:38:55 <heycam> ACTION: Cameron to set up Leipzig meeting questionairre
20:38:55 <trackbot> Created ACTION-3596 - Set up leipzig meeting questionairre [on Cameron McCormack - due 2014-03-06].
20:39:22 <heycam> Topic: Why does SVGMatrix.rotateFromVector(x, y) throw on y=0? (ISSUE-2457)
20:39:55 <heycam> 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
20:40:09 <heycam> ... was wondering if this was something we might change in our spec, or if we should just reference DOMMatrix from SVG 2
20:40:15 <heycam> krit: the idea is that we replace SVGMatrix with DOMMatrix
20:40:21 <heycam> ... which of course depends on how fast we can progress DOMMatrix
20:40:32 <heycam> ... there is some pushback form other orgs
20:40:41 <heycam> ... we can update the SVGMatrix for now, to use the definition we have in DOMMatrix
20:41:05 <heycam> ... the reason why SVGMatrix has the issue is that it is a division by zero for certain rotations
20:41:11 <heycam> ... I think we should just change it
20:41:20 <heycam> ed: the y parameter you don't really need to divide by 0
20:41:58 <ed> ISSUE-2457?
20:41:58 <trackbot> ISSUE-2457 -- Why does svgmatrix.rotatefromvector(x,y) throw on y=0? -- raised
20:41:58 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2457
20:42:22 <heycam> heycam: what do we do for (0, 0)?
20:42:27 <heycam> krit: DOMMatrix says the matrix is unmodified
20:42:41 <heycam> ...  we treat that as angle 0
20:42:44 <krit> http://www.w3.org/TR/matrix/#widl-DOMMatrix-rotateFromVector-DOMMatrix-unrestricted-double-x-unrestricted-double-y
20:42:59 <ed> the issue link has links to the various spec defintions (and atan)
20:43:25 <heycam> 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
20:43:48 <heycam> ACTION: Erik to define SVGMatrix.rotateFromVector(0,0) in SVG 2 not to throw
20:43:48 <trackbot> Created ACTION-3597 - Define svgmatrix.rotatefromvector(0,0) in svg 2 not to throw [on Erik Dahlström - due 2014-03-06].
20:44:07 <heycam> Topic: Review of feature needs & use cases for technical/engineering diagrams using SVG
20:44:29 <heycam> ThomasSmailus: I've broken out some things I talked about at the F2F
20:44:38 <heycam> ... still working with some of the graphics engineers here at Boeing for some more precise examples
20:44:46 <heycam> ... closer to be able to nail down a concrete explanation of the features
20:44:59 <heycam> ... 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
20:45:11 <heycam> ... also objections/issues with the use cases, would be glad to hear those
20:45:31 <heycam> heycam: can you summarise the features which aren't supported currently?
20:45:49 <heycam> ThomasSmailus: text height, as an analog to the textWIdth="" attribute
20:46:16 <heycam> ... this isn't as critical, but it's a nice to have, where more precise control of text height would be important
20:46:26 <heycam> ... next is non-scaling line widths, dash/line patterns, and hatch patterns
20:46:41 <heycam> ... where the displayed pattern/stroke appears the same at any zoom level
20:46:46 <heycam> ... finally the engineering line types/definitions
20:46:52 <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)
20:47:02 <heycam> ... talking with folks here, some of the line types they can be done with stroke-dasharray
20:47:09 <heycam> ... some you can't, since they have some unique characteristics
20:47:24 <heycam> ... coming up with an enhanced way to define line styles than implementing an enumerated set of line styles
20:47:47 <heycam> heycam: I agree with having a general mechanism
20:48:28 <heycam> Tav: variable stroke width would work for the curved and zig-zag lines
20:48:39 <heycam> heycam: yes if we allow the "both sides of the stroke go to one side of the stroke middle"
20:49:06 <heycam> ThomasSmailus: if the various line styles are not defined in a consistent way it makes it difficult to import/export
20:50:12 <heycam> ed: do you have any insight into which of these new things would be more important? a priority list?
20:50:15 <heycam> ThomasSmailus: I'm still working on that
20:50:29 <heycam> ... I'm trying to get some concrete examples from within Boeing, and to get a feel of which of these are truly important
20:50:33 <heycam> ... and which happen rarely
20:50:56 <heycam> ... I suspect the patterns and line styles would be most important
20:51:10 <heycam> ed: as long as there's some information coming on that, that's fine
20:51:23 <heycam> krit: for most of these things it's important to have uniform scaling, horiz/vert axis scaling the same
20:51:29 <heycam> ... how do we define if that's not the case?
20:51:35 <heycam> ... or if you have skew?
20:51:57 <heycam> heycam: I think that's an open question for the non-scaling stroke that we already have
20:52:12 <heycam> ThomasSmailus: my gut feeling is that for hatch pattern they'd also be non-rotating
20:52:33 <heycam> ... there's a legend those goes with them, and that pattern should match even after rotation
20:52:37 <heycam> krit: ok, so no transformation at all
20:52:52 <heycam> Tav: you can already do that with patterns can't you?
20:52:58 <heycam> krit: not really, they're in the coordinate space of the element
20:53:24 <heycam> heycam: you can't say userSpaceOnUse and choose the root coord system
20:53:30 <heycam> ed: not without ref() transforms or something like that
20:53:41 <heycam> Tav: so we'd add a third option? to use the root coordinate system?
20:53:51 <heycam> krit: should we go extreme and allow the user to select the user coordinate system?
20:54:26 <heycam> 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
20:54:50 <heycam> ThomasSmailus: any opposition to any of these proposals?
20:54:56 <heycam> Tav: the only one I might question is the text, might be hard to do
20:55:06 <heycam> Tav: the other ones I think we should do
20:55:10 <heycam> krit: what's the problem with text?
20:55:18 <heycam> Tav: the text height
20:55:24 <heycam> ... the boxed-cap, boxed-all ...
20:55:30 <heycam> krit: why is that difficult?
20:55:43 <heycam> ed: doesn't canvas already have that?
20:55:45 <heycam> heycam: don't think so?
20:56:25 <heycam> heycam: I don't think that feature should be too hard
20:56:31 <heycam> ThomasSmailus: do you feel these should be implemented in the browser?
20:56:40 <heycam> s/ThomasSmailus/krit/
20:56:54 <heycam> krit: there might be viewers which implement certain features, and browsers that implement a different set of features
20:57:05 <heycam> ThomasSmailus: our vision is that all viewers/browsers would implement the features
20:57:15 <heycam> ... if some don't implement, it's not a feature we want to use/rely on
20:57:49 <heycam> krit: we need to specify what happens when you have a non-uniform scale
20:57:58 <heycam> ... it's not an issue for you, since you're always doing a uniform scaling with your schematics
20:58:21 <heycam> ThomasSmailus: not hearing any opposition, so I'll proceed to gather more precise examples, and prioritise them
20:58:23 <shepazu> q+
20:58:31 <heycam> ... then based on that come up with some proposed behaviour
20:58:50 <heycam> Tav: would you have resources to add these to a browser?
20:58:51 <heycam> ThomasSmailus: no :)
20:59:41 <heycam> shepazu: I don't want there to be features in SVG that aren't in the browser
20:59:47 <heycam> ... I think we're all on board with there being one SVG
20:59:50 <heycam> heycam: yes
21:00:09 <heycam> krit: yeah
21:00:27 <heycam> Topic: Canvas element: should fallback content be name spaced for HTML content?
21:00:31 <heycam> IOW, what happens with <canvas><p> ... </p></canvas>
21:00:49 <heycam> 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
21:01:03 <heycam> ... what do we want to do for fallback content under SVG's <canvas>, and how do we support HTML in there?
21:01:07 <heycam> ... namespaced in the fallback content?
21:01:10 <heycam> ... I don't think it's quite addressed
21:01:33 <heycam> shepazu: I'd like to understand more about fallback canvas content
21:01:49 <heycam> 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
21:01:58 <heycam> ... also, in HTML, the fallback content goes into the tab order
21:02:00 <ed> https://svgwg.org/svg2-draft/embedded.html#CanvasElement
21:02:04 <heycam> ... so the question I have is, what do we want to do with SVG on this?
21:02:25 <heycam> ... if we're using <canvas> to render something, we have to make it accessible, can we put HTML in the fallback content?
21:02:41 <heycam> ... saw this when I was going through the "intrinsic host language semantics for SVG elements in ARIA"
21:04:09 <heycam> heycam: do we require <foreignObject> child of <canvas> to put HTML in there?
21:04:24 <heycam> krit: sounds like <canvas> is a bit like <div>, given you can tab right into it
21:04:33 <heycam> ... we could make <canvas> a grouping element, so similar
21:04:45 <heycam> heycam: those children aren't going to be rendered though
21:04:52 <heycam> krit: which would allow <foreignObject> as well
21:05:01 <thorton> thorton has joined #svg
21:05:09 <heycam> richardschwerdtfeger: so <canvas><foreignObject><p> ... ?
21:05:27 <heycam> krit: either that or SVG children directly
21:05:57 <heycam> heycam: I think that would be the most logical thing given how we allow HTML in SVG content currently
21:06:36 <heycam> heycam: so Dirk if you make it a "grouping element" in terms of the content model allowed in <canvas>, that makes sense
21:07:36 <heycam> shepazu: at one point we were discussing allowing an <html> element, rather than <foreignObject>
21:08:18 <heycam> ... what's the fallback for canvas in HTML?
21:08:45 <heycam> ... 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
21:08:53 <heycam> ... should be the same
21:09:31 <heycam> ... 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
21:09:38 <heycam> ... and typically it would be HTML fallback content
21:09:56 <heycam> ... I would expect they'll have a richer toolkit in HTML than in SVG
21:10:10 <heycam> krit: we wouldn't disallow it, but we could still do various fallback things in SVG -- tabindex, aria, etc.
21:10:24 <heycam> ... but you could also choose to use HTML with <foreignObject>
21:10:58 <heycam> shepazu: there are going to be authoring tools that help you make accessible content for canvas
21:11:07 <heycam> ... I seriously doubt those tools will also do SVG equivalents
21:11:28 <heycam> ... 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
21:12:23 <heycam> krit: we just add one more step, you have to use <foreignObject>, then all the HTML content would be allowed in there
21:12:39 <heycam> 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
21:12:44 <heycam> ... and foreignObject is not a good solution
21:13:08 <heycam> ... it's an ugly element, and it doesn't allow you to simply use HTML in there, you have to use namespaces, etc.
21:13:31 <heycam> ... 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
21:13:33 <heycam> ed: I agree
21:14:19 <heycam> shepazu: so why not have <html> instead of <foreignObject>
21:14:39 <ed> s/ed: I agree//
21:14:46 <heycam> krit: given you still need to add one more element, does it make it easier for the authoring tool?
21:15:03 <heycam> ... I am sympathetic to the <html> element
21:15:12 <heycam> ... but I think it makes no difference for this accessibility case
21:15:55 <heycam> krit: I feel this is independent of this issue
21:16:06 <heycam> ... as <html> would just be another element we'd support everywhere
21:16:19 <heycam> shepazu: so we don't want to do anything special here
21:16:20 <heycam> krit: yes
21:16:44 <heycam> shepazu: I think addressing how we handle HTML in SVG means we don't have to go into a special solution for <canvas>
21:17:05 <heycam> ... foreignObject is harder to use, that's my point
21:17:15 <heycam> ... let's not keep avoiding the issue of HTML in SVG
21:17:22 <heycam> ... then issues like this won't come up
21:17:50 <heycam> 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?
21:17:52 <heycam> shepazu: yes
21:18:05 <richardschwerdtfeger> yes
21:18:24 <heycam> RESOLUTION: We will allow the standard container element content model within SVG <canvas>.
21:20:13 <heycam> Tav: what happens if you put a <rect> inside a <canvas>?
21:20:47 <heycam> heycam: it wouldn't be rendered
21:21:00 <heycam> cabanier: unless the canvas rendering is turned on
21:22:21 <heycam> 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.
21:22:30 <richardschwerdtfeger> q+
21:22:32 <Zakim> -Tav
21:22:37 <richardschwerdtfeger> q?
21:22:41 <heycam> ... a canvas element in SVG might have some interesting possibility for combining SVG/HTML stuff to make the canvas more accessible
21:22:45 <heycam> ack shepazu
21:22:54 <heycam> ... I could imagine making a rect/circle for hit testing
21:23:09 <heycam> ... and they're rendering that thing in canvas, but the hit testing is done in the fallback content
21:23:12 <Zakim> +Tav
21:23:28 <heycam> ... I think we should think more about that
21:23:36 <heycam> cabanier: I think that is already supported
21:23:37 <ed> ack richardschwerdtfeger
21:23:54 <heycam> 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
21:24:10 <heycam> ... in HTML they're DOM elements, but if they have a location, then there are spatial things to be concerned about as well
21:24:17 <heycam> shepazu: I think there are interesting possibilities here
21:25:34 <heycam> ACTION: Cameron to change the content model of <canvas> in SVG to allow the same child elements as <g>.
21:25:34 <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].
21:26:06 <heycam> Topic: CSS Masking review request
21:26:10 <heycam> krit: CSS Masking is back in WD again
21:26:18 <heycam> ... it has already been for 2 weeks, and would like to ask for a new LCWD soon
21:26:24 <heycam> ... but would like as much review before that as possible
21:26:34 <krit> http://www.w3.org/TR/css-masking-1/
21:26:34 <heycam> ... if anyone who has time, please look over the current WD
21:26:51 <heycam> ed: is there a date for comments?
21:26:56 <heycam> krit: a lot of things changed
21:27:32 <heycam> ... next week, but willing to delay if there are requests for longer view period
21:27:41 <heycam> s/next week/end of next week/
21:28:25 <Zakim> -Thomas_Smailus
21:28:28 <Zakim> -heycam
21:28:29 <Zakim> -cabanier
21:28:31 <Zakim> -stakagi
21:28:31 <Zakim> -birtles
21:28:32 <Zakim> -Tav
21:28:32 <Zakim> -nikos
21:28:33 <Zakim> -Doug_Schepers
21:28:34 <Zakim> -krit
21:28:35 <Zakim> -ed
21:28:36 <Zakim> -Rich_Schwerdtfeger
21:28:36 <Zakim> GA_SVGWG(SVG1)3:30PM has ended
21:28:36 <Zakim> Attendees were Thomas_Smailus, krit, [IPcaller], ed, stakagi, birtles, heycam, Tav, nikos, Doug_Schepers, Rich_Schwerdtfeger, cabanier
21:28:41 <heycam> trackbot, end telcon
21:28:41 <trackbot> Zakim, list attendees
21:28:41 <Zakim> sorry, trackbot, I don't know what conference this is
21:28:49 <trackbot> RRSAgent, please draft minutes
21:28:49 <RRSAgent> I have made the request to generate http://www.w3.org/2014/02/27-svg-minutes.html trackbot
21:28:50 <trackbot> RRSAgent, bye
21:28:50 <RRSAgent> I see 3 open action items saved in http://www.w3.org/2014/02/27-svg-actions.rdf :
21:28:50 <RRSAgent> ACTION: Cameron to set up Leipzig meeting questionairre [1]
21:28:50 <RRSAgent>   recorded in http://www.w3.org/2014/02/27-svg-irc#T20-38-55
21:28:50 <RRSAgent> ACTION: Erik to define SVGMatrix.rotateFromVector(0,0) in SVG 2 not to throw [2]
21:28:50 <RRSAgent>   recorded in http://www.w3.org/2014/02/27-svg-irc#T20-43-48
21:28:50 <RRSAgent> ACTION: Cameron to change the content model of <canvas> in SVG to allow the same child elements as <g>. [3]
21:28:50 <RRSAgent>   recorded in http://www.w3.org/2014/02/27-svg-irc#T21-25-34