- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 29 Jul 2011 12:42:53 +1200
- To: www-svg@w3.org
- Cc: public-svg-wg@w3.org
The HTML minutes for the Seattle F2F day 1 are at:
http://www.w3.org/2011/07/27-svg-minutes.html
but have unfortunately been merged with day 1’s minutes. Below is the
text version of just day 1.
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
27 Jul 2011
[2]Agenda
[2] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda
See also: [3]IRC log
[3] http://www.w3.org/2011/07/27-svg-irc
Attendees
Present
heycam, brian, ed, cabanier, cyril, stearns_, tabatkins_,
tbah, shepazu, Charles, Pritchard
Regrets
Chair
SV_MEETING_CHAIR
Scribe
Cameron
Contents
* [4]Topics
1. [5]Glyph Selection
2. [6]text warping
3. [7]Event attributes in SVG2
4. [8]image-rendering property and why Tab is redefining it
5. [9]SVG in Canvas
6. [10]SVG Accessibility
* [11]Summary of Action Items
_________________________________________________________
<trackbot> Date: 27 July 2011
<vhardy_> ScribeNick: vhardy
<vhardy_> heycam: Topic Glyph Selection
Glyph Selection
<vhardy_> cabanier: this is an issue that came up a couple months
ago like SVG does not let you select particular glyphs.
<vhardy_> cabanier: my proposal is to mimic what PDF does. Instead
of specifying characters, you could specify offsets in the font. It
would not rely on the text layout engine.
<vhardy_> heycam: talking about encoding may be misleading.
<vhardy_> cabanier: with identity encoding, the code is an index
pointing to a glyph.
<vhardy_> cabanier: so this is very specific to the font you pick.
If the font is not available, it does not work.
<ChrisL> its glyph encoding, not character encoding
<vhardy_> heycam: so you are talking about having glyph indices
instead of text characters.
<vhardy_> cabanier: yes, that gives you more access.
<vhardy_> birtles: what about accessibility?
<vhardy_> cabanier: in the PDF precedent, there is a mapping between
the glyphs and the unicode characters.
<ChrisL> yeah the accessibility folks are going to love this. there
is no access t the text.
<vhardy_> heycam: so you specify glyph id to unicode character
mapping.
<ChrisL> and if we put it in an attribute then the I18n folks will
shout, to. So it needs to be element content
<vhardy_> birtles: so for a user agent, you would have to have a
mapping table.
<vhardy_> cabanier: yes.
<vhardy_> birtles: there is some work that John Dagget on variation
selectors. is that relevant here.
<vhardy_> vhardy: are you talking about IVSes?
<ChrisL>
[12]http://www.w3.org/Talks/2010/ChrisLilley-SVG-LaCantine/cover.svg
requires firefox 4+
[12] http://www.w3.org/Talks/2010/ChrisLilley-SVG-LaCantine/cover.svg
<vhardy_> birtles: yes, but I was also thinking of specific
properties to chose ligatures.
<vhardy_> birtles: would that be enough?
<vhardy_> chril: this is experimental syntax in FF.
<ChrisL> it uses vendor prefixes
<ChrisL> eg .dlig {font-size: 60px ; -moz-font-feature-settings:
"dlig=1,ss01=1,case=1"; }
<vhardy_> vhardy: the requirement is to provide absolute control
over the glyph selection and their positioning.
<vhardy_> heycam: do you have a proposal?
<vhardy_> cabanier: not yet. Would like to offer the same feature
level as PDF.
<vhardy_> heycam: Example:
<vhardy_> .... <text x="10 20 30"><altGlyph
xlink:href="#a">a</altGlyph>...</text>
<vhardy_> <altGlyphDef id="a"><glyphRef glyph-name="..." />
</altGlyphName>
<vhardy_> heycam: the altGlyph element allows you to select the
specific glyph to use for a particular run of text.
<vhardy_> cabanier: wouldn't the text engine still try to do
ligatures?
<vhardy_> heycam: yes, without altGlyph. Not with altGlyph.
<vhardy_> shepazu: with the current mechanisms, you can disable
ligatures if you want to.
<vhardy_> cyril: what about glyph substitution?
<ChrisL> 6.5 Ligatures: the font-variant-ligatures property
<vhardy_> heycam: If you select a glyph, there is no substitution.
<ChrisL>
[13]http://dev.w3.org/csswg/css3-fonts/#font-variant-ligatures-prop
[13] http://dev.w3.org/csswg/css3-fonts/#font-variant-ligatures-prop
<ChrisL> Value: normal | inherit | [ <common-lig-values> ||
<additional-lig-values> || <historical-lig-values> ]
<vhardy_> shepazu: if you wanted a particular shape, you could use a
combiniation of markup and styling to achieve the effect.
<vhardy_> heycam: in the use case I presented, you want no layout at
all.
<ChrisL> 6.9 Defining font specific alternates: the
@font-feature-values rule
<vhardy_> shepazu: I do not see a collection of what we want on the
wiki page. Are we sure we have the requirements clear?
<ChrisL> [14]http://dev.w3.org/csswg/css3-fonts/#font-feature-values
[14] http://dev.w3.org/csswg/css3-fonts/#font-feature-values
<vhardy_> cabanier, heycam: yes.
<vhardy_> heycam: if you have a tool that has done the glyph
selection and layout and you want to guarantee the output, you need
a solution like this.
<vhardy_> cyril: why not use shapes in that case?
<vhardy_> cabanier: you would lose accessibility.
<vhardy_> shepazu: you could use a graphic and a <title>
<vhardy_> vhardy: you also need a solution like this if you have a
significant chunk of text. Having all path is verbose.
<vhardy_> shepazu: another use case is groovy text with interlocking
shapes.
<vhardy_> stearns: yes, there are fonts that have the right
combinations of glyphs, and you could select those easily.
<vhardy_> shepazu: show an example of "Groovy text" with intertwined
glyphs.
<vhardy_> (discussion about whether the altGlyph could also
reference a shape)
<vhardy_> heycam: 3 main things:
<vhardy_> .. 1. how you reference a glyph in a font
<vhardy_> by id and have that disable glyph selection.
<vhardy_> .. 2. positioning 'characters' instead of glyphs in the
<text> element's x attribute
<vhardy_> .. 3. ability to have an altGlyph reference a shape.
<vhardy_> shepazu: if we had capability #3, people would use it.
<vhardy_> (discussion on text path and shape path).
<vhardy_> shepazu: there has not been proposal to get shapes as part
of a text layout.
<vhardy_> vhardy: to get back to cabanier's proposal, I think we
have:
<vhardy_> ... 1. there is a mechanism for selecting specific glyph.
It is clear for SVG fonts. The first issue is to clarify how to do
that for other font formats, in particular opentype fonts.
<vhardy_> ... 2. there is a mechanism for positioning characters (x
and y attributes) and that should be positioning glyphs.
<vhardy_> ... 3. If 1 and 2 are addressed, we need to see if the
solution would be terse enough to be acceptable.
<vhardy_> shepazu: Here is an example for groovy text:
<vhardy_> <g x-advance=".." id="groovytext">
<vhardy_> <path .../>
<vhardy_> <path .../>
<vhardy_> </g>
<vhardy_> heycam: yes, it would make a solution simpler.
<vhardy_> shepazu: yes, and it would avoid the font coordinate
orientation issue.
<vhardy_> (discussion about the text x/y positions and how they work
with ligatures)
<vhardy_> heycam: for example if you have <text x="10 20
30">ffe<text>
<vhardy_> if the font has the ff ligature, the first glyph (for ff)
will be at x=10 and the second glyph (for e) will be positioned at
20.
<vhardy_> if there is no ligature for ff, the first f is at 10, the
second at 20 and e at 30.
<vhardy_> birtles: jdaggett says we should talk about glyph clusters
and not glyphs.
<vhardy_> stearns shows a hindic example where the cluster is made
of multiple glyphs.
<ChrisL> sigh. I'm going to get dropped every 50 minutes
<vhardy_> ACTION: cabanier to define how to use <glyphRef>'s
glyphRef attribute to point to an openType glyph and make sure it
works with the different openType format variations. [recorded in
[15]http://www.w3.org/2011/07/27-svg-minutes.html#action01]
<trackbot> Created ACTION-3073 - Define how to use <glyphRef>'s
glyphRef attribute to point to an openType glyph and make sure it
works with the different openType format variations. [on Rik
Cabanier - due 2011-08-03].
<vhardy_> ACTION-3073: Report on how this would work with the
shaping process.
<trackbot> ACTION-3073 Define how to use <glyphRef>'s glyphRef
attribute to point to an openType glyph and make sure it works with
the different openType format variations. notes added
<vhardy_> (discussion on character and glyph positioning).
<vhardy_> heycam: when altGlyphs are used we should allow the author
to skip extraneous x/y values that are not used because of
ligatures.
<vhardy_> ACTION: cabanier to work with vhardy and text experts on
x/y positioning and altGlyphDef and altGlyph. [recorded in
[16]http://www.w3.org/2011/07/27-svg-minutes.html#action02]
<trackbot> Created ACTION-3074 - Work with vhardy and text experts
on x/y positioning and altGlyphDef and altGlyph. [on Rik Cabanier -
due 2011-08-03].
<vhardy_> vhardy: what is the support for altGlyph and altGlyphDef?
<vhardy_> ed: Opera and WebKit have support altGlyph for SVG fonts,
but not altGlyph for Opentype fonts AFAIK.
<tbah> Call ended....
<vhardy_> heycam: we should be able to extend the syntax if needed.
<vhardy_> birtle: we also need to keep accessibility in mind in the
new solution.
<vhardy_> ACTION: shepazu to create a proposal for "Groovy Text",
i.e., a solution for easily provide the graphical rendering of a
piece of text with SVG graphics. [recorded in
[17]http://www.w3.org/2011/07/27-svg-minutes.html#action03]
<trackbot> Created ACTION-3075 - Create a proposal for "Groovy
Text", i.e., a solution for easily provide the graphical rendering
of a piece of text with SVG graphics. [on Doug Schepers - due
2011-08-03].
text warping
<vhardy_> heycam: tbah, can you summarize the issue.
<tbah> [18]http://tavmjong.free.fr/SVG/TEXT_PATH/TextPath.html
[18] http://tavmjong.free.fr/SVG/TEXT_PATH/TextPath.html
<vhardy_> tbah: this is following our last discussion on Israel's
examples.
<vhardy_> tbah: you can see the limitations with wide characters and
text stretch.
<vhardy_> tbah: I have looked at the different ways that InkScape
can distort paths.
<vhardy_> tbah: the most interesting are the ones at the bottom.
<vhardy_> tbah: the ones done as envelope deformations.
<ChrisL> using Inkscape's Envelope Deformation LPE
<vhardy_> tbah: it uses for paths, top, bottom, left and right.
<vhardy_> tbah: InkScape keeps the original path.
<vhardy_> tbah: it shows the kind of things you could do.
<vhardy_> tbah: it works nicely.
<vhardy_> tbah: the algorithm does not preserve vertical lines
<vhardy_> tbah: the person that wrote this code for InkScape could
modify to do whatever we want.
<vhardy_> tbah: it would be nice to do that without converting to a
path.
<vhardy_> tbah: it would also be nice to use the base line of the
text instead of the visual bounding box bottom edge
<vhardy_> heycam: question: none of the glyphs have descenders in
the examples.
<ChrisL> base line and ascent as top and bottom paths
<vhardy_> tbah: if they had descenders, they would be shifted up.
<vhardy_> tbah: there is an example.
<vhardy_> (example with descender has 'Sample Text: Office')
<vhardy_> shepazu: this satisfies some of the Groovy text examples.
<vhardy_> shepazu: how hard is this to implement.
<vhardy_> tbah: the implementation is complicated, but it is pretty
fast.
<ChrisL> a path is converted to an SBasis (Symmetric power basis)
polynomial representation, transformed, and then converted back to
Bezier curves. This is done using the lib2geom library package
<vhardy_> tbah: it subdivides the path into small chunks and then
transforms them.
<vhardy_> chrisl: it would be better to transform the control points
and avoid subdividing.
<vhardy_> tbah: I have thought about that for straight lines, and it
is not clear how you add control points, where you add them and how
they get transformed.
<vhardy_> heycam: I think you need to subdivide.
<vhardy_> chrisl: I do not agree you need to subdivide. It is one
way, that is not the only.
<ChrisL> NURBs
<ChrisL> I notice that lib2geom also has nurrbs support
<vhardy_> (discussion on the merits of converting to and back to
NURBS or other representation and how this will create more Bezier
curves in general, but may be better than subdividing upfront).
<vhardy_> tbah: lib2geom uses convertion to SBasis curves.
<vhardy_> tbah: InkScape uses these curves extensively.
<vhardy_> heycam: is it simpler to use text on a path and warping
that v.s. 4 different paths on all sides.
<vhardy_> ... algorithmically simpler.
<vhardy_> tbah: I dont think it is necessarily simpler.
<ChrisL> lib2geom has an irc dump as documentation :)
<ChrisL> quote
<ChrisL> All of these operations are fast. For example,
multiplication of two
<ChrisL> beziers by converting to s-basis form, multiplying and
converting back
<ChrisL> takes roughly the same time as performing the bezier
multiplication
<ChrisL> directly, and furthermore, subdivision and degree reduction
are
<ChrisL> straightforward in this form.
<ChrisL> unquote
<heycam> yeah
<heycam> I would love to understand how those s-basis curves work :)
<heycam> and the conversion between them and beziers
<ChrisL>
\cite{SanchezReyes1997,SanchezReyes2000,SanchezReyes2001,SanchezReye
s2003,SanchezReyes2004}.
<ChrisL> the same library uses SBasic curves to do the union and
difference operations
<tbah> I would doubt this would use much CPU as compared to some of
the filters.
<heycam> heh
<heycam> maybe we can get gpu accelerated path warping
<tbah> The warped D in one of my examples has 33 nodes after warping
compared to 30 before so converting
<tbah> to and from the s-basis form doesn't seem to add that many
extra nodes.
<heycam> nice
<ChrisL> right. i would expect the node increase to be proportional
to the degree f warping
<ChrisL> tha tis a bg difference froma pre-subdivide or
pre-tesellation approach
<heycam> yeah, I agree
<TabAtkins__> ScribeNick: TabAtkins__
shepazu: What is the scope or place for this? SVG2, or a special
module, or what?
tbah: Dunno.
... This started as a way of clarifying what to do with the
"stretch" value.
vhardy_: What was israel asking for?
ed: First he was just asking for "stretch" to be clarified. As it
went on, he moved to wanting a more expressive modle.
vhardy_: One possibility is to just give access to the text
geometry, and let you do crazy things with the geometry yourself.
... Java2d had something similar, where it gave you the geometry of
the text outline.
heycam: That's probably a good short step forward.
... We may want to consider building in some kind of functionality,
though.
... I think that when people to textpath, they probably want glyphs
to be stretched properly. Currently it's just often ugly.
vhardy_: In Tav's example, look at, frex, the "ribbon" example - it
often looks better than the "snake" option.
... So these are some very simply things we could offer (that would
be a bit heavy-handed to force authors to do themselves in script)
that would make it prettier, without going all-out.
tbah: Note that, in the example, each top option is transforming the
points directly, while the lower option splits each path segment
into thirds before transforming the points.
heycam: The "snake" option is only transitioning the controlpoints,
right?
tbah: Yes.
heycam: I'm not sure what we want to get out of this discussion
today.
<vhardy_> Converting Bezier curves to NURBS:
[19]http://www.mactech.com/articles/develop/issue_25/schneider.html
[19] http://www.mactech.com/articles/develop/issue_25/schneider.html
heycam: it seems that people are in agreement that we want to expose
the glyph shapes to script, so people can at least do arbitrary
warpning in script.
... I have the feeling that I'd like us to do nicer text on a path
than at the moment, but I'm not sure what option we'd choose for
that.
tbah: For now, I suggest that horizontal lines be warped to match
the shape of the path, specified in the current spec.
TabAtkins__: Current impls do "stretch" by transforming the glyph
bounding box into a quad and doing a simple perspective transform,
which is pretty ugly.
tbah: Israel's suggestion means that horizontal lines are
transformed such that their tangent is always parallel to the path.
... Vertical positions would be the same distance from the path as
they are the baseline.
heycam: Would that involve subdividing path segments?
TabAtkins__: Yes, it would imply that horizontal lines become curved
lines.
vhardy_: [shows an example of how a perpendicular grid would be
transformed, using those principles]
heycam: Is that the same as the "office text"-in-a-circle example?
vhardy_: Yes.
heycam: Ok, that's the result that I'd like.
... I'm slightly reluctant to put in spec requirements for things
beyond basic graphics algorithms without saying how to do it.
vhardy_: Is Bob Hopegood still an IE in the group?
ChrisL: No, but we could ask him to rejoin.
... Cam, why are you reluctant?
heycam: Just reluctant to do so without explaining how to do it, so
it's defined in the spec.
<ChrisL> I missed the "without saying how" part on the phone, hence
my question
vhardy_: I'd like either Israel, if he's up to it, or Bob, if he's
interested in rejoining, to help draft this stuff.
<heycam> ChrisL, no problem
shepazu: They don't even need to join, if they just help explain it.
... We all agree though that step 1 is exposing the path data via
some API.
heycam: I think that's reasonable to resolve on.
RESOLUTION: We will provide a way to get glyph path data via some
API.
[some discussion about where this would live]
heycam: We can decide whether this would apply to single glyphs, or
if you get the total path from a run of text, or what.
... So I think there are a few different ways we could expose this
information.
... Like something that just takes a font name and a character, or
whatnot.
ed: There may be different ways of rendering, so you'd want it on
the element. Frex, for simple text we may just hand the text over to
the platform API, which may end up with a different shape.
vhardy_: In Java, if you ask for the glyph outline you get the
non-hinted outline.
heycam: I'm happy to write a proposal for something simple.
cabanier: In some fonts you're not allowed to get the outlines.
heycam: I don't see any difference between exposing the bytes of the
font and exposing the path.
[unminuted discussion about legal issues]
shepazu: Summary is, we shouldn't talk about legal issues in the
spec. We should expose some way of determining that a glyph is
available or not (useful generally). Implementations might choose to
claim that glyphs aren't available for whatever reason.
<scribe> ACTION: heycam to come up with API proposal for exposing
glyph path data. [recorded in
[20]http://www.w3.org/2011/07/27-svg-minutes.html#action04]
<trackbot> Created ACTION-3076 - Come up with API proposal for
exposing glyph path data. [on Cameron McCormack - due 2011-08-03].
heycam: It sounds like we also want some options to talk to people
who know something about path warping algorithms.
... Like Bob or Israel, so they can help inform us as to whether we
add that into the SVG spec.
<scribe> ACTION: vhardy to reach out to Bob Hopgood for information
about path warping for text. [recorded in
[21]http://www.w3.org/2011/07/27-svg-minutes.html#action05]
<trackbot> Created ACTION-3077 - Reach out to Bob Hopgood for
information about path warping for text. [on Vincent Hardy - due
2011-08-03].
heycam: For Israel, I got the impression that Israel doesn't
particularly want to give away what he's doing, but it would be nice
to ask anyway.
vhardy_: We can ask - I think he has paths and does animation, but
in these examples it's exported pre-computed.
<scribe> ACTION: heycam to contact Israel about path warping
information. [recorded in
[22]http://www.w3.org/2011/07/27-svg-minutes.html#action06]
<trackbot> Created ACTION-3078 - Contact Israel about path warping
information. [on Cameron McCormack - due 2011-08-03].
ChrisL: What about the guy who does lib2geom?
heycam: Nathan Hurst
... I can contact him to ask him... something...
shepazu: Something important.
heycam: Perhaps he can explain what he does in a more explainable
manner.
<scribe> ACTION: heycan to contact Nathan Hurst about lib2geom for
information about path warping. [recorded in
[23]http://www.w3.org/2011/07/27-svg-minutes.html#action07]
<trackbot> Sorry, couldn't find user - heycan
<scribe> ACTION: heycam to contact Nathan Hurst about lib2geom for
information about path warping. [recorded in
[24]http://www.w3.org/2011/07/27-svg-minutes.html#action08]
<trackbot> Created ACTION-3079 - Contact Nathan Hurst about lib2geom
for information about path warping. [on Cameron McCormack - due
2011-08-03].
heycam: Tav, anything else?
tbah: No, that's it.
Event attributes in SVG2
ed: I think SVG2 should align with what HTML5 does wrt event
attributes.
... Basically that would add all of the on* attributes to the svg
attributes.
... And for any new events, they'd automatically get an
on[event-name] attribute added to all relevant elements.
anne: The way HTML does it is that, for each element that's
dispatched, there's a corresponding on* attribute.
... Currently they're exposed on window, document, and HTMLElement.
Plus a few that are only exposed on specific objects, like XHR or
WebSocket.
... But, frex, things that are dispatched on <video> can be caught
higher by using the on* attribute.
... So I think SVG should follow the same path. Any attributes that
are dispatched should be added to SVGElement.
<ChrisL> yes it would be better to pu them on Element and have
HTMLElement SVGElement inherit
heycam: SVG doesn't have many novel events that aren't already
exposed generally.
birtles: The SMIL events.
ed: SVG has a 'SVGRotate' event, too.
[vhardy reviews the list of SVG events]
<ChrisL> on[a-zA-Z-]*
heycam: Are there examples in HTML of element-based events being
scoped?
anne: No, anything that dispatches on elements are available on
HTMLElement, document, and window.
heycam: Maybe HTML could define a hook so that we can put these
things on window, or we can just do it ourselves.
anne: You can use the new "partial" thing in WebIDL.
... There's some thought to define the hooks in DOMCore.
<br type=lunch-prep duration=5min>
heycam: We haven't moved to the on* being on Element yet; right now
it's on HTMLElement.
... Should we wait for DOMCore to define them on Element, or put
them on SVGElement.
anne: I think Moz already puts them on Element, and they said that
the HTML events should move to match them.
... So I think if we move those we should move SVG events as well.
vhardy_: What's the status of that move?
anne: Nothing is moved so far, and I'm not sure DOMCore should
define it; it would need to contain a long magic list of attributes
that would be continually updated.
... But I think DOMCore could define some hooks that make it easy
for other specs to define their events on Element.
vhardy_: What about the SVG-specific events? Should we ask the
HTMLWG to add them?
anne: Sounds like a good idea.
heycam: Are there event listener attributes defined in HTML that
aren't HTML-specific?
anne: Well, something like onscroll
... They could fire in a document with no HTML elements in them.
heycam: Okay, so sounds like everyone thinks this is a good idea (to
have the events on Element).
... anne, any timescale?
anne: Haven't looked into it yet.
heycam: It's not an immediate concern, but.
anne: Probably in the next six months or so.
RESOLUTION: SVG2 will move all events to Element, in accordance with
the similar move in HTML.
anne: If you could file a bug it would be easier to follow up on.
<scribe> ACTION: heycam to file a bug on DOMCore to remind Anne
about the event move. [recorded in
[25]http://www.w3.org/2011/07/27-svg-minutes.html#action09]
<trackbot> Created ACTION-3080 - File a bug on DOMCore to remind
Anne about the event move. [on Cameron McCormack - due 2011-08-03].
image-rendering property and why Tab is redefining it
<heycam> Scribe: Cameron
[26]http://dev.w3.org/csswg/css3-images/#image-rendering
[26] http://dev.w3.org/csswg/css3-images/#image-rendering
<heycam> ScribeNick: heycam
TA: the pixelate value was added a week ago
... I've specifically defined optimizeSpeed and optimizeQuality as
simply being equivalent to auto
... if your specific goal is high quality grphics, you do need the
ability to control speed & quality
... in general in CSS, you specificalyl don't want to give authors
control of this
... you want the browser to do the best it can
... if you let them make the choice, they will base their decision
on their own machine
... whenever we offer features that let you make a performance
sensitive choice, they do it based on their computer
... so the new values I've added to image-rendering are specifically
intent based
... "this image should preserve certain features when
resized/scaled"
... browsers are then free to use whatever algorithm they want to
match the intent
... auto can drop down to nearest neighbour
... but when you have the resources, use bicubic
... chrome resizes in bilinear, then after a timer if no further
resizes are done, redoes it with lancosz
... the other two svg defined values just map to auto
... crispEdges would be used for pixel art or diagram with straight
edges, something that would look bad if the edges were blurred
... in the simple case, you can use nearest neighbour, but
alternatives could be used
... pixellate I added, which means just embiggen the pixels
CM: what's the difference?
TA: pixellate would just do pixel scaling, crispEdges could use a
different algorithm for pixel art scaling for example
DS: you might have an image editing program where you want to see
big square pixels
CM: would we want to do something similar with the other properties,
text-rendering etc.?
VH: should we add values to image-rendering rather than replace
them?
TA: what intent is good to have for vector images?
... crispEdges and pixellate would be more useful for rasters
... if there are specific types of intents that we want for vector
values, we could use those
VH: I think that's a good point, but it's a separate problem
... you're talking abotu a case when referenceing a vector image
... image-rendering is already used in SVG
TA: the way I'm using image-rendering is only for raster images
ED: that's how it's defined in SVG too
TA: in that case, if we can tell what the current of optimizeSpeed
and optimizeQuality are intending, we could define them instead of
mapping to auto, or mapping them to an existing intent based keyword
VH: I can see your point of view, but I would also like the original
definition of image-rendering
... as an author I would like to have the four sets of values
... somethings you would like this to be fast, so if you're on a
faster computer, that's fine use a high quality algorithm
... I'm more focused on the user experience than visual quality
PD: we came to the same conclusion about not supporting
image-rendering
... you couldn't as an author determine what the end user's desire
was
... at the same time I don't understand your two recommendations
TA: the various pixel scaling algorithms are used by emulators
JY: what would the test for that look like?
TA: I'm not sure this property is testable
... the only MUST in there is for upscaling with pixellate
... the rest are SHOULDs
VH: if I'm an author and I want an image that may want to be scaled,
or printed for example
... for printing I'd probably want optimizeQuality, it may take
time, but I'd want it to be printed high quality
TA: currently, the only time browsers use low quality algorithms is
if there really is not enough time for the HQ algorithms
... otherwise, it assumes as high quality as it can provide
... the rendering intent you want doesn't seem to be useful
... I think the browser will do the highest quality in the time it
can
VH: java2d lets you select particular algorihtms
TA: webgl exposes some levels of performance information, so you can
decide things yourself
... with webgl you really need the game to decide to scale back its
work
... with images, in practice, I don't think there's a problem
... with one of the IE demos there were lots of scaled logos moving
around, using bilinear was still too slow
... but we could choose to use nearest neighbour to make it fast
enough
... so what we do now, fast when it can be, I think is what you
always want
... if you have use cases where you really need it to be this way,
browsers would make the wrong decision, I would like to see them
VH: the one were you said it was too slow because it chose bilinear
CM: I would say that's just a bug
VH: I think we're making a choice of speed vs visual quality
... and you're saying we will degrade quality to increase speed
... they may prefer to have a slower animation
TA: so it's deciding between animation jank and quality
VH: what nags me a bit is saying we can decide what's best for the
author
TA: I think in the vast majority of cases we can get and do make
that decision correctly
... and I'm not sure the remaining cases are important enough that
we need to give that sort of control to the author
... for example in the really high load flying images constant
resizing, I think it's pretty clear you don't want janky animations
... they always look bad
... so I think the browser can make that decision and it will be
right in the vast majority of cases
... in those tiny minority of cases where it really matters, it will
much more often be misused
... and you would end up requiring an uglier experience
VH: with optimizeSpeed, if you had the bandwidth you could use the
higher quality
... it doesn't mean use the fast path all the time
... it's a tradeoff
... I think there's a tradeoff between visual quality and
speed/performance, and that the current settings allow you to say
where you stand on that balance
... if you run and find out that the most expensive interpolation
method you still have a nice frame rate, even with optimizeSpeed you
would keep that algorithm
ED: the spec already says something like that
... if you can achieve the performance with HQ algorithms, just use
that
BB: you also want particular algorithms sometimes
VH: so I like the additional settings, I'm not opposed to that
... this is just about the existing settings
TA: optimizeSpeed seems to be in really emergency situations, when
you have to make a choice between unarguably ugly with image
rendering, or janky with animations, you have to decide
... in that case, I could see optimizeSpeed having some value
... in all other cases it would be equivalent to auto
<ed>
[27]http://www.w3.org/TR/SVG11/painting.html#ImageRenderingProperty
[27] http://www.w3.org/TR/SVG11/painting.html#ImageRenderingProperty
CM: I think that's what the existing definitions say
... that's not to say that's how they're implemented, but that's the
intention of the spec
TA: ok, so I can take optimizeSpeed and reword it to make sure it's
clear it means use nearest neighbour all the time, e.g.
... it means use the best you can, and if you can't get the best
speed, use lower quality
VH: what about optimizeQuality?
TA: that's the same as auto
VH: don't think so, currently it says "at least as good as bilinear"
TA: I think that's a bad thing. animation jank is nearly always
worse than lower quality.
... optimizeQuality preventing you from going below bilinear is a
bug
... since framerate is a larger problem
VH: I think there are cases, not in the context of animation, print
would be one, and as an implementor you need to decide what
alogirhmt you're going to use
... so you might want to use nearest neighbour for the sake of time,
but the author may want a better quality
TA: the way hardware is these days, you could use lancosz for
printing without a time problem
... back in the day, sure, since that might take 2 seconds to scale
the image. now it's 10ms or whatever, slow enough that animation
suffers, but fast enough that you won't notice print stuff
... like patrick was saying, some of these seem like they were more
useful several years ago, and now we have enough performance not to
trade off as much
... in the future, we won't need to worry about optimizeSpeed
either, because we will always be able to do HQ in time
DJ: I tend to agree with Tab
... I think the new keywords are the more improtant ones, the ones
that guarantee "worse looking" images
VH: I'm ok with what you said, if you add optimizeSpeed
... I think it's easier to add values
TA: the old ones would just be aliased to auto
VH: oh, so alias optimizeQuality to auto
... and keep optimizeSpeed?
<ed> scribeNick: ed
SVG in Canvas
DS: currenlty you can use canvas in html, with the canvas element
... there's a set of things for which canvas is better than svg, and
vice versa
... getPixelAtPoint
DJ: you have to getImageData and pull out pixels
TabAtkins__: in canvas you can get a pixel value, which isn't
possible in svg
... [highlevel description of what canvas is]
... you can e.g do blur by manipulating pixels in the imagedata
... you can draw video to it, and you can pull binary blobs from it
CM: that's like the toDataURI but without the uri, right?
TabAtkins__: yes
... the WebGL context can do more things, like use shaders and so on
CP: hlsl could be abstracted out, canvas acts as a middle for svg,
for html
vhardy_: you can draw svg to canvas, right?
TabAtkins__: yes, via image
... drawImage and pass in an svg
anne: passing in an svg element is not in the spec
... opera supports that
DS: that should be in the spec
CP: it works already via image element, which is specced
[a round of introduction, group welcomes Charles Pritchard to the
session]
DS: i would like to use canvas in svg
... to e.g expose the canvas via the svg:image element
DJ: wouldn't it be better to have a canvas element in svg instead?
... you're duplicating an API
... it's the canvas context thatäs the verbose api
... you expose the getContext method on the image element, but
that's a bit weird because you draw to it
... if you use the exact same element and API then that makes it
easier
anne: presumably the html group could have done the same, but didn't
CP: there's also the getCSSCanvas
... works together with css
... only one set of width and height ...
... allows you to get scalable results
... it's manual with canvas
... but with getCSScanvascontext
... it's slightly different
... it's more managed
... in webkit you can buffer the drawing commands and replay them
later
... you can use a set of bitmaps to get more scalable
... they're not managing multiple bitmaps
... works with css backgrounds
CM: not that familiar with the getCSSContext
TabAtkins__: mozilla can use moz-element to render any element into
a background
... webkit has something that allows you to pull out a canvas
context from a background
DJ: getCSSContext was a hack we wish we didn't put in
... we want to move to element()
DS: svg doesn't have backgrounds
TabAtkins__: svg has fills
DS: but it's not the same
... the svg root could have a background
vhardy_: svg tiny does have viewport-fill
DS: maybe we could allow backgrounds in svg
... and allow getting a canvas from the background
TabAtkins__: both produce the image as imagevalues, and you can fill
something with a canvas
CM: so rect filled with some canvas content
vhardy_: for the paintservers?
TabAtkins__: via the element() syntax you could point to something
like that
<circle fill="element(mycanvas)"/>
<canvas id="mycanvas">
vhardy_: how does this all work?
... so not the getCSSContext, but the element() syntax
TabAtkins__: right
... can refer to things outside of the document
vhardy_: by id?
TabAtkins__: yes
CP: is it the case now that you can use getCSSContext?
TabAtkins__: yes, but we want to move away from that
DS: so we could use a canvas to fill any shape in svg
vhardy_: the element syntax is implemented in firefox?
TabAtkins__: yes
... not all parts we discussed here
... need to add the syntax for the paintservers
DS: that's the kind of integration i'd like to see in svg
vhardy_: the other part is the canvas element in svg
... width and height are different in svg than in html
DS: they perhaps need to be resolved to pixels differently
TabAtkins__: you need the width and height to be the pixel
dimensions
CM: you could rescale if the zoomfactor changes
vhardy_: what do you do if you zoom an html page with canvas?
CP: you listen for the resize event and redraw the canvas
DS: in svg you could just use currentScale
vhardy_: you have to detect that the canvas size changes, and set it
CP: yeah, just do that and set a scale transform
DJ: you may have to look at device pixel ratio
CP: yes, for devices, but on desktop it usualyl doesn't cahnge
CM: what happens when the svg transforms scale something that has a
canvas element below?
DJ: the coordinate system in svg is independent
... you have to say how many pixels you want
CM: so the smallest size that looks nice at the transformed size
DJ: typically ppl means css pixels
CM: so authors should be in control?
DJ: well, you specifgy in user untis the size of the canvas element
for layout in the svg
... but you delay creating the backing bitmap
CP: but what if several places uses the same canvas element, but
with different scales?
... do you have to use separate canvas elements to get it without
pixelizing the result?
CM: if you were animating a transform of a <g> containing a
<canvas>, would you have to recreate the bitmap?
TabAtkins__: or you have to start out big so that it's scaled ok
CM: you keep the bitmap buffer around
vhardy_: right, but you might want to repaint if the size changes
CM: so you only want to know if the transform changes
vhardy_: canvas should be a same as anything else you draw
... so rasterize so that it looks ok
CM: you still need to redraw the canvas manually
DJ: if you pinchtozoom would you expect to recreate the canvas for
each step?
vhardy_: just asking for a way to get notified when the scale
changes
CP: css transitions has transitionend/start
DJ: by default when you draw something in svg you get optimal
rendering
... except for a raster image, which has to be scaled
... wiuth canvas you can improve the visual output depending on
scale
vhardy_: if you listen for zoom and resize events you could solve
some of these things, similar to how it's done in html today
CP: requestAnimationFrame gives a hook where you can attach some
handling
vhardy_: you could do that outside the repaint loop
... i think i can withdraw my proposal, maybe we have enough with
the zoom and resize events
<vhardy_> ed: I am interested in having Canvas in SVG.
DS: interesting to drill down into detail, but i'm just looking at
gaging the interest in having the functionality
<ChrisL> I'm in favour of havinga cavas element available in svg
<ChrisL> ... but have no special input beyond that
DJ: typically people don't run javascript int he middle of painting
... it's the using of javascript that updates the rendering
... bigger concern is if you have a loop of canvas in html drawing
something svg with canvas (circular loop)
CP: that's just going to give a static bitmap
CC: what about export of svg rendered to the canvas?
TabAtkins__: most of the canvas drawing commands maps to svg
... but when you're manipulating pixels directly then it's not
really possible
vhardy_: can you hook up a new context to the canvas element?
DS: there's been lots of experimenting with wrapping canvas and svg
... given a raster you can't go back to vectors
CP: recording commands is possible, but it's overhead
... but you're going to want a dom tree anyway
... svg is great for interop, and we use it for a few things
<shepazu> [28]http://schepers.cc/w3c/svg/api/cog.svg
[28] http://schepers.cc/w3c/svg/api/cog.svg
CP: but you want something with great svg import/export
... not script hacks
DS: svg's dom api sucks
<TabAtkins__> [29]https://wiki.mozilla.org/SVG:Language:Regrets
[29] https://wiki.mozilla.org/SVG:Language:Regrets
<jwatt> hey, that's my secret page
<TabAtkins__> NOT SO SECRET ANYMORE
<jwatt> apparently
<dino> wow. I have many more regrets about SVG than jwatt.
<dino> i would not know where to start :)
<jwatt> there's only so many I had time to write down
<jwatt> :)
<TabAtkins__>
[30]https://docs.google.com/a/google.com/document/edit?id=1WYzbMkC_Q
1pi6HyMNu4p6XevqXtGEHvmRjEZZemR6r8&hl=en&pli=1#
[30] https://docs.google.com/a/google.com/document/edit?id=1WYzbMkC_Q1pi6HyMNu4p6XevqXtGEHvmRjEZZemR6r8&hl=en&pli=1
DS: one of the reasons ppl like to use canvas is because they want
to make a cirlce or path, more intuitive than setting attributes,
creating elements
CP: js libraries do provide you with that
vhardy_: you need svg and canvas for different use-cases
... trying to merge the two is a good thing though
TabAtkins__: the svg dom is clumsy to work with
DS: and less intuitive than the canvas API
CM: right, so using DOM core methods that's too much work
CP: i like innerHTML
DS: there are script libs that allow you to do some things easier
... but having a shared language for creating the shapes and so on
is good
CM: you want to be able to use currentFill=blah, and fillRect and so
on and that it generates svg
vhardy_: but it can be hard to make that preserve structure
DS: we need to look at both, but unify gradients
vhardy_: there were some proposals for svg2 dom
... like inline json for example
<TabAtkins__> TabAtkins__: Some examples from a doc (unfortunately
private) for a better drawing API for SVG:
<TabAtkins__> var font = root.font(”DroidSans”, [”DroidSans.ttf”,
“DroidSans.swf”],
<TabAtkins__> {fontWeight: ‘bold’, fontStyle: ‘normal’});
<TabAtkins__> root.linearGradient(”myGradient”, “-blue-green”);
<TabAtkins__> var group = root.group();
<TabAtkins__> var rect = group.rect(20, 20, 300, 300, {fill:
“id(#myGradient)”});
<TabAtkins__> var text = group.text(30, 40, “Hello World!”,
<TabAtkins__> {fontFamily: “DroidSans”});
<TabAtkins__> group.translate(-5, -5)
<TabAtkins__> .scale(1.5, 1.5)
<TabAtkins__> .animate({x: 200, opacity: 0.2}, 2000);
DS: don't want to remove the ability to get good structued svg
files, with the new api
CP: you probably want to use svg, and use drawImage instead
CM: robert was in favor of doing something like that
... there are some immiate mode apis that allow you to do groups
... we could have that
vhardy_: as in the example shown above from tab
CP: inkml is the only format i've seen that has a streaming mode and
an archived mode
... you can flatten the strucutre
<shepazu> [31]http://www.w3.org/Graphics/SVG/WG/wiki/Simple_SVG_API
[31] http://www.w3.org/Graphics/SVG/WG/wiki/Simple_SVG_API
CP: pdf has streaming capabilites
... but improving the flexibility is good
... we want to preserve the vectors
DS: dropped in link, different from tabs exmaple
<vhardy_> vhardy: talking about variations, I like things like:
CM: are there any plans of improving DOM core to make it easier to
create elements and attributes
<vhardy_> var rect = group.append({tag: 'rect', x: 10, y: 20, fill:
'blue'});
anne: haven't heard any suggestions yet
CM: so ppl aren't complaining?
anne: not enough
... only suggesting i've heard is like "new HTMLElement"
... not a lot of requests on the mailinglists
<wi> hola
anne: there's innerHTML
CM: shouldn't we try to improve the base platform?
<wi> alguien desea platicar?
anne: does jquery have the sort of thing you're asking about?
CM: yes
anne: wondering about hte vconvinence methods they have
TabAtkins__: jquery just wraps up innerhtml
anne: that's being specified
vhardy_: the proposed syntax is json, i prefer that syntax over
innerhtml
CM: like taking a bag of arguments
<vhardy_> Summary of issues for SVG and Canvas integration:
<vhardy_> 1. <canvas> in SVG
DS: todataURI in svg is somethign i want, and getimagedata
<vhardy_> 2. SVG in 2D context's drawImage
<vhardy_> 3. CSS image values as SVG paint servers
<vhardy_> 4. SVG export from Canvas
<vhardy_> 5. SVG export to Canvas
CM: so just a convience function, to avoid having to paint svg to
canvas and pulling pixels/datauri out from that
CP: if canvas is a requirement of SVG2 then you can do many of these
thigns
DS: would like to see canvas as a firstclass element in svg
brian: so foreignObject?
anne: you could replace that with onlu <html> sort of like <svg>
works in html5
vhardy_: let's go through the list above
6. toDataURL
7. getImageData
CM: so first point?
vhardy_: we need to resolve the width/height issue
CM: just doing the same as <image> should work
brian: so why do we need this without the foreignObject?
ISSUE: <canvas> element in SVG
<trackbot> Created ISSUE-2417 - <canvas> element in SVG ; please
complete additional details at
[32]http://www.w3.org/Graphics/SVG/WG/track/issues/2417/edit .
[32] http://www.w3.org/Graphics/SVG/WG/track/issues/2417/edit
CM: next one, SVG in 2d context's drawImage
vhardy_: anne, drawImage doesn't mandate support for svg?
anne: right
DS: just needs to be mentioned in the spec
anne: you can pass in video, canvas and image elements in drawImage
vhardy_: we should request to be able to render an svg elements
TabAtkins__: there are some security concerns, like foreignObject
CP: to be able to draw an svg path directly to a canvas would be
nice
anne: there are many things that can be external in svg, and that
can taint the canvas
DS: the svg integration spec is meant to cover some of that
TabAtkins__: we could probably find a good way to do this, by
disabling some things
vhardy_: if you could paint an svgsvgelemnent to a canvas
... you could create a datauri of the subtree and pass that via the
drawImage call, so it's a workaround
... as an image.src
CP: taking a snapshot of an animated svg and creating a raster
s/6. toDataURL/6. toDataURL and toBlob/
ISSUE: SVG in 2D context's drawImage
<trackbot> Created ISSUE-2418 - SVG in 2D context's drawImage ;
please complete additional details at
[33]http://www.w3.org/Graphics/SVG/WG/track/issues/2418/edit .
[33] http://www.w3.org/Graphics/SVG/WG/track/issues/2418/edit
CM: so point 4
vhardy_: many libs allow this
... you can ask for the svg output
TabAtkins__: so let jslibs handle this
8. new API to construct svg trees
CM: so point 5
... SVG export to canvas
DS: this would tak e some arbitrary svg and spit out the
corresponding canvas javascript commands to do that
vhardy_: could be done in a library
CP: if svg paths was supported in canvas that would be nice, and
it's about 80 lines of js code to be able to handle that atm
<scribe> ACTION: Tab to work with charles pritchard to propose a
canvas function that uses svg paths [recorded in
[34]http://www.w3.org/2011/07/27-svg-minutes.html#action10]
<trackbot> Created ACTION-3081 - Work with charles pritchard to
propose a canvas function that uses svg paths [on Tab Atkins Jr. -
due 2011-08-03].
CM: point 6: toDataURL and toBlob
... not sure if it meant to generate a png
DS: yes, that's what I meant
DJ: toDataURL takes a param for what you want back
DS: the one i'm most interested in is the rasters
CM: would have the same security concerns as drawing svg to a canvas
DS: there are ways around that
CP: 6 and 7 have the same concerns
vhardy_: anne, would it make sense to add capabilty to canvas to
draw a string?
anne: what do you mean with string?
vhardy_: a serialized document
TabAtkins__: you could use a crippled security context
... like for img elements
anne: it seems better to pass the element
vhardy_: i have a snippet of svg i want to draw in canvas
... don't want ot have to base64 encode it
anne: two separate things, you could use innerHTML
... vincent said it was not related to tainting?
CM: the only reaosn why your'e serailing is to be able t get it into
the canvas
anne: if it's a separate file you could aslo use an iframe
CM: so have someone investigate how to get toDatauRL and pixels back
... and the security concerns
anne: so for foreignObject that would taint the svg
ISSUE: Investigate how to get pixel data out of svg subtrees
securely
<trackbot> Created ISSUE-2419 - Investigate how to get pixel data
out of svg subtrees securely ; please complete additional details at
[35]http://www.w3.org/Graphics/SVG/WG/track/issues/2419/edit .
[35] http://www.w3.org/Graphics/SVG/WG/track/issues/2419/edit
<scribe> ACTION: heycam to investigate ISSUE-2419 [recorded in
[36]http://www.w3.org/2011/07/27-svg-minutes.html#action11]
<trackbot> Created ACTION-3082 - Investigate ISSUE-2419 [on Cameron
McCormack - due 2011-08-03].
CM: 8. New API to construct svg trees
CP: would be nice to have ArrayBuffer in svg and canvas API's, very
efficient for gpus
... avoids string serialinzg data
... necessary for drawing fast
<scribe> ACTION: doug to propose a new API for constructing svg
trees [recorded in
[37]http://www.w3.org/2011/07/27-svg-minutes.html#action12]
<trackbot> Created ACTION-3083 - Propose a new API for constructing
svg trees [on Doug Schepers - due 2011-08-03].
--- 15 minute break
SVG Accessibility
<TabAtkins__> shepazu: Two aspects to this.
<TabAtkins__> shepazu: One, should we push for SVG being leverage
for Canvas accessibility?
<TabAtkins__> shepazu: Two, how can SVG be made more accessible?
<TabAtkins__> shepazu: I have a plan going forward for the latter.
<TabAtkins__> pritchard: In about 2009, people started asking for
a11y in canvas.
<TabAtkins__> pritchard: In both SVG and Canvas, shapes are used;
it's not text and a box model.
<TabAtkins__> pritchard: Richard Sch and I started looking into
this.
<TabAtkins__> pritchard: I found several issues by trying to
implement HTML forms in Canvas, and found many different things.
<TabAtkins__> pritchard: Then I started playing with shapes. If I
have a button shaped like a star, how can I tell the AT about that?
<TabAtkins__> pritchard: On the iphone, you can drag your finger
around and it can find bounding boxes and read them to you.
<TabAtkins__> pritchard: But triangles? Not so much.
<TabAtkins__> pritchard: So with ARIA you can specify the "role" of
something to an AT.
<TabAtkins__> pritchard: So, how does ARIA work with SVG and Canvas?
<TabAtkins__> pritchard: ARIA initially didn't take SVG into
account.
<TabAtkins__> pritchard: Though they'll do more work with this in
the future.
<TabAtkins__> pritchard: Canvas gets a lot of AT stuff for free with
the hidden subtree; it can contain buttons, frex.
<TabAtkins__> pritchard: [explains the canvas subtree]
<TabAtkins__> pritchard: [explains the ability to draw focus rings
based on whether a specified element in the subtree is focused]
<TabAtkins__> pritchard: So even if I'm drawing a custom focus ring,
I need to tell the system where on my canvas is being focused (so
the AT can help the user by zooming or highlighting or something
there)
<TabAtkins__> pritchard: The best part about having focus here is
that it's bound to an element, so you can some semantics out of that
element.
<TabAtkins__> shepazu: [draws a pie chart]
<TabAtkins__> s/pie chart/radial menu/
<TabAtkins__> shepazu: So in the canvas subtree it's just a list of
links, which correspond to the regions in the radial menu of the
Canvas.
<TabAtkins__> shepazu: So if you tab to the link, you'd either get
the link's box or the entire canvas or something as the focused
area, not the appropriate region of the menu. That's what
drawFocusRing is for here.
<TabAtkins__> heycam: In the pie chart it seems like each part is
focusable, but if there's a <select> in the subtree, you're not
really focusing the <option>s, but the <select> as a whole.
<TabAtkins__> pritchard: You can either link the focus-area to the
appropriate <option>, or do something different like a list of
links.
<TabAtkins__> pritchard: If you desire, though, you can take a list
of links and use ARIA to mark it up as a select with options,
semantically, and it's presented the same way to the AT.
<TabAtkins__> shepazu: While it hasn't been well-defined yet, it
should also be possible to use ARIA with SVG well. You could think
of a lot of SVG as "really pretty divs".
<TabAtkins__> vhardy: Can you disable the UA's normal rendering
here?
<TabAtkins__> TabAtkins__: You can pass a parameter to drawFocusRing
to tell it not to visually do anything, so you can then just stroke
the path afterwards.
<TabAtkins__> pritchard: [something about caret]
<TabAtkins__> [Doug is interested in exploring the idea of ARIA and
carets]
<TabAtkins__> heycam: If you're doing a custom widget in windows,
you can report the caret location, right?
<TabAtkins__> mattmay: Yes.
<TabAtkins__> heycam: So it seems like that's something you'd want
to do with canvas as well, right?
<TabAtkins__> TabAtkins__: Text-editing has a ton more complexity
than carets, so we generally just say you shouldn't do it yourself,
and let <textarea> or @contenteditable handle it.
<TabAtkins__> pritchard: So we proposed setCaretPosition
<TabAtkins__> pritchard: And Ian suggested ScrollPathIntoView
<TabAtkins__> pritchard: The semantics are a little weird; you don't
know that you're just emulating the functionality that moving the
caret does natively (always keeping itself in view).
<TabAtkins__> shepazu: So, let's not drill down this far into Canvas
a11y.
<TabAtkins__> pritchard: Another problem with canvas that SVG
doesn't have is that, if you're searching through the DOM, you don't
necessarily want to focus things.
<TabAtkins__> pritchard: So, for example, enumerating the selectable
elements so you can move through them. You need to know this
*before* focusing them.
<TabAtkins__> pritchard: So this is where "why not just use SVG"
really came in. SVG gets this for free - you know the geometry of
things before they're focused.
<TabAtkins__> pritchard: Canvas lacks the ability to talk about
active regions ahead of time.
<TabAtkins__> pritchard: SVG has an opposite problem - it has a ton
of paths, and we don't necessarily need all of them.
<TabAtkins__> heycam: Basically the set of things you want to report
are the same as the set of focusable things?
<TabAtkins__> pritchard: Basically, yeah.
<TabAtkins__> shepazu: In Tiny 1.2 we introduced a @focusable
attribute, which was meant to be for things like this.
<TabAtkins__> pritchard: [talk about using SVG and ARIA to create a
checkbox and lable]
<TabAtkins__> mattmay: [talk about the difference between "virtual
cursor" and "form" modes in ATs]
<TabAtkins__> ISSUE: Looks at @focusable in context of text and a11y
<trackbot> Created ISSUE-2420 - Looks at @focusable in context of
text and a11y ; please complete additional details at
[38]http://www.w3.org/Graphics/SVG/WG/track/issues/2420/edit .
[38] http://www.w3.org/Graphics/SVG/WG/track/issues/2420/edit
<TabAtkins__> mattmay: You should be able to set @focusable on text
elements, but most of the time users won't need to be reading that.
<TabAtkins__> heycam: The "virtual cursor" mode seems pretty
valuable to work more on too. In HTML you can just read through the
DOM linearly, but in SVG you might want to read along the lines in a
chart.
<TabAtkins__> pritchard: In ARIA you have aria-flow-to and
aria-owns, which let you specify the AT tree different from the DOM
tree. aria-live lets you specify an area that is active and may
change.
<TabAtkins__> pritchard: My main thing I found with SVG was that
it's not quite as hierarchical as HTML.
<TabAtkins__> heycam: aria-flow-to sounds pretty interesting to use
here too.
<TabAtkins__> mattmay: flow-to affects tab order, not reading order
(order of the virtual cursor).
<TabAtkins__> shepazu: I think that peppering your doc with ARIA is
a last resort, generally. It's good when we need it, but better if
we can make it work without it.
<TabAtkins__> shepazu: My "connectors" stuff was about that.
<TabAtkins__> pritchard: flow-to changes the reading order in some
circumstances.
<TabAtkins__> shepazu: What other things does canvas have for a11y?
<TabAtkins__> pritchard: Juts ARIA stuff.
<TabAtkins__> pritchard: You may want to use things for various
profiles. OpenClipArt is all very presentational documents, frex.
<TabAtkins__> pritchard: We've also recently proposed
setClickableRegion, which similarly lets you link a subtree element
with a canvas region and lets AT know what's clickable.
<TabAtkins__> pritchard: [gives an example of how you might want a
different path than the visual representation in SVG for
focusing/activating AT behavior]
<TabAtkins__> shepazu: Then I think Rich got into something weird
with hit testing.
<TabAtkins__> pritchard: Rich thought we could combine
setClickableRegion and hit-testing, such that the browser can
automatically route clicks around.
<TabAtkins__> [explanation of how that could work potentially]
<TabAtkins__> heycam: I don't know if this works well with <select>
- you'd need to map a region to an <option>, and then handle the
<select> value changing yourself.
<TabAtkins__> pritchard: Yes.
<TabAtkins__> heycam: So you'd have to listen to mousedown on the
particular element.
<TabAtkins__> shepazu: So I think on the surface it seems
reasonable, though it verges into a retained mode. You already have
a retained mode with the fallback as well.
<TabAtkins__> shepazu: But where does this end?
<TabAtkins__> pritchard: It seems like this is the end. Based on the
OS AT APIs so far, these fill in all the information necessary.
<TabAtkins__> pritchard: We have focus position, caret position, and
clickable regions. That's as far as all the ATs go anyway.
<TabAtkins__> heycam: These seem more reasonable than the
permathread suggests.
<TabAtkins__> pritchard: Well, one of the major objections was to
simply keep it difficult to do these in Canvas, so authors instead
go ahead and use "better" technologies like SVG.
<TabAtkins__> shepazu: The final part of the story imo is that two
browser vendors have come forward and said "no".
<TabAtkins__> pritchard: We're working on this. We've been talking
with Apple, and with Jonas Sicking from Moz.
<TabAtkins__> pritchard: And MS has certain high AT standards in
their products that make them potentially interested.
<TabAtkins__> pritchard: Also I've been working with Apple and
Voiceover to fix their handling of Canvas.
<TabAtkins__> shepazu: So I think what you wanted in SVG was a
method to bind an element to the path.
<TabAtkins__> shepazu: And my suggestion was, why not just have an
SVG element (with ARIA) that simply carries the semantics.
<TabAtkins__> shepazu: The other is the above, but drawing the SVG
shape into the canvas.
<TabAtkins__> shepazu: So why not use SVG?
<TabAtkins__> pritchard: Cost. It's expensive to serialize paths.
<TabAtkins__> TabAtkins__: He suggested drawing with SVG instead,
with a linkage to the represented element.
<TabAtkins__> pritchard: That works, but it doesn't fix canvas
accessibliity.
<TabAtkins__> shepazu: No, it fixes platform image accessibility.
<TabAtkins__> shepazu: So if we draw SVG into a canvas we seem to
lose a lot of the good retained-mode parts of SVG. So what *would*
it mean to combine these?
<TabAtkins__> shepazu: So if you animate the pie chart in canvas,
don't you also have to update the clickable region?
<TabAtkins__> pritchard: Yes, but given the shape of the proposed
APIs, you'd just reuse the path that you're using to draw anyway.
<TabAtkins__> ISSUE: Contact platform a11y api people about
non-rectangular path regions.
<trackbot> Created ISSUE-2421 - Contact platform a11y api people
about non-rectangular path regions. ; please complete additional
details at
[39]http://www.w3.org/Graphics/SVG/WG/track/issues/2421/edit .
[39] http://www.w3.org/Graphics/SVG/WG/track/issues/2421/edit
<TabAtkins__> mattmay: Adobe likes non-rectangular paths.
<TabAtkins__> pritchard: If you put <canvas> into SVG, and you put a
button into there, how do you use the subtree in SVG?
<TabAtkins__> shepazu: Increasingly, SVG is being used in HTML too.
<TabAtkins__> TabAtkins__: My opinion on the matters: First,
anything to do with text editting should, imo, never be done in
Canvas. There are massive complexities in text that the platform
solves for you, and which most authors will not get right.
<TabAtkins__> Second, I see canvas as being very useful for (1)
scripted images, (2) games, and (3) rendering of isolated controls
(like fancy checkboxes). When you start rendering entire forms or
entire UIs in canvas, you're generally doing something wrong, and
should instead be using what the platform provides (that is, do your
overall UI in HTML).
<TabAtkins__> pritchard: Great internal policy, but in the web,
there are already many cases where people use canvas for
inappropriate things.
<TabAtkins__> pritchard: Also, some of these subjects are relevant
directly to SVG.
<TabAtkins__> pritchard: SVG is widely currently used in static
documents, but for interactive documents you probably want to plug
into the AT APIs surrounding forms.
<TabAtkins__> pritchard: Like describing a region of a radial manu
as a button.
<TabAtkins__> s/manu/menu/
<TabAtkins__> shepazu: I've done that with SVG and buttons already.
<TabAtkins__> pritchard: And we'll be reviewing more parts of
ARIA/etc to see what's missing in SVG.
<TabAtkins__> shepazu: So you say you're making progress with the
vendors; seems there's not too much for us to do?
<TabAtkins__> heycam: I thought a wide variety of diagrams and
infographics would probably require a different set of ARIA
semantics than what is already exposed based on HTML.
<TabAtkins__> shepazu: Yes, and that's what I want to talk about.
<TabAtkins__> shepazu: There's two things I plan to do in SVG2.
<TabAtkins__> shepazu: One is, make an ontology of infographics
(document navigation paths, etc)
<TabAtkins__> shepazu: Assessment techniques one uses when looking
at infographics, and annotate them.
<TabAtkins__> pritchard: And for things like pie charts, <table>s
are a great retained version of data that could potentially work
here with SVG.
<TabAtkins__> mattmay: SAS has a demo involving tactile feedback of
interactive graphics.
<shepazu> [40]http://schepers.cc/svg/accessibility/
[40] http://schepers.cc/svg/accessibility/
<TabAtkins__> shepazu: This example shows how you could use SVG to
create a tabular appearance, annotating with ARIA to make it exposed
as a table.
<TabAtkins__> shepazu: (There's a problem that ARIA doesn't expose
role=column. WAI-ARIA rejected my feedback to add that earlier.)
<TabAtkins__> shepazu: One, setting up roles and attributes for
infographics (for SVg, canvas, flash, etc.)
<TabAtkins__> shepazu: Two, start talking to AT vendors about
expanding the platform APIs for a11y
<TabAtkins__> mattmay: I don't necessarily think that the native
APIs really need to be fixed. They're probably fine for what you
need to do.
<TabAtkins__> mattmay: I think your best bet is to produce a clean
DOM with good ARIA, and then file bugs yelling at them for not
following the spec.
<TabAtkins__> shepazu: That's basically my plan anyway.
<TabAtkins__> heycam: For things like Excel, how are charts exposed
to AT APIs? They must do something already.
<TabAtkins__> mattmay: Dunno for sure.
<TabAtkins__> mattmay: All of that work is custom between Office.
<TabAtkins__> mattmay: It's not a model I'd want to follow.
<TabAtkins__> mattmay: But if you create a model that would support
it, I'm sure they'd be glad to follow.
<shepazu> [41]http://www.w3.org/TR/html-aapi/
[41] http://www.w3.org/TR/html-aapi/
<TabAtkins__> shepazu: The second thing I want to do in SVG2 is
produce an analog of this guide for SVG.
<TabAtkins__> heycam: This is the default roles you get if you don't
use ARIA. We should definitely have this.
<TabAtkins__> shepazu: So those are the two things I want to do in
SVG2 for a11y.
<TabAtkins__> shepazu: I've already started on the API mapping.
<TabAtkins__> shepazu: Do we feel we need any kind of resolution on
the canvas api stuff?
<TabAtkins__> heycam: I think the kinds of things Charles proposed
isn't really needed in SVG.
<TabAtkins__> pritchard: Right - you already have most of this.
<TabAtkins__> heycam: But if you have canvas in SVG, whatever gets
decided for HTML would get handled just fine.
<TabAtkins__> heycam: I think we should maybe integrate editable
text with canvas.
<TabAtkins__> pritchard: [something about shape-wrap]
<TabAtkins__> mattmay: There's precedent for creating an
overlay/underlay of live areas. Like PDF.
<TabAtkins__> mattmay: The idea is that you may have a
@contenteditable rendered in SVg or Canvas or whatever. Your
subtree-equivalent control would just occupy the same space, but is
hiddne.
<TabAtkins__> mattmay: So selecting the text or whatever would map
down into the subtree.
<shepazu> here are some issues raised by Rich Schwerdtfeger on SVG
accessibility
[42]http://www.w3.org/Graphics/SVG/WG/wiki/Accessibility_Issues
[42] http://www.w3.org/Graphics/SVG/WG/wiki/Accessibility_Issues
Summary of Action Items
[NEW] ACTION: cabanier to define how to use <glyphRef>'s glyphRef
attribute to point to an openType glyph and make sure it works with
the different openType format variations. [recorded in
[43]http://www.w3.org/2011/07/27-svg-minutes.html#action01]
[NEW] ACTION: cabanier to work with vhardy and text experts on x/y
positioning and altGlyphDef and altGlyph. [recorded in
[44]http://www.w3.org/2011/07/27-svg-minutes.html#action02]
[NEW] ACTION: doug to propose a new API for constructing svg trees
[recorded in
[45]http://www.w3.org/2011/07/27-svg-minutes.html#action12]
[NEW] ACTION: heycam to come up with API proposal for exposing glyph
path data. [recorded in
[46]http://www.w3.org/2011/07/27-svg-minutes.html#action04]
[NEW] ACTION: heycam to contact Israel about path warping
information. [recorded in
[47]http://www.w3.org/2011/07/27-svg-minutes.html#action06]
[NEW] ACTION: heycam to contact Nathan Hurst about lib2geom for
information about path warping. [recorded in
[48]http://www.w3.org/2011/07/27-svg-minutes.html#action08]
[NEW] ACTION: heycam to file a bug on DOMCore to remind Anne about
the event move. [recorded in
[49]http://www.w3.org/2011/07/27-svg-minutes.html#action09]
[NEW] ACTION: heycam to investigate ISSUE-2419 [recorded in
[50]http://www.w3.org/2011/07/27-svg-minutes.html#action11]
[NEW] ACTION: heycan to contact Nathan Hurst about lib2geom for
information about path warping. [recorded in
[51]http://www.w3.org/2011/07/27-svg-minutes.html#action07]
[NEW] ACTION: shepazu to create a proposal for "Groovy Text", i.e.,
a solution for easily provide the graphical rendering of a piece of
text with SVG graphics. [recorded in
[52]http://www.w3.org/2011/07/27-svg-minutes.html#action03]
[NEW] ACTION: Tab to work with charles pritchard to propose a canvas
function that uses svg paths [recorded in
[53]http://www.w3.org/2011/07/27-svg-minutes.html#action10]
[NEW] ACTION: vhardy to reach out to Bob Hopgood for information
about path warping for text. [recorded in
[54]http://www.w3.org/2011/07/27-svg-minutes.html#action05]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [55]scribe.perl version 1.136
([56]CVS log)
$Date: 2011/07/28 00:49:31 $
_________________________________________________________
[55] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[56] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43
Check for newer version at [57]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[57] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/shape./shape)/
Succeeded: s/ some support for SVG fonts./ support altGlyph for SVG fon
ts, but not altGlyph for Opentype fonts AFAIK./
Succeeded: s/thought/though/
Succeeded: s/web/lib/
Succeeded: s/matter/manner/
Succeeded: s/'rotate'/'SVGRotate'/
Succeeded: s/the spec/the SVG spec/
FAILED: s/6. toDataURL/6. toDataURL and toBlob/
Succeeded: s/can/can get/
FAILED: s/pie chart/radial menu/
FAILED: s/manu/menu/
WARNING: No scribe lines found matching ScribeNick pattern: <Cameron> .
..
Found ScribeNick: vhardy
WARNING: No scribe lines found matching ScribeNick pattern: <vhardy> ..
.
Found ScribeNick: TabAtkins__
Found Scribe: Cameron
Found ScribeNick: heycam
Found ScribeNick: ed
ScribeNicks: vhardy, TabAtkins__, heycam, ed
WARNING: Replacing list of attendees.
Old list: +1.206.675.aaaa +33.9.53.77.aabb ChrisL tbah
New list: tbah ChrisL +1.206.675.aaaa
Default Present: +1.206.675.aaaa, tbah, ChrisL
Present: heycam brian ed cabanier cyril stearns_ tabatkins_ tbah shepaz
u Charles Pritchard
Agenda: [58]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Age
nda
[58] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda
WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth
Found Date: 27 Jul 2011
Guessing minutes URL: [59]http://www.w3.org/2011/07/27-svg-minutes.html
People with action items: cabanier doug heycam heycan shepazu tab vhard
y
[59] http://www.w3.org/2011/07/27-svg-minutes.html
End of [60]scribe.perl diagnostic output]
[60] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
--
Cameron McCormack ≝ http://mcc.id.au/
Received on Friday, 29 July 2011 00:43:33 UTC