W3C home > Mailing lists > Public > public-svg-wg@w3.org > July to September 2011

minutes, SVG WG Seattle F2F 2011 day 1

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
Message-ID: <20110729004236.GA28045@wok.mcc.id.au>
The HTML minutes for the Seattle F2F day 1 are at:


but have unfortunately been merged with day 1’s minutes.  Below is the
text version of just day 1.


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

                               - DRAFT -

                   SVG Working Group Teleconference

27 Jul 2011


      [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


          heycam, brian, ed, cabanier, cyril, stearns_, tabatkins_,
          tbah, shepazu, Charles, Pritchard




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

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

   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

   <vhardy_> <altGlyphDef id="a"><glyphRef glyph-name="..." />

   <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

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


     [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

   <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

   <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

   <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

   <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

   <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

   <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

   <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

   <vhardy_> ACTION: cabanier to work with vhardy and text experts on
   x/y positioning and altGlyphDef and altGlyph. [recorded in

   <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

   <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

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

   <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

   <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

   <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

   <ChrisL> directly, and furthermore, subdivision and degree reduction

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

   tbah: Yes.

   heycam: I'm not sure what we want to get out of this discussion

   <vhardy_> Converting Bezier curves to NURBS:

     [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

   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

   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

   [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
   ... Like something that just takes a font name and a character, or

   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

   <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

   <trackbot> Created ACTION-3077 - Reach out to Bob Hopgood for
   information about path warping for text. [on Vincent Hardy - due

   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

   <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

   <scribe> ACTION: heycan to contact Nathan Hurst about lib2geom for
   information about path warping. [recorded in

   <trackbot> Sorry, couldn't find user - heycan

   <scribe> ACTION: heycam to contact Nathan Hurst about lib2geom for
   information about path warping. [recorded in

   <trackbot> Created ACTION-3079 - Contact Nathan Hurst about lib2geom
   for information about path warping. [on Cameron McCormack - due

   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
   ... Basically that would add all of the on* attributes to the svg
   ... 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
   ... 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

   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

   <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

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

   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
   ... you couldn't as an author determine what the end user's desire
   ... 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

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

   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

   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


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

   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

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

   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

   CP: css transitions has transitionend/start

   DJ: by default when you draw something in svg you get optimal
   ... except for a raster image, which has to be scaled
   ... wiuth canvas you can improve the visual output depending on

   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

   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


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


     [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”,

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

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

   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

   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

   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

   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

   <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

   <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

   <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

   <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

   <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

   <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

   <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

   <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

   <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

   <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

   <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

   <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

   <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

   <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

   <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

   <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

   <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

   <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

     [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
   [NEW] ACTION: cabanier to work with vhardy and text experts on x/y
   positioning and altGlyphDef and altGlyph. [recorded in
   [NEW] ACTION: doug to propose a new API for constructing svg trees
   [recorded in
   [NEW] ACTION: heycam to come up with API proposal for exposing glyph
   path data. [recorded in
   [NEW] ACTION: heycam to contact Israel about path warping
   information. [recorded in
   [NEW] ACTION: heycam to contact Nathan Hurst about lib2geom for
   information about path warping. [recorded in
   [NEW] ACTION: heycam to file a bug on DOMCore to remind Anne about
   the event move. [recorded in
   [NEW] ACTION: heycam to investigate ISSUE-2419 [recorded in
   [NEW] ACTION: heycan to contact Nathan Hurst about lib2geom for
   information about path warping. [recorded in
   [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
   [NEW] ACTION: Tab to work with charles pritchard to propose a canvas
   function that uses svg paths [recorded in
   [NEW] ACTION: vhardy to reach out to Bob Hopgood for information
   about path warping for text. [recorded in

   [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

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

     [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

     [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

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