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