SVG Working Group Teleconference -- 10 Jul 2008

<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_> 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

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 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_> 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

Limitation of Units and propose extension

<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].

- DRAFT -

SVG Working Group Teleconference

10 Jul 2008

Attendees

Contents