SVG Working Group Teleconference -- 20 Apr 2009

<trackbot> Date: 20 April 2009

<scribe> Scribe: anthony

1.2T list-of-string data type issue

<heycam> http://www.w3.org/mid/20090408054239.GA31922@bowman.infotech.monash.edu.au

CM: Pointing out there's a problem with list-of-strings

<ChrisL> need to disallow spaces in strings

CM: I have some overdue action in looking at this syntax
... I can solve this at the same time

CL: Do you say any character minus the following?
... for Unicode
... I need to have a string that doesn't have commas?
... is that what I wanted for colour profiles?

ED: I think so

<heycam> SpacelessAndCommalessValues ::= [^, ]*

ED: I'm not sure

<heycam> that's valid EBNF afaik

<ChrisL> cheers

ED: You probably want to escape those

DS: There are also certain values
... because we don't control them
... they have to be space separated

CL: We should probably disallow them
... instead of allowing them
... because if we move to separated lists, we don't what to end up with commas
... in the middle of a string

DS: We were moving towards having commas

CL: For Tiny we should tighten it to disallow commas in the middle of a string
... and we have semicolons?
... maybe we should disallow those?

DS: I think they are already disallowed?

<ChrisL> lists of lists

CL: I thought we had list of lists that used semicolons?

CM: List of points for a the animation attributes

CL: Any syntactic characters we shouldn't allow
... maybe it's too much

CM: So I'll look at cleaning that up when I get to the action
... The second part of the email asks about allow listing content types

CL: Some content types like video audio take the codec as the content type
... so we do need to be able to separate them

DS: Like semicolon

CM: When writing these media types without parameters you could probably do it without spaces

DS: I think people are likely to put a space in

<ChrisL> http://www.rfc-ref.org/RFC-TEXTS/2361/index.html WAVE and AVI Codec Registries

CM: I don't think it's likely we can put it all in one list type

DS: We should document these cases

AG: Wiki them

CM: So I'll look into that at the same time

CL: The examples in the RFC do include space
... but after the semicolon in all the examples

CM: They might allow all sorts of things inside quotes

<ChrisL> "Video codecs within the AVI Registry are identified by AVI Codec IDs.

<ChrisL> The AVI Codec ID value is a FourCC encoding. A FourCC is 32-bits long

<ChrisL> and represents a (case-sensitive) four-character (i.e., ASCII) code

<ChrisL> value. These codecs may be referenced within the IANA namespace as

<ChrisL> "video/vnd.avi; codec=XXX", where XXX represents a valid AVI Codec ID

<ChrisL> (e.g., the WAVE Format ID of "SCRN" is referenced within the IANA

<ChrisL> namespace by "video/vnd.avi; codec=SCRN").

<ChrisL> "

CL: I think that means it's for ASCII characters
... those ones

CM: Ok, I'll reply to the email and tell Peter we will deal with it in due course

Proposed test for markers: offset viewBox

<heycam> http://lists.w3.org/Archives/Public/www-svg/2009Apr/0051.html

CL: We should clearly test when the viewBox doesn't start with 0 0
... I have done markers like this
... which are centered on the origin
... but you have set the clipping

ED: I discussed this with JWatt
... and it's suppose to clip to View Port
... Opera and FireFox are currently clipping to the viewBox
... not the View Port

<ChrisL> which is wrong

CM: So the difference being aspect ratio conversion

ED: The View Port is typically bigger than the viewBox
... I did write up a couple of test cases
... JWatt had one as well
... I could try to convert that to the W3C template
... and commit those

CL: We could duplicate the test and add his modification

CM: Is there any problem with just taking the test?

CL: He can't modify the test
... we should keep paint-marker-01f
... duplicate it and add changes

<shepazu> http://www.w3.org/Graphics/SVG/WG/wiki/List_Syntax

1.2T list-of-string data type issue (again)

DS: In CSS they have rules for spaces

CL: What they say in CSS that is if you don't quote multiple spaces it will collaps it

DS: Could we say that for our lists that if you want to have characters that are commas
... colons or spaces you have to quote the string?

CM: You mean double quotes?

DS: Double or single

