W3C home > Mailing lists > Public > public-svg-wg@w3.org > April to June 2009

Minutes, Wednesday 8 April 2009 telcon

From: Cameron McCormack <cam@mcc.id.au>
Date: Wed, 8 Apr 2009 17:59:19 +1000
To: public-svg-wg@w3.org
Message-ID: <20090408075919.GA29358@arc.mcc.id.au>


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

                               - DRAFT -

                   SVG Working Group Teleconference

08 Apr 2009


      [2] http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0016.html

   See also: [3]IRC log

      [3] http://www.w3.org/2009/04/08-svg-irc


          [IPcaller], anthony, heycam, Doug_Schepers, ed, ChrisL




     * [4]Topics
         1. [5]SVG Integration module
         2. [6]Progress on 1.1 second edition
         3. [7]Color module
         4. [8]Transforms module
     * [9]Summary of Action Items

   <trackbot> Date: 08 April 2009

   <scribe> Scribe: Cameron

   <scribe> ScribeNick: heycam

SVG Integration module

   DS: not much to show yet, thought i'd get something going


     [10] http://dev.w3.org/SVG/modules/integration/SVGIntegration.html

   DS: i'm going to start by integrating that embedding document i once

   ED: sounds good

   <shepazu> [11]http://www.schepers.cc/svg/blendups/embedding.html

     [11] http://www.schepers.cc/svg/blendups/embedding.html

   DS: also how to extend svg, starting with what we had in 1.2T
   ... i'll put in whatever hooks cameron needs for doing the tables of
   attributes and elements

   CL: did how we do attributes change recently?

   CM: still experimenting, once the build scripts are finalised i'll
   mail the list with details


     [12] http://www.w3.org/TR/SVGTiny12/conform.html#ConformingSVGEncoding

   [doug reads out D.7]

   CL: nice that that wording is in there

   DS: does the current svg in html proposal violate that?

   CL: the intention would be not to violate that, not sure about the
   current proposal

   DS: i don't think it does violate it
   ... as to what hooks to put into the spec to generate the tables of
   attributes etc., i'll leave it to cameron to work out what's best
   ... a question about svg in an <img> element
   ... what if you have svg referenced from html <img>
   ... <object> has .contentDocument

   <ChrisL> script in svg wich is in an image, or script somewhere else
   getting at svg in an image through script?

   DS: does <img>?
   ... i'm kind of thinking that we might say no

   ED: i don't think that would work, at least in opera 10

   DS: should it?

   ED: we made a decision not to allow it. it's just whether you put
   the interface on that <img> element. but we chose not to.
   ... since it doesn't allow scripting inside the referenced document,
   that's why we chose to leave out the interface

   CL: but why prevent accessing the document from outside?

   DS: i think from a security and efficient viewpoint, it might be
   better not to get at the contents at all

   ED: my question is, what would happen if you inserted a <script>
   inside the referenced document?

   CL: i'm talking about getting to the document at all. whether it's
   readonly or read-write is a separate question.
   ... maybe if it comes from a different host you wouldn't be allowed
   to, but that's just a standard cross site restriction, nothing to do
   with it being an <img>

   DS: if you reference using <object>, <embed>, etc., you already have
   that capability
   ... we're talking about one particular embedding scenario that walls
   it off more

   CM: perhaps you specifically want to disallow access from the
   containing html (and to disallow script running inside the svg),
   hence you'd use <img>

   DS: the canvas api operates on <canvas> and not <img>, right?

   ED: yes

   DS: so you wouldn't be able to modify the image referenced by <img>
   but not an svg referenced by that element (i.e., there wouldn't be
   that inconsistency)
   ... so with <img> you can't access the DOM from the outside

   CL: if you can't access the DOM from inside or the outside, do you
   need to build a DOM at all?

   DS: text

   CL: might be an accessibility concern if an AT can't access the text
   as a DOM

   CM: perhaps the AT uses privileged methods to get at the DOM, not
   just standard script in the web page

   DS: in the html wg we're discussing accessibility of canvas
   ... for the purposes of svg in <img>, there might be an api (mini
   dom?) hanging off the <img> that exposes the text information and
   nothing else

   ED: i would prefer in that case to have specialised access for ATs
   ... i started to look at this; we still have the DOM for SVGs
   referenced by <img>, so in our source code we can access it
   ... but you're just prevented from accessing it in script
   ... i don't think it'd be a problem to expose that information to
   ... i'd have to check how we integrate with ATs, though, but i don't
   think it'd be a problem
   ... i agree that it'd be useful for such tools to be able to access
   that information inside

   [discussions about getting AT vendors involved in helping with SVG
   accessibility speccing]

   <scribe> ACTION: Doug to contact AT vendors about SVG accessibility
   [recorded in

   <trackbot> Created ACTION-2515 - Contact AT vendors about SVG
   accessibility [on Doug Schepers - due 2009-04-15].

   DS: i wonder if much of the challenge for them is in drilling in to
   embedded DOMs (e.g., via <object>)

   [discussions of appropriate title/desc]

   DS: this'd be for the svg semantics spec (which would deal with
   aria, too)

   ED: another thing for the integration spec would be css fonts and
   web fonts, whether or not scripts should run in referenced svg fonts

   CL: if an svg has an @font-face, which points back to the same
   document; if that document has script, should it run?
   ... how about if they're in different documents?
   ... not sure where the line lies

   DS: some of these trickier decisions fall out from higher level

   No telcons next week.

