SVG Working Group Teleconference -- 22 Apr 2009

<trackbot> Date: 22 April 2009

<jwatt> yikes

<jwatt> (probably)

<scribe> Scribe: anthony

SVG Color

CL: I sent in some notes

<ed> 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> 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 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> http://lists.w3.org/Archives/Public/public-svg-print/2008Feb/0005.html

CL: but perceptual is harder
... to test

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> 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 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> 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> http://www.webmasterworld.com/forum21/11870.htm

Favicon

ED: I allowed Opera to use SVG for Favicons

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

DS: so I could use that here

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

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

Parameters

<shepazu> 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> http://www.w3.org/Graphics/SVG/WG/track/issues/2265

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

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

- DRAFT -

SVG Working Group Teleconference

22 Apr 2009

Attendees

Contents