CM: Backslash
... double quotes could be away around that
... we could have a different type of list of strings that allows quotes around values
... it might be that the more restrictive types for the URIs don't need the quotes
... maybe that would be the extent of the lists

Proposed test for markers: offset viewBox (again)

<scribe> ACTION: Erik to Duplicate the test paint-marker-01f and add Jorge Stolfi's suggested changes to the test. Reply back to Jorge [recorded in http://www.w3.org/2009/04/20-svg-minutes.html#action01]

<trackbot> Created ACTION-2519 - Duplicate the test paint-marker-01f and add Jorge Stolfi's suggested changes to the test. Reply back to Jorge [on Erik Dahlström - due 2009-04-27].

SVG 1.1 Test suite: (somehow unexpected) "mobile" keyword

CM: Don't know exactly what's being pointed out - because I haven't read it yet

<ChrisL> http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-color-prof-01-f.html

CL: If you look at that
... and view source
... has "<meta name="keywords" content="W3C SVG 1.1 Test Suite testsuite mobile"/>"
... The way around it is to remove the word mobile

ED: I think the script that generates the harness has two options

<ChrisL> just remove the word "mobile" next time we regenerate the tests

CL: Next time we refresh it we will take the word out

<scribe> ACTION: Anthony to Reply to Helder's email saying that we will change the name the next time the test suite is regenerated [recorded in http://www.w3.org/2009/04/20-svg-minutes.html#action02]

<trackbot> Created ACTION-2520 - Reply to Helder's email saying that we will change the name the next time the test suite is regenerated [on Anthony Grasso - due 2009-04-27].

SVG 1.1 Second Edition update

http://dev.w3.org/SVG/profiles/1.1F2/publish/

CL: The link doesn't have all the files needed

CM: Not all the chapters are being built yet
... I wanted to point out
... that I've updated the list of editors
... the criteria I used was
... include the former editors, people that have added errata text, and people that are editing the spec files
... Oliver has made an errata entry
... so I thought that was a reasonable criteria for adding editors to the 1.1F 2nd spec

<heycam> that's here: http://dev.w3.org/SVG/profiles/1.1F2/publish/

JW: I''m fine with being added

<ChrisL> http://dev.w3.org/SVG/profiles/1.1F2/master/types.html

CL: In the data types chapter
... would you mind sorting that so the list of types are in alphabetical order
... like they are in Tiny 1.2

AG: That should definitely be changed