Progress on 1.1 second edition

   ED: what's the status on the scripts?


     [14] http://mcc.id.au/temp/struct.html

   CM: changes since last update are the interfaces at the bottom of


     [15] http://dev.w3.org/SVG/profiles/1.1F2/master/svg.idl

   CM: the idl file is using javadoc-style comments now

   [people are happy with javadoc-style comments in the idl]

   <ChrisL> (discussion about svg)

   CL: what are we doing about rng?

   CM: should we still include the dtd in the appendix?

   CL: i guess we should; we should add some wording about problems
   with dtds, non-namespace-aware, etc.
   ... we should fix the non-deterministic problems and other things
   that were identified
   ... add wording to say that if you want to validate including rdf
   etc., then suggest using rng

   CM: we might want to rewrite some of the text in extend.html

   CL: where's the rng coming from?
   ... i think it would be better to start with the 1.2T rng and
   add/remove things

   ED: There's an rng for 1.2 full, not sure how correct it is

   CL: i don't think it's quite correct
   ... the other option is to take the dtd and convert it to rng
   ... so i think it would be best to start from 1.2T and add the 1.1

   <ChrisL> a trang conversion is probably not going to be very

   <scribe> ACTION: Chris to make RNG for 1.1 based on the 1.2T one
   [recorded in

   <trackbot> Created ACTION-2516 - Make RNG for 1.1 based on the 1.2T
   one [on Chris Lilley - due 2009-04-15].

   CM: there are still a few outstanding 1.1 errata that need working

   ED: it would be useful if people could finish those off, and talk
   about them after next week

Color module

   CL: there has been a question asked of me about why we support
   ... my answer was because the ICC spec has rendering intent
   ... people have pushed back and said that it's probably going away
   from the next ICC spec
   ... and many profiles have only a single table
   ... we have to say what happens if the user requests a rendering
   intent and there isn't a table for it
   ... i will be discussing with the openicc people at libre graphics
   some of the options for that, but that's a new issue
   ... at minimum it needs to go into the spec as an issue
   ... hopefully i can add some text to describe fallback

   AG: i can also talk to some people here to see what fallback to use
   ... i got a group of people together within cisra to discuss the
   color module, and from that review we felt that it wasn't targetting
   anything specific
   ... i went back and talked to some other cisra people, and we
   figured that with the current features that are in the color module,
   it's best targetted towards office printing
   ... not sure if that's the original intent of the spec

   CL: it should cover that, but i don't think it should be specific to

   AG: it does cover everything from regular web authoring up to office
   ... it's probably not sufficient for high end printing
   ... we should specify what areas we are intending to target

   CL: it would be helpful if you could let us know what is missing for
   high end printing
   ... not necessarily to put it into the spec, but just to know

   AG: in terms of the current spec being useful for office printing,
   one feature we think is missing is "preserve black"
   ... where you'd be able to say that RGB black (or CMYK black) would
   be preserved as black at the printer

   CL: is that different from black point compensation?
   ... if i have rgb(0.0001, 0, 0) is that also black?
   ... black point preservation says what really is black, given the

   AG: this is basically for text. if you specify some text as black,
   you'd want to preserve that so that at the end when printing, it
   doesn't use CMY to make up the colour. but uses the black ink

   CL: so you're using black as a spot colour, and saying not to
   separate it

   AG: yes
   ... the other area where this is useful is for fonts
   ... because if you pull out a font that's a bitmap, you could say
   preserve black on the bitmap so that they don't get colour converted
   ... otherwise you still might get a browny colour out at the end for
   your text

   CL: but you still want it to be optional?
   ... e.g. if you're matching up with other black parts of the image

   AG: haven't thought that far ahead
   ... if you have line art between the text, you might want to use
   preserve black on the line art too
   ... some of these guys would be happy to join a call to discuss
   things that are missing
   ... we're still doing some more review on it, we'll get comments in
   in a week or two

   CL: i started looking at a global default for icc profiles
   ... it's fairly easy to do, not sure it gains you much

   AG: the other thing is that icc profiles are referenced by name. is
   it possible to reference them by id?

   CL: what does the id look like in the spec?
   ... if there's a big complicated string, we'd only want to use that
   once in a document


     [17] http://dev.w3.org/SVG/modules/color/master/SVGColor.html

   <ChrisL> not *that* spec :)

   <ChrisL> [18]http://www.color.org/ICC1V42.pdf

     [18] http://www.color.org/ICC1V42.pdf

   CL: the profile's unique id is an MD5 hash
   ... using that everywhere in a document wouldn't be nice

   <ChrisL> ok so the short readable name instgead of a n MD5
   unreadable thing is much nicer

   AG: 'local' is optional too

