- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 28 Feb 2014 08:30:03 +1100
- To: "www-svg@w3.org" <www-svg@w3.org>
Minutes from this week's telcon are below.
http://www.w3.org/2014/02/27-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
27 Feb 2014
[2]Agenda
[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
Attendees
Present
Thomas_Smailus, krit, [IPcaller], ed, stakagi, birtles,
heycam, Tav, nikos, Doug_Schepers, Rich_Schwerdtfeger,
cabanier
Regrets
Chair
ed
Scribe
Cameron
Contents
* [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
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>
[11]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Leipzig_2014
[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
[12]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>
[13]http://www.w3.org/Graphics/SVG/WG/track/issues/2457
[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
<krit>
[14]http://www.w3.org/TR/matrix/#widl-DOMMatrix-rotateFromVecto
r-DOMMatrix-unrestricted-double-x-unrestricted-double-y
[14]
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
[15]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:
[16]https://www.w3.org/Graphics/SVG/WG/wiki/images/d/d8/Feature
s_needed_in_SVG2_for_Technical_Diagrams.pdf)
[16]
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>
[17]https://svgwg.org/svg2-draft/embedded.html#CanvasElement
[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
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
[18]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> [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
[20]http://www.w3.org/2014/02/27-svg-minutes.html#action03]
[NEW] ACTION: Cameron to set up Leipzig meeting questionairre
[recorded in
[21]http://www.w3.org/2014/02/27-svg-minutes.html#action01]
[NEW] ACTION: Erik to define SVGMatrix.rotateFromVector(0,0) in
SVG 2 not to throw [recorded in
[22]http://www.w3.org/2014/02/27-svg-minutes.html#action02]
[End of minutes]
Received on Thursday, 27 February 2014 21:30:39 UTC