See also: IRC log
<trackbot> Date: 22 April 2009
<jwatt> yikes
<jwatt> (probably)
<scribe> Scribe: anthony
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
<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
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].
<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
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
<ChrisL> <use role="shortcut icon" xlink:href="#myFav" ....>
DS: so I could use that here
<ed> <xhtml:link rel="shortcut icon" href="#myFav"/>
<ChrisL> 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
<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
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at 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: http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0055.html Found Date: 22 Apr 2009 Guessing minutes URL: http://www.w3.org/2009/04/22-svg-minutes.html People with action items: cameron chris[End of scribe.perl diagnostic output]