- From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
- Date: Fri, 11 Jul 2008 00:30:49 +1000
- To: SVG WG <public-svg-wg@w3.org>
http://www.w3.org/2008/07/10-svg-minutes.html
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
10 Jul 2008
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0025.html
See also: [3]IRC log
[3] http://www.w3.org/2008/07/10-svg-irc
Attendees
Present
ed_, aemmons, heycam, anthony, Doug_Schepers
Regrets
Chair
Erik
Scribe
anthony
Contents
* [4]Topics
1. [5]XHTML Access Module
2. [6]SVG in HTML5
3. [7]http://lists.w3.org/Archives/Public/www-svg/2008Jul/0000
.html
4. [8]Feed back on SVG 1.1 Errata
5. [9]Duration of an SVG file
6. [10]Limitation of Units and propose extension
* [11]Summary of Action Items
_________________________________________________________
<trackbot> Date: 10 July 2008
<scribe> Scribe: anthony
XHTML Access Module
ED: I read the review
... and I think it's fine
... I gave Doug some feedback already
... anything else we want to add to the review?
... or any comments?
CM: Not if it's the same stuff we talked about on Tuesday
DS: Was hoping Chris would read it
ED: We still have today before it has to be sent off right?
... unless there are any objections or comments
... we can send this off to the XHTML group
RESOLUTION: We will send the proposed comments to the XHTML Working
Group
DS: So I slipped in parts of my original review
... any objections?
AG: None
ED: I don't see any major issues with sending off
DS: I'll send it off now
SVG in HTML5
<ed_>
[12]http://dev.w3.org/SVG/proposals/svg-html/svg-html-proposal.html
[12] http://dev.w3.org/SVG/proposals/svg-html/svg-html-proposal.html
ED: There have been a few updates to the proposal
... clarifications
... descriptions on what we want to do
... so we updated the first section
... requirements
... we had a requirement form Marceij about error handling
<ed_>
[13]http://dev.w3.org/cvsweb/SVG/proposals/svg-html/svg-html-proposa
l.html.diff?r1=1.5&r2=1.6&f=h
[13]
http://dev.w3.org/cvsweb/SVG/proposals/svg-html/svg-html-proposal.html.diff?r1=1.5&r2=1.6&f=h
ED: here's the diff
... So you can see in the last bit we loosened the requirement a bit
... so one of the things I wanted to ask is
... how to deal with broken mark up
... [reads out what's currently written]
... the SVG fragment will show something
... then the HTML parser takes over
... the question is do we want the broken fragment to show up
... or do we want text description to show
... so you'd create elements up to that point
... and they'd be rendered in some other way
CM: You could throw them away
ED: I guess that's possible
... I think what we want to avoid is reparsing
... this proposal doesn't do any reparsing
CM: If you open a comment and then don't close it by the end of the
file it goes back and
... reparses it
ED: That's true
... doing reparsing here would be heavier
CM: Don't know whether to keep them there or throw them away
... which way would be the best?
DS: I'm concerned that if we allow for recovery behavior of well
form-ness
... that's the slippery slope right
ED: I thought someone mentioned security issues with reparsing of
comments
... can't remember
CM: Do you say to close all of the elements right back to where the
SVG started?
ED: Yes
CM: The alternative would be to close the element that had the error
... and switch to HTML parser
... and continue to set elements at that point
... ED do you know if you don't get a closed tag for the thing at
the top what it does
... just wondering if we switch to HTML parser straight away
... then as you go down the SVG closing tags that might not make the
tree so bad
ED: You may end of up with odd close tags
<ed_> ...arbitrary case close tags is what's odd in this case
DS: There was some discussion in the HTML group that a UA should
allow the user to export valid XML
... to solve the extraction problem
... I could see Inkscape changing for the new parsing
... but I couldn't see Illustrator changing
... changing SVG so that it's not well formed would mess with the
model
... that's the way it was designed
... now errors in values we already have a description for that
... for well formness errors it should close off the SVG right there
... everything goes into the tree
... but is not rendered
... so you would like to see something similar to the proposed model
... and you would say anything beyond that would not be rendered
ED: I can see people would have a problem with that
... chances are there would be HTML beyond that
... so then IE would render HTML pages that are broken and UAs that
tried to handle the SVG
... parts would not render correctly
DS: Not sure how that follows
... so IE wouldn't simply render the SVG unless there was a plugin
ED: So any browser today would not handle the SVG part
... it would handle it as HTML
... try to understand any parts that look like HTML
DS: What about it puts it into the tree but anything past that is
not rendered
... is it should continue to search for a close SVG
CM: So if don't have a closing SVG element then nothing passed the
error would render
DS: I'm proposing that if that if there is a well formness error the
parser should try to continue to parse everything into the DOM
... what happens a snippet of SVG where they didn't close the SVG
root
... and what happens when they don't close the circle and there is a
rect after that
... should the rect be rendered should the circle be rendered?
... if there is a star, circle, and a rect
... and there is an error in the circle
... I say the star only should be rendered
ED: That's what we are proposing at the moment
... after the point in error it's parsed as HTML
... if you have fallback content then you'd show the broken SVG and
the fallback content
DS: We should try to accommodate the broken content
... fallback content for a well formness error
ED: We should put that in the proposal
DS: I did
... it describes the different types of fallbacks
... I think the way it is fine
ED: Do we have agreement to close the SVG tag?
... in the case of well formness errors
... to close all the elements on the stack
... to where XML parsing began
DS: There are only a couple of things will look odd if we do this
... if there is a font it will rendered as a HTML font
ED: It would be odd either way
... there is one thing you can do
... which is prefix the elements
DS: That's an interesting point
... maybe we should mention that something specific in the proposal
... as an authoring tip
... would you mind doing that?
ED: Sure
DS: Most of these elements would do nothing in HTML
... only text would do something
CM: and textArea
... and font
ED: It doesn't do much
... I was curious about the font stuff, but it is possible to
determine the type from the attributes
CM: Bit hacky
DS: The whole reason for fallback behavior is to make a best guess
at what the author intended
... in this case I don't think that it's at all outside the spirit
of that
... to render what text you can
... and say I don't know what to do with the rest of it
... because the author hasn't given enough information to say what
to do
... as an author I would like to see what I've done wrong
... and by it not showing is a pretty good indication
... we are trying to do the best for the authors
<scribe> ACTION: Erik to add prefixing of elements with name
collisions to the SVG in HTML proposal [recorded in
[14]http://www.w3.org/2008/07/10-svg-minutes.html#action01]
<trackbot> Created ACTION-2093 - Add prefixing of elements with name
collisions to the SVG in HTML proposal [on Erik Dahlström - due
2008-07-17].
ED: This way you can make sense of them
DS: We should be careful about how we name stuff in the future
ED: Do we want to send this off this week?
... do we want to add more to it?
DS: Maybe we can hold off to tomorrow
... and if Chris can look at it tomorrow
... we could say it's a tentative proposal and that we are
interested in feedback
... form the group and the public
... that will allow Chris to respond to it
AE: There's no guarantee that Chris can look at it tomorrow
ED: Just because we send it doesn't mean it can't be discussed and
changed
DS: It's not a complete proposal but it's close
ED: I just noticed that there is a section on SVG resources
DS: I tried putting some wording in there about that
... it's related to what Opera and Moz (roc) is doing with SVG and
HTML
... if you can add some stuff that you've been doing would be good
... I mean notes and potential things we could do
... sort of an informative
ED: Ok I'll try to flesh that out
<scribe> ACTION: Erik to send the SVG in HTML proposal to the HTML
Working Group [recorded in
[15]http://www.w3.org/2008/07/10-svg-minutes.html#action02]
<trackbot> Created ACTION-2094 - Send the SVG in HTML proposal to
the HTML Working Group [on Erik Dahlström - due 2008-07-17].
<ed_> z
[16]http://lists.w3.org/Archives/Public/www-svg/2008Jul/0000.html
[16] http://lists.w3.org/Archives/Public/www-svg/2008Jul/0000.html
Feed back on SVG 1.1 Errata
ED: On set matrix
... I went through my actions and I didn't see anything relating to
this
... this is strange one
... because we have to change a proposed
AG: A proposed errata is not an accepted errata
... which means we can probably take it back to draft and work on it
ED: Has anyone else taken a look at this yet?
... I tested it a bit
... and it seems the values are copied
... in Batik and Opera
... and the same for create SVG transform matrix
... and the last was for consolidate
... how do we want to treat the case where we have a list of
transforms
... and we want to consolidate
... do we create a new item in the list?
DS: What do you think will be most intuitive for users?
... I don't have an opinion on this
... what do implementations do?
... should choose the solution that gives the most options
ED: Opera seems to consolidate to the first item in the list
... so if you have a reference to the first item
... you don't have to grab a new reference
... Do you want to throw away the value you have and do a new one?
... that's what's being proposed
... I guess doing consolidate on one item is not a good idea
AG: Is this an edge case?
ED: Kind of
... Would be good to have feed back form CM
... I think it's ok to get a fresh transform item in the list
<scribe> ACTION: Erik to change the proposed errata item and report
back to the group [recorded in
[17]http://www.w3.org/2008/07/10-svg-minutes.html#action03]
<trackbot> Created ACTION-2095 - Change the proposed errata item and
report back to the group [on Erik Dahlström - due 2008-07-17].
Duration of an SVG file
<ed_>
[18]http://lists.w3.org/Archives/Public/www-svg/2008Jul/0015.html
[18] http://lists.w3.org/Archives/Public/www-svg/2008Jul/0015.html
ED: I think this is pretty interesting
... it's suggesting that we should have a way of specifying the time
for an SVG fragment
... currently we don't have a way of specifying this
... if you author a comic you may want to specify how long it runs
for
... using an intrinsic duration
... I guess this would be a nice feature
... but probably out of scope for Tiny
AE: In the very early days when people were asking for SVG
... they wanted something that was almost like an Animated GIF
... so it has a defined duration
... someone would have been able to put the exact duration about how
long
... the file runs for
... I guess it would be a bit of a burden on the implementor
... to figure out how long the animation runs for
... I guess the duration at the top of the file would determine how
long the animation ran for
... there was some stuff in SVG Full 1.2
... I'd hesitate to put anything in Tiny at this stage
... So we've implemented something ourselves
... where we calculate the intrinsic duration
... but Julien has made some good points
DS: I would like to respond to him in some way, I would like to get
some formal resolution from this group
ED: I think a resolution would be we want to investigate this
DS: I don't think this is something we want to do in Tiny 1.2
... but the idea has merit
<scribe> ACTION: Emmons to respond to Julien saying that will
investigate his idea for future versions of SVG [recorded in
[19]http://www.w3.org/2008/07/10-svg-minutes.html#action04]
<trackbot> Created ACTION-2096 - Respond to Julien saying that will
investigate his idea for future versions of SVG [on Andrew Emmons -
due 2008-07-17].
DS: So Julien's email goes right along with getting other properties
of the SVG such as dimensions
Limitation of Units and propose extension
<ed_>
[20]http://lists.w3.org/Archives/Public/www-svg/2008Jun/0068.html
[20] http://lists.w3.org/Archives/Public/www-svg/2008Jun/0068.html
ED: I read this
... and I thought
... this would be quite similar to Cameron's constraint stuff
DS: I mentioned that to him and he mentioned that he didn't want to
have
... to implement a whole new feature set to get this extension
... he pointed out a few cases
ED: If this is sort of syntax is supported in SVG then it would be
good
... for SVG to have this
... I think this would also be good for HTML and CSS
... they've often wanted to do what he's wanting to do
DS: I think this is a special case of the constraints syntax
ED: So I'm only slightly worried that this will be incompatible with
older UAs
... it will be treated as a default value in the older UAs
DS: A video element will end up looking like nothing
ED: Just wondering if there is something that is backwards
compatible
DS: Cameron did a bit of work on this stuff and thought using a
child element that would introduce this
... you'd give it 50% and then say -10 pixels
... not matter what happens you're not going to get what the author
expected
ED: But the author could make it such that it looks ok in older UAs
... but look better in newer UAs
DS: So the solution here is switch
... have required feature
ED: That's fine I guess
DS: Any plugins or modern browsers that come out at this point
... would implement this
ED: I think his extension seems to be less advanced
DS: But he is trying to cover different use cases to what Cameron
was
... here's what I'd like say
... I'd like to start work on the layout module
... it doesn't take a lot to start the specification
... this could be a feature of that
AE: His (Roc's) proposal looks good
DS: I propose we start the layout module
... and we add one of these things as his syntaxes
AE: As long as it doesn't take the focus away from the test suite
RESOLUTION: We will start the layout module and we will tentatively
put Roc's suggestion in
<scribe> ACTION: Doug to create layout the module and email Roc
[recorded in
[21]http://www.w3.org/2008/07/10-svg-minutes.html#action05]
<trackbot> Created ACTION-2097 - Create layout the module and email
Roc [on Doug Schepers - due 2008-07-17].
Summary of Action Items
[NEW] ACTION: Doug to create layout the module and email Roc
[recorded in
[22]http://www.w3.org/2008/07/10-svg-minutes.html#action05]
[NEW] ACTION: Emmons to respond to Julien saying that will
investigate his idea for future versions of SVG [recorded in
[23]http://www.w3.org/2008/07/10-svg-minutes.html#action04]
[NEW] ACTION: Erik to add prefixing of elements with name collisions
to the SVG in HTML proposal [recorded in
[24]http://www.w3.org/2008/07/10-svg-minutes.html#action01]
[NEW] ACTION: Erik to change the proposed errata item and report
back to the group [recorded in
[25]http://www.w3.org/2008/07/10-svg-minutes.html#action03]
[NEW] ACTION: Erik to send the SVG in HTML proposal to the HTML
Working Group [recorded in
[26]http://www.w3.org/2008/07/10-svg-minutes.html#action02]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [27]scribe.perl version 1.133
([28]CVS log)
$Date: 2008/07/10 12:07:31 $
_________________________________________________________
[27] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[28] http://dev.w3.org/cvsweb/2002/scribe/
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 [29]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[29] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/anything/nothing/
Succeeded: s/ROC/Opera and Moz (roc)/
Succeeded: s/references/reference/
Succeeded: s/gues/guess/
Found Scribe: anthony
Inferring ScribeNick: anthony
Default Present: ed_, aemmons, heycam, anthony, Doug_Schepers
Present: ed_ aemmons heycam anthony Doug_Schepers
Agenda: [30]http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSe
p/0025.html
Found Date: 10 Jul 2008
Guessing minutes URL: [31]http://www.w3.org/2008/07/10-svg-minutes.html
People with action items: doug emmons erik
[30]
http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0025.html
[31] http://www.w3.org/2008/07/10-svg-minutes.html
End of [32]scribe.perl diagnostic output]
[32] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Thursday, 10 July 2008 14:31:32 UTC