See also: IRC log
<trackbot> Date: 24 November 2008
<scribe> scribe: anthony
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
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].
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
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
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
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]