See also: IRC log
<trackbot> Date: 10 July 2008
<scribe> Scribe: anthony
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
<ed_> 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_> 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 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 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
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 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].
<ed_> 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 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
<ed_> 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 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].
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/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: http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0025.html Found Date: 10 Jul 2008 Guessing minutes URL: http://www.w3.org/2008/07/10-svg-minutes.html People with action items: doug emmons erik[End of scribe.perl diagnostic output]