Transforms module

   AG: i was reading through the conformance criteria section in 1.2T

   <anthony> "If using features defined in SVG Full, an extension must
   not redefine the syntax of the syntax of those features."

   <anthony> "An extension must not redefine the semantics of any
   existing SVG element or attribute."

   AG: we'd need to use unique names, we can't redefine semantics of
   existing attribute names

   <ChrisL> (found the unique name thing - its section 7.2.18 Profile
   ID field (Bytes 84 to 99))


     [19] http://www.w3.org/TR/2009/WD-SVG-Transforms-20090320/#transform-list-extensions

   CM: i assume it's more for 3rd party extensions rather than
   restricting how the WG can extend the language

   AG: i'd like to start discussing some of the issues that were raised

   <anthony> ISSUE-2233?

   <trackbot> ISSUE-2233 -- adopt the syntax for CSS Transforms --

   <trackbot> [20]http://www.w3.org/Graphics/SVG/WG/track/issues/2233

     [20] http://www.w3.org/Graphics/SVG/WG/track/issues/2233

   AG: here dino asks why we dropped translateX/Y/Z etc.
   ... there's no real cost in having them in there, is it worth
   dropping them or keeping them?

   DS: i don't think it makes a big deal either way
   ... i think i was the one who originally raised the issue about
   adding too many transform items, but if there's a plausible story
   for them making it easier for authors, i'm all for it

   CM: the cognitive cost of having both translate(5) and translateX(5)
   doing the same thing probably isn't too great

   JW: my concern was about implementation strategies and optimising
   memory usage
   ... rather than having 16 values for some of the transforms you
   could cut it down to 1 or 2 quite often
   ... there's probably enough in there that implementations would have
   to deal with that complexity anyway, so perhaps it's not a concern

   CM: do implementations keep around only a single value for
   transform="scale(4)" at the moment, rather than storing all 6 values
   for 2d transforms?

   JW: the moz code at the moment stores the full matrices

   AG: i'd imagine a lot of transform pipelines would be like that

   JW: was thinking of implementing it with an operator overload kind
   of thing, with classes for the different types
   ... but that's probably a bad strategy anyway ;)

   AG: if you do have translateX/Y/Z, do we keep the current
   translate() transform item as is?

   <anthony> translate(<tx> [<ty> [<tz>]])

   AG: would we still allow translate() to do a 3d translate?

   CM: in the css proposal do they only allow two parameters to

   AG: yes, and have an additional translate3d()

   CM: maybe they did that to avoid trampling on existing svg transform

   AG: they have no optional components for translate3d(), but keep
   translate() the same as svg's

   DS: we should have a call with dino to discuss these instead of
   guessing at intentions

   <scribe> ACTION: Anthony to mail dino CCing public-fx to get him to
   join an SVG call to discuss transforms [recorded in

   <trackbot> Created ACTION-2517 - Mail dino CCing public-fx to get
   him to join an SVG call to discuss transforms [on Anthony Grasso -
   due 2009-04-15].

   <shepazu> public-fx

Summary of Action Items

   [NEW] ACTION: Anthony to mail dino CCing public-fx to get him to
   join an SVG call to discuss transforms [recorded in
   [NEW] ACTION: Chris to make RNG for 1.1 based on the 1.2T one
   [recorded in
   [NEW] ACTION: Doug to contact AT vendors about SVG accessibility
   [recorded in

   [End of minutes]

Cameron McCormack ≝ http://mcc.id.au/
Received on Wednesday, 8 April 2009 08:00:10 UTC

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