W3C

- DRAFT -

SVG Working Group Teleconference

24 Nov 2008

Agenda

See also: IRC log

Attendees

Present
Shepazu, heycam, anthony, ed, Shepazu.a
Regrets
CL
Chair
Erik
Scribe
anthony

Contents


 

 

<trackbot> Date: 24 November 2008

<scribe> scribe: anthony

Upcomming F2F meetings

ED: I saw that it was discussed at the last telcon
... is there a registration page up for it?

DS: No, but I'll make one up now

ED: For the next F2F after that we are planning on having it in France?

DS: Raliegh
... I'm going to Web Directions North in the first week of Feb

<shepazu> http://www.w3.org/2002/09/wbs/19480/SydneyF2F2009/

DS: Registration link is there, adding it to the wiki page now

HTML and SVG coordination

ED: We did start some discussion at the TPAC with the HTML WG
... we decided a number of goals for SVG inside of HTML5
... probably didn't finish the discussion

DS: I think we should make this a priority
... at the F2F in short the SVG WG acknowledged that it is desirable to have error correction
... SVG should be in XML syntax and if the content creator doesn't make it in that syntax then error
... correction is applied

CM: So it's a question of a validity
... so I think it HTML they have various things that are parsing errors that get corrected

DS: The distinction is subtle but I'd like wording saying that the SVG is not correct but it will be corrected
... E.g. There are certain elements that can't be left open in HTML5
... We do see some benefit of this, but it should be serialised as XML
... In HTML5 attribute values don't have quotes and this is allowed. But in SVG this is reported as an error
... but in HTML5 this can be error corrected

CM: So there was in principle support for the that view of document validity and error correction?

DS: There should be no white list of SVG elements, any SVG element that is legal in SVG should be allowed
... And it doesn't matter what language we are putting in there. The author shouldn't have to do anything special when they are
... putting in SVG
... so the white list only be that of what is supported by implementations rather than a specification
... I think the parser requires a list of element stings
... we may need to make some distinction about how SVG is treated
... there were conflicts in names "a" element, "textArea", "font", "metadata" they were essentially black listed
... they shouldn't be black listed or white listed
... what are the next steps we need to take?

CM: Someone should write up the scheme you described?

DS: I need to go back and read Ian's proposal
... he says exactly how it needs to be parsed, but if an implementation wants to parse it differently
... then this should be allowed
... it shouldn't say that you can't

CM: You wouldn't want those two different ways to result in different output

DS: Ideally no
... I guess you have a point

CM: Uniform parsing is one of the requirements of HTML5

ED: Do we need to talk to the HTML Working Group again regarding the goals?
... I'm wondering if Ian has everything he has to make a new proposal?
... or if he needs more info

DS: We should probably come back with an email saying these are the goals we agreed to at TPAC
... we'd like to move forward with this
... perhaps we should have a conversation on our email list first

ED: Sure, I can do that

DS: We had some proposals some went down to the parser level. We have said that the HTML parser can be used to parse SVG
... so it should be easier to say these are the goals that should be met
... Simply putting it in the spec may not be good enough. We need to consider the implications of what's in there.
... Compared to SVG in strict XML

ED: I will send an email out about this
... and try to collect the goals we decided on

