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

Minutes, Wednesday April 22, 2009

From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
Date: Wed, 22 Apr 2009 21:02:44 +1000
Message-ID: <49EEF954.8090607@cisra.canon.com.au>
To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>

http://www.w3.org/2009/04/22-svg-minutes.html

---

    [1]W3C

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

                                - DRAFT -

                    SVG Working Group Teleconference

22 Apr 2009

    [2]Agenda

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

    See also: [3]IRC log

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

Attendees

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

    Regrets
    Chair
           Erik

    Scribe
           anthony

Contents

      * [4]Topics
          1. [5]SVG Color
          2. [6]conformance
          3. [7]SVG Compositing
          4. [8]SVG Integration
          5. [9]Favicon
          6. [10]Parameters
      * [11]Summary of Action Items
      _________________________________________________________



    <trackbot> Date: 22 April 2009

    <jwatt> yikes

    <jwatt> (probably)

    <scribe> Scribe: anthony

SVG Color

    CL: I sent in some notes

    <ed>
    [12]http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/005
    7.html

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

    CL: First thing
    ... was case insensitivity
    ... DS had complained that there was mixed casing
    ... AG and I explained that's how it should be specified in the
    color world
    ... I tested the mixed case RGB

    <ChrisL> firefox 3.1 case-insensitive

    <ChrisL> opera 10a case-sensitive

    <ChrisL> safari 4b (crash!)

    <ChrisL> batik 1.7 case-insensitive

    <ChrisL> asv3 allows rgb or RGB but not mixed case

    CL: Those are my results
    ... Need someone to test a different build of Safari
    ... Mixed case is not allowed in ASV3
    ... my Corel viewer fails to run

    DS: Did you test Renesis?

    CL: No
    ... I'm trying to figure out if I should go to case insensitive

    ED: In Opera we are case sensitive for anything that's an attribute
    ... it might be possible to change it

    JW: For Mozilla, presentation attributes are placed to the style
    system
    ... which is why they are case insensitive

    CL: Presumably you'd be arguing for case insensitivity because
    that's the way you do it?

    JW: Depends if it's easy to make it that way or not
    ... don't really have a strong opinion on this

    CL: Sounds like we have some flexibility
    ... I remember Doug's comment

    CM: For the general issue I'd be in favor of having presentation
    attributes case insensitive in general

    CL: I guess it'd be ok if it would be case insensitive
    ... I attached a test in my email

    ED: I can test it in Safari
    ... Same color everywhere

    CL: Safari is case insensitive

    AG: I think it would be ok have case insensitive values, but have
    the correct/preferred syntax in the spec

    <heycam> [13]http://www.w3.org/TR/SVG11/styling.html#CaseSensitivity

      [13] http://www.w3.org/TR/SVG11/styling.html#CaseSensitivity

    CL: Opera allows lower case in the color key names
    ... and mixed case

    <ChrisL> batik allows upper case and mixed cASe in color names

    CM: We can just change RGB in ICC for 1.1

    <scribe> ACTION: Chris to Add an item to the F1.1 errata that allows
    case insensitivity for the 'RGB' value when painting [recorded in
    [14]http://www.w3.org/2009/04/22-svg-minutes.html#action01]

    <trackbot> Created ACTION-2525 - Add an item to the F1.1 errata that
    allows case insensitivity for the 'RGB' value when painting [on
    Chris Lilley - due 2009-04-29].

    CL: The next question I had was a bout number format in ICC

    <ChrisL> number format in icc(name, number, bumber....)

    CL: we need to discuss what number format we want
    ... because 1.1 only allows a float
    ... For attribute values that are not properties scientific notation
    is allowed
    ... I haven't done any tests on what implementations do
    ... but I should

    CM: It is unlikely that the numbers would require scientific
    notation because they are so small
    ... each color profile defines a standard range?

    CL: I don't know
    ... some of them allow negative colors to express out of gamut
    colours

    <ChrisL> fairly sure that some allow > 1.0 for headroom; believe
    trhat some cms allow negative values and others clip

    CM: I think 0 to 1 makes more sense

    CL: Which would be compatible with what 1.1 says
    ... values greater than 1 or less than 0 would be out of the profile
    gamut but no necessarily out of the target gamut
    ... I'd be fine with that

    RESOLUTION: A float in the range 0 to 1 like SVG 1.1 and no
    Scientific notation

conformance

    <ChrisL> - unconformant

    <ChrisL> - uses fallback colour, ignores profile in tagged
    images(SVG 1.1/1.2T, but not this spec)

    <ChrisL> - tagged image conformant

    <ChrisL> - uses fallback colour, honors profile in tagged images

    <ChrisL> - fully conformant

    <ChrisL> - uses icc and device colors in preference to fallback
    colour, honors profile in tagged images

    CL: I'd like to have two conformance levels
    ... one is that it doesn't do the color spec
    ... always falls back
    ... the next one would be that
    ... it falls back but does honor the profile in tagged images
    ... FireFox does that already according to their release notes
    ... What does Opera do in terms of color profiles?

    ED: I don't think it does anything useful with them at the moment
    ... I think that might be something we implement

    CL: The other level of conformance is it does everything
    ... It's easier to decide to implement a spec if you already half
    pass. More so for encouragement

    RESOLUTION: There will be two conformance levels in the Color
    specification

    CL: Rendering intents
    ... we got some text from HP
    ... the text would fit ok, in the Primer
    ... it's not exactly specification text
    ... but is seems that, relative and absolute colormeric
    ... is testable

    <ChrisL>
    [15]http://lists.w3.org/Archives/Public/public-svg-print/2008Feb/000
    5.html

      [15] http://lists.w3.org/Archives/Public/public-svg-print/2008Feb/0005.html

    CL: but perceptual is harder
    ... to test

    [16]http://www.svgopen.org/2007/papers/PublishingAndPrintingWithSVG/
    index.html#S8.3.2

      [16] 
http://www.svgopen.org/2007/papers/PublishingAndPrintingWithSVG/index.html#S8.3.2

    scribe: We might be able to do some tests in the test suite
    ... apparently many profiles only include a single rendering intent
    type
    ... the specification needs to specify what to do in that case

    ED: We should probably take this to email

SVG Compositing

    ED: Anything to report

    AG: I think it's ready to publish

    <ChrisL> [17]http://dev.w3.org/SVG/modules/compositing/master/

      [17] http://dev.w3.org/SVG/modules/compositing/master/

    <ChrisL> please ensure that normative and informative references are
    called out separately

    <ed> needs to run master2publish, doesn't have a publish subdir

    <scribe> ACTION: Cameron to Get the master2publish script working
    for the modules [recorded in
    [18]http://www.w3.org/2009/04/22-svg-minutes.html#action02]

    <trackbot> Created ACTION-2526 - Get the master2publish script
    working for the modules [on Cameron McCormack - due 2009-04-29].

SVG Integration

    <shepazu>
    [19]http://dev.w3.org/SVG/modules/integration/SVGIntegration.html

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

    DS: So far I don't have much on it
    ... I basically took the embedding document and I gave them each a
    set of feature definitions
    ... I don't know if we should put something about CSS in there or
    not
    ... do you think that would be affected?
    ... I think it's orthogonal

    <shepazu> Feature Definitions: declarative animation, external
    reference, link traversal, script execution, interaction

    DS: There is something in HTML5 and you have an iFrame and set it to
    seamless
    ... it will inherit the CSS from the parent document
    ... I should probably reference that
    ... Each of these things
    ... which what I'm calling feature definitions
    ... I should put in the feature stings for all of these
    ... if you look through the section
    ... I give a definition for what the feature is
    ... and I give a table
    ... and a little explanation of it
    ... I have a bunch of referencing mode
    ... and I talk about how each feature applies
    ... That's are the most complete section I have
    ... there other sections to come
    ... I slightly re-worked my original image
    ... I took sections out of SVG Tiny 1.2 or SVG 1.1 as appropriate
    ... to specify how to make extensions to SVG
    ... I intend on talking about foreign name spaces
    ... I also talk about encoding
    ... XML and non-XML
    ... Sections 5 and 6 is where I intend on putting the list of
    element definitions
    ... I'll have a table which will have an element name
    ... it will have pointers to either SVG 1.1 or SVG Tiny 1.2
    ... to the definitions of the elements
    ... and hopefully we will have a list of attributes that can go on
    the element
    ... I will have the same thing for attributes

    CM: So will this be the Union of the specs or the modules?

    DS: This will point to any relevant spec

    CM: And the intention that this is a place that you can go to

    CL: What about when we have modules that are not in Rec?

    DS: If this goes to Recommendation, we continuously publish an
    errata for this
    ... it would be multiple editions

    CL: Wouldn't really be an errata

    DS: I plan on this being part of the Core for SVG 2.0
    ... I've also been looking at CDF to see what their strategy is
    ... There are some parameters that are defined in CDF that have to
    do with SVG like whether animation activates
    ... that really should be defined in SVG
    ... and that might go into this integration spec

    <ChrisL> [20]http://www.webmasterworld.com/forum21/11870.htm

      [20] http://www.webmasterworld.com/forum21/11870.htm

Favicon

    ED: I allowed Opera to use SVG for Favicons

    [21]http://en.wikipedia.org/wiki/Favicon

      [21] http://en.wikipedia.org/wiki/Favicon

    CL: Lets assume you do something similar in SVG

    ED: What I was thinking of was including the icon in the document
    itself
    ... that would allow script access

    DS: I would say, it should be in secure animation mode
    ... that would allow animation
    ... just not external references

    <ChrisL> <use role="shortcut icon" xlink:href="#myFav" ....>

    DS: so I could use that here

    <ed> <xhtml:link rel="shortcut icon" href="#myFav"/>

    <ChrisL> [22]http://en.wikipedia.org/wiki/Favicon

      [22] http://en.wikipedia.org/wiki/Favicon

    <ChrisL> <svg role="accessible: no" ....>

    DS: they are only normative as so far as, they can be referenced
    normative

Parameters

    <shepazu> [23]http://www.schepers.cc/w3c/svg/params/ref.html

      [23] http://www.schepers.cc/w3c/svg/params/ref.html

    <ChrisL> issue-2265?

    <trackbot> ISSUE-2265 -- Consider adding a parameter referencing and
    defaulting mechanism -- RAISED

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

      [24] http://www.w3.org/Graphics/SVG/WG/track/issues/2265

    DS: I considered it
    ... and this is what I came up with

    <ChrisL> [25]http://www.w3.org/2005/10/howto-favicon

      [25] http://www.w3.org/2005/10/howto-favicon

    DS: I had the idea of being able to get at the parameters somehow
    ... most of this material would be in the primer
    ... for the button it works pretty well
    ... as you scroll down you see the parameters are used for position
    ... in my proposal any attribute could take a IRI with parameters
    ... the ref element has an 'id' a 'param' and a 'default' value
    ... so if you have no parameter at all
    ... that's what it will default to
    ... there are two open questions
    ... do you think making IRIs to work in this way would be a problem?

    CL: if an IRI already has mean that is similar to this how does it
    work?

    ED: What about the references that take a string at the moment?

    DS: I made it so that there could be a child default value
    ... this would allow <tref> to work with parameterisation
    ... the actual value could always be the child
    ... it matches the 'param' and sets it as it's child value
    ... and the way you reference a paint when the paint is a ref is
    that it takes the string value of the first child
    ... so get rid of default and the value would always be the child
    content

    CM: Would you have a modified DOM?

    DS: Haven't decided if it would modify the DOM or if it would be an
    animated value

    CM: I would find it strange if it mutated the document

    CL: When you look in the DOM do you see the modified or the
    original, or both
    ... security exploit?

    DS: So it can be set using a URI or a param element
    ... but if you supply the param element it overrides the URI string
    ... I came to the conclusion that what if I wanted someone to allow
    someone certain content. I pass someone a link to my goods with a
    certain URL
    ... and they override the URI to put their own links in
    ... so I think they are serving adds for me but they are serving
    adds for someone else
    ... I think the URI should override anything the params say

    CL: Do you have to de-reference anything?

    DS: No

    CL: If you had to de-reference it, I could give you a redirect 301

    DS: I thought about extending the Window or Default View interface
    to have a list of parameters
    ... no spec has a list of what the parameters are
    ... it would be a list of all the name value pairs

Summary of Action Items

    [NEW] ACTION: Cameron to Get the master2publish script working for
    the modules [recorded in
    [26]http://www.w3.org/2009/04/22-svg-minutes.html#action02]
    [NEW] ACTION: Chris to Add an item to the F1.1 errata that allows
    case insensitivity for the 'RGB' value when painting [recorded in
    [27]http://www.w3.org/2009/04/22-svg-minutes.html#action01]

    [End of minutes]
      _________________________________________________________


     Minutes formatted by David Booth's [28]scribe.perl version 1.135
     ([29]CVS log)
     $Date: 2009/04/22 08:27:15 $
      _________________________________________________________

      [28] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [29] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20
Check for newer version at [30]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/

      [30] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/worked/re-worked/
Found Scribe: anthony
Inferring ScribeNick: anthony
Default Present: Doug_Schepers, ed, heycam, [IPcaller], anthony, ChrisL
, jwatt
Present: Doug_Schepers ed heycam [IPcaller] anthony ChrisL jwatt
Agenda: [31]http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJu
n/0055.html
Found Date: 22 Apr 2009
Guessing minutes URL: [32]http://www.w3.org/2009/04/22-svg-minutes.html
People with action items: cameron chris

      [31] http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0055.html
      [32] http://www.w3.org/2009/04/22-svg-minutes.html

    End of [33]scribe.perl diagnostic output]

      [33] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Wednesday, 22 April 2009 11:03:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 22 April 2009 11:03:29 GMT