<scribe> ACTION: Chris to Change the order of the types in 1.1F 2nd so that they are alphabetical [recorded in http://www.w3.org/2009/04/20-svg-minutes.html#action03]

<trackbot> Created ACTION-2521 - Change the order of the types in 1.1F 2nd so that they are alphabetical [on Chris Lilley - due 2009-04-27].

<heycam> http://dev.w3.org/SVG/profiles/1.1F2/publish/types.html#BasicDataTypes isn't ordered

CM: What I've plan to do is once the rest of chapters are being generated properly
... I'll do some diffs with the original 1.1F
... and then we can start putting in the Errata

DS: So the thing that Chris is doing is changing the RNG or the Output?

CL: I'm changing the master types.html

DS: Just wanted to make sure changes wouldn't be overridden

CM: Perhaps I'll ping Oliver and see if cares about the editors list

ISSUE-2266: Correct Role Module Reference

ISSUE-2266?

<trackbot> ISSUE-2266 -- Correct Role Module Reference -- RAISED

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2266

DS: Simply a typo
... just needs to be changed

CL: Are you going to fix it then?

DS: I could do
... do we need to issue an errata for this?

CL: I believe so

CM: Hearing no objections we should issue an errata

RESOLUTION: We will create an errata for ISSUE-2266

<scribe> ACTION: Doug to Create an errata to address ISSUE-2266 [recorded in http://www.w3.org/2009/04/20-svg-minutes.html#action04]

<trackbot> Created ACTION-2522 - Create an errata to address ISSUE-2266 [on Doug Schepers - due 2009-04-27].

Child element order differences between SVG 1.1 and SVG Tiny 1.2

http://www.w3.org/mid/20090417053216.GE9802@arc.mcc.id.au

CM: Pointing out that in 1.1 there is some restriction in element order that doesn't exist in 1.2T

CL: Over time we thought it was good practice to have those things at the top
... there is not practical draw back to having a description at the end for example
... if we require it to be at the beginning then I think you'll find UAs will allow it to go anywhere

ED: I don't mind removing the restriction in the DTD
... as long as the spec says it's better to put it at the top

DS: I think it's reasonable to tell people that as a practice
... put it at the top
... because it helps for readability
... but doesn't effect the processing
... do we say what happens if we have more than one title or description?

ED: Yes we do

<ed_> http://www.w3.org/TR/SVG11/struct.html#DescriptionAndTitleElements

ED: [reads out part of spec]

JW: Could we strongly encourage that it should be the first child elements of the elements it's the title of?

CL: Why do you think it's good to have it at the top?

JW: When used as a tool tip. You have your target of the mouse over, you're basically looking up the all the elements of the parent to
... find the title

CL: Some UAs might be impacted
... they could construct a pointer to it when they see it, rather than do tree manipulation for every mouse over

CM: So if the title is not the first child then you definitely wont show the tool tip?

JW: There issues as some of it is implemented in Java script
... and there would be problems changing it

CM: Would you want the text to say that if it's not the first child then the UA doesn't have to render it?

DS: We went in that direction in Tiny 1.2

CL: We started moving towards moving to have a tooltip element in Full 1.2

DS: Anthony suggested to have an role on title to indicate what the title did
... Can't remember if it was put in there as an example in the spec

<ChrisL> close ACTION-2521

<trackbot> ACTION-2521 Change the order of the types in 1.1F 2nd so that they are alphabetical closed

<scribe> ACTION: Cameron to Add wording to Full 1.1 saying that if title is not the first child element that UAs can optionally render it [recorded in http://www.w3.org/2009/04/20-svg-minutes.html#action05]

<trackbot> Created ACTION-2523 - Add wording to Full 1.1 saying that if title is not the first child element that UAs can optionally render it [on Cameron McCormack - due 2009-04-27].

<shepazu> [[In order to honor authorial intent, it is strongly recommended that when, and only when, the appropriate 'role' attribute value is present, user agents display the text content of the applicable 'title' and 'desc' elements in a highly visible manner supported by the user agent, such as in a tooltip or status bar, when the pointing device is hovered over the described element or elements, or when the described element is given focus (e.g., through keyboard or

<heycam> ACTION-2523: and remove the restriction on child element order from the DTD

<trackbot> ACTION-2523 Add wording to Full 1.1 saying that if title is not the first child element that UAs can optionally render it notes added

CM: Something you might want to port back to 1.1?

DS: Seems relevant
... but 1.1 doesn't have the role attribute

Allowable presentation attributes

<heycam> http://www.w3.org/mid/20090417055354.GF9802@arc.mcc.id.au

CM: In Full 1.1 they are limited

CL: People argued that the DTD should be used to validate properties on an element
... I think that any property should be able to placed on any element

DS: Was this fixed in 1.2T?

CL: Yes

DS: I would consider it to be a feature of a validator that which properties don't apply to the element

CL: To my mind that's not a validator but an optimiser
... based what is actually there
... separate for validation
... it's an authoring tool

<shepazu> https://launchpad.net/scour

CM: Couple of questions about Tiny
... I think at one point we were toying with the idea that display controlled how title was used
... I'm not sure if it was because of that
... the media properties were put on those
... it doesn't seem very useful

CL: Yes, it doesn't seem very useful

CM: Could issue an errata

CL: I don't really have an opion
... it doesn't really hurt, but at the same time it's not a good idea

CM: The next question I have is why are only media properties allowed on <image>
... Should we issue an errata?

<ChrisL> i hadn't really twigged before that 'media' was all properties that don't conflict with smil "fill"

<scribe> ACTION: Cameron to Create an errata to address the questions in the email sent [recorded in http://www.w3.org/2009/04/20-svg-minutes.html#action06]

<trackbot> Created ACTION-2524 - Create an errata to address the questions in the email sent [on Cameron McCormack - due 2009-04-27].

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

- DRAFT -

SVG Working Group Teleconference

20 Apr 2009

Attendees

Contents