<scribe> ACTION: Erik to Send an email to the SVG Working Group regarding the goals that were decided on at TPAC for SVG in HTML [recorded in http://www.w3.org/2008/11/24-svg-minutes.html#action01]

<trackbot> Created ACTION-2355 - Send an email to the SVG Working Group regarding the goals that were decided on at TPAC for SVG in HTML [on Erik Dahlström - due 2008-12-01].

Errata 1.1

ED: Has something been done about this?

AG: I had an action to split out the 1.1
... but I haven't gotten around to doing this

ED: I think it would be helpful to check in what's been done on 1.1 2nd edition

http://www.w3.org/Graphics/SVG/Group/repository/errata/errata.xml

Undefined Behaviour with Filters

http://www.w3.org/Graphics/SVG/Group/repository/errata/errata.xml#undefined-behaviour-with-filters

ED: It's about 8 years old
... His example is about making something less transparent, why not use opacity? Or am I missing something

DS: I think we should skip this one
... and see if we can solve this in the next filters module
... perhaps we can raise an issue on the filters module for this

CM: I think he's saying that the initial canvas is undefined
... but I think that it might be

<shepazu> ISSUE-2185?

<trackbot> ISSUE-2185 -- Update SVG 1.2 Tiny to account for the change in the default overflow property in SVG 1.1 -- RAISED

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

ISSUE-2185

DS: The paragraph in question is the last one in 7.10

<shepazu> http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0344.html

DS: it seemed to me that we should correct this to match the behaviour we are allowing which is here
... that overflow is only hidden for things that are not root
... I think that was for SVG elements only

<ed> the <svg> element

DS: I thought they were talking about the root element

ED: That's at least how I understood the elemail from David H
... I guess we could do some slight rewording if you want

DS: Doesn't it contradict

ED: It's still informative

DS: We could say that this paragraph is misinformative (or possibly disinformative) =P

<shepazu> s/missinformative/misinformative (or possibly disinformative)/

DS: We could add

<shepazu> [[ since the initial value for the 'overflow' property is hidden for non-root elements that establish viewports ([SVG11], section 14.3.3). ]]

DS: That would satisfy me
... and that would accurately describe what we are doing for SVG 1.1

CM: I don't know if saying initial value is exactly right

<ed> http://www.w3.org/TR/2003/REC-SVG11-20030114/masking.html#OverflowProperty

CM: I think the property only has one initial value

ED: Overflow is pretty verbose
... different initial values depending on the element

DS: We probably should try to correct more than we want to at this time
... this will change eventually

Resolution: We will change the informative section 7.10 to match the wording of the SVG 1.1 errata

<scribe> ACTION: Doug to Make the change as agreed to for ISSUE-2185 [recorded in http://www.w3.org/2008/11/24-svg-minutes.html#action02]

<trackbot> Created ACTION-2356 - Make the change as agreed to for ISSUE-2185 [on Doug Schepers - due 2008-12-01].

DS: As issues come in for spelling and typos, I am correcting them in Master, but not in the Published (PR) draft
... whenever we go to Rec they will appear in it

<ed> http://www.w3.org/Graphics/SVG/Group/repository/errata/errata.xml#script_animatable_xlink_href

Errata items

ED: This one is about xlink:href is animatable
... in Tiny 1.2 we say it can't be

CM: Is this because xlink:href is defined one place?

ED: It could be
... I think some have it in the attribute list

CM: It's mentioned in "use" for example
... maybe it should be something we have for Core
... list the attributes for each element def

DS: I already raised an issue on that already
... the build script should build it form the schema

ED: I would to move this errata item to proposed

AG: I don't have any problems with this one

Resolution: We will move the Errata item "Clarify if xlink:href on <script> elements is animatable or not" to proposed

http://www.w3.org/Graphics/SVG/Group/repository/errata/errata.xml#attribute-index

AG: This one looks complete

CM: I wrote the item but I remember at one point Chris had an action to check it

AG: I'm ok with this

ED: Me too

Resolution: We will move the Errata item "Incorrect entries in the attribute index" to proposed status

<scribe> ACTION: Anthony to Change the status on the errata times as per the resolution [recorded in http://www.w3.org/2008/11/24-svg-minutes.html#action03]

<trackbot> Created ACTION-2357 - Change the status on the errata times as per the resolution [on Anthony Grasso - due 2008-12-01].

http://www.w3.org/Graphics/SVG/Group/repository/errata/errata.xml#svgzoomevent-interface

ED: The "SVGZoomEvent - Interface" seems to be ok to me
... just checking Tiny now

CM: It's just a basic event

ED: And in 1.1 it is UIEvent
... so that wouldn't affect Tiny at all

CM: Maybe Tiny must of changed from UIEvent to BasicEvent at some point
... should someone take Andrew's action to check it out?

ED: I'm just wondering if there is anything to check out
... we can see there is no SVGZoomEvent in Tiny
... any change we make in 1.1 unless we make it incompatible in some way should be fine
... I don't think removing some of those interface events will effect anything
... I'm not sure in which circumstance they will be applicable anyway

CM: Unless you had some sort of interaction where you can click to zoom
... should we just close this action and accept this?

ED: Would be fine with me at least

AG: I can't edit the action

DS: Old tracker is not working

AG: I'll edit the errata to say the action is closed
... and move it to proposed if there are no objections

ED: Just wondering if we can change the status of the next one after that
... it seems to have a resolution

AG: And same with the one after that

ED: We can postpone this for Thursday

Summary of Action Items

[NEW] ACTION: Anthony to Change the status on the errata times as per the resolution [recorded in http://www.w3.org/2008/11/24-svg-minutes.html#action03]
[NEW] ACTION: Doug to Make the change as agreed to for ISSUE-2185 [recorded in http://www.w3.org/2008/11/24-svg-minutes.html#action02]
[NEW] ACTION: Erik to Send an email to the SVG Working Group regarding the goals that were decided on at TPAC for SVG in HTML [recorded in http://www.w3.org/2008/11/24-svg-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/11/24 21:06:07 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/error correction/that view of document validity and error correction?/
Succeeded: s/missinformative/misinformative (or possibly disinformative)/
FAILED: s/missinformative/misinformative (or possibly disinformative)/
Succeeded: s/... I don't know if/CM: I don't know if/
Succeeded: s/it/the action/
Found Scribe: anthony
Inferring ScribeNick: anthony
Default Present: Shepazu, heycam, anthony, ed, Shepazu.a
Present: Shepazu heycam anthony ed Shepazu.a
Regrets: CL
Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2008OctDec/0396.html
Found Date: 24 Nov 2008
Guessing minutes URL: http://www.w3.org/2008/11/24-svg-minutes.html
People with action items: anthony doug erik

[End of scribe.perl diagnostic output]