SVG Working Group Teleconference -- 29 Apr 2008

<trackbot-ng> Date: 29 April 2008

<scribe> Scribe: anthony

Upcoming F2F meetings

ED: The first one is Sophia Antipolis
... that's already planned
... the next one is around SVG Open
... dates have been confirmed
... but we haven't really figured if out if we have anywhere to stay

<ed> http://www.w3.org/Graphics/SVG/Group/wiki/NuremburgF2F2008

ED: but I was wondering if Chris is going to set it up or if Andrew and I have to contact Alex Adam

AE: The page says it is hosted by Examotion
... Not sure if Doug contacted Alex about it

ED: We should probably move it to the public wiki

AE: Sure I can do it

ED: So the dates are Aug 21-24 for the F2F
... anyone has any problems?

CM: That's the week before SVG Open

<scribe> ACTION: AndrewE to contact Alex Adam about the SVG Face-2-face in August [recorded in http://www.w3.org/2008/04/29-svg-minutes.html#action01]

<trackbot-ng> Sorry, couldn't find user - AndrewE

<scribe> ACTION: Emmons to contact Alex Adam about the SVG Face-2-face in August [recorded in http://www.w3.org/2008/04/29-svg-minutes.html#action02]

<trackbot-ng> Created ACTION-2003 - Contact Alex Adam about the SVG Face-2-face in August [on Andrew Emmons - due 2008-05-06].

ED: So the next meeting after SVG Open is TPac meeting
... October 20 - 24

AG: Did Doug say where it was going to be held?

<ed> http://lists.w3.org/Archives/Member/w3c-svg-wg/2008AprJun/0134.html

ED: France somewhere

AE: Doug said something about which groups to meet with at the TP

ED: I did fill out some groups
... we should meet with HTML, XSL, CSS
... I filled out a lot of groups

AG: It's not all confirmed though

ED: Yup, it's still open
... so we can make changes to it
... I filled out HTML, WebAPI, SMIL, CDF
... I missed XSL
... so I guess we should really decide which groups to meet with
... not sure if we have to meet with WebAPI since many off us in WebAPI

AE: And SMIL
... do we have any outstanding issues with SMIL

ED: Yeah I guess we could skip it
... there is only so much time
... I'm not sure about the ARIA stuff
... if it will still be an issue
... or if it will be resolved before the TP

AE: It looks good to me

AG: The only suggestion I have is add in XSL

ED: Yup, I will do that

XMLHttpRequest

ED: The WebAPI WG requested the SVG working group to review the spec
... it's LC
... with due date June 2nd

AG: Is this something we should have a small discussion in France?

ED: Might be a good idea to read it in advanced
... then have a short discussion on it
... it's a pretty small spec, but it does have a fair bit of stuff in it
... I guess we can do as we've done in the past
... send all comments to the public SVG mailing list
... then collate all comments
... and send them
... From a quick read I didn't see anything particularly bad for SVG

CM: I guess the only thing is how compatible it is with getURL and postURL

ED: Yup

WAI-ARIA

ED: We are trying to set up a telcon
... some people interested in accessibility

CM: Does Opera implement any of it?

ED: Some of it
... there are somethings in there which are good for SVG
... it ties in with the role attribute
... for example the various roles which make sense for XHTML
... to represent text
... there is nothing saying that this is part of map or a diagram

CM: When is the telcon?

ED: Still trying to decide a date
... just interested in seeing anyone from here would want to attend

CM: A friend of mine who is also ding a PhD has started looking into role and would be interested in it
... than me
... dunno if anyone can come along

ED: Not sure, but I can confirm that

AE: We should be able to work something out
... the original email requested members of the working group
... but in this case it might be possible to work something out

CM: So at this stage no time has been confirmed

AE: Yeah, so looking for times and key people

ED: So Andrew do you want to look into that?

AE: So maybe if he joined the interest group
... do you think he would want to join the interest group?

CM: Maybe

ED: We need to respond to the original mail
... I'd be interested in at least attending one

<scribe> ACTION: Erik to respond to the WAI-ARIA email regarding the organisation of the multi-group telcon [recorded in http://www.w3.org/2008/04/29-svg-minutes.html#action03]

<trackbot-ng> Created ACTION-2004 - Respond to the WAI-ARIA email regarding the organisation of the multi-group telcon [on Erik Dahlström - due 2008-05-06].

SVG in CSS

ED: There is a whole thread going on in the Mozilla group
... as you know Apple has proposed to add things to CSS
... similar to SVG
... there has been suggestions that these things should be done in conjunction with SVG
... instead of CSS

CM: One of Robs suggestions was that things like fill, stroke be made to work in HTML
... which I think is a good idea

ED: I tend to agree with that
... I'm wondering if we should say something as WG on the CSS list

CM: So I guess at this stage making the CSS properties work
... hasn't been proposed to the CSS WG

ED: I don't know if it is best coming from a company or a working group
... but I should do something about this

CM: I guess it would be good if you weighed in on the thread

ED: I would love to see the fill and stroke work in HTML
... seems strange to not use the definitions used already in SVG

<scribe> ACTION: Erik to send an email to the CSS list regarding SVG in CSS [recorded in http://www.w3.org/2008/04/29-svg-minutes.html#action04]

<trackbot-ng> Created ACTION-2005 - Send an email to the CSS list regarding SVG in CSS [on Erik Dahlström - due 2008-05-06].

SVG in HTML requirements TBD

AE: Do you have link to the current requirements?

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG_in_text-html

ED: These are not decided requirements these are collections of what people thought
... might be good to have Chris and Doug here on this

<heycam> CM: Maciej argues that if you want to put SVG in HTML, then the main reason is so that you can use HTML-like (non-XML) syntax, since otherwise you could just use XHTML+SVG, which works already.

CM: So I wonder what people think of that argument
... is it fundamental, does it have merit?

AE: I thought the main debate was around Text/HTML
... so the reason for getting to main stream syntax was because of the lack of support for XHTML
... by MS

CL: So because MS doesn't do XHTML putting in SVG wont make them do it either

ED: If you have blogging software too that outputs something that is not well formed XHTML and you try to put in SVG inline
... it could work if we put in something like this

CL: How would it work?

ED: It would work for those people that would SVG inline

CL: If you have inline SVG it will not work
... but for other browers it will work if you have XHTML

<ChrisL> MS don't implement xhtml. They don't do SVG either. Whether the SVG is in XML syntax or in some other syntax, it won't suddenly work

<ChrisL> there are three things : 1) the syntax used 2) the internet media type 3) meta element

CL: meta type overrides media type in IE

<ChrisL> which is against what the TAG says

CL: if you want anything to work in I.E. you already need a lot of adaptation

<ChrisL> bottom line, if you want something to work in IE, there is a lot of adaptation needed

AE: So with Heycams original question is in the reason you want SVG in HTML syntax

<aemmons> AE: Is not to have the same syntax as text/html but because xhtml is not used as widely as text/html

AN: I think one problem is that they don't see the web is also tools as well

<ChrisL> no authorig tols will generate or import an undefined, non-XML syntax for SVG

AN: makes it harder for browsers to implement

CL: There is nothing to say this fragment is XML
... if there was an extension element similar to what Doug proposed
... then copy and paste from tools could be done

AE: So we want to come up with a list of requirements

<aemmons> http://www.w3.org/Graphics/SVG/WG/wiki/SVG_in_text-html

CL: So it's like you are or you aren't. It's either XML or it's not
... basically it's in a different syntax then
... and it needs to be defined then

CM: What about a subset of XML

CL: So for input a subset is probably fine
... for export it's probably not good
... PIs are already ignored

CM: You can put them anywhere, inside content

CL: As soon as you have unquoted attribute values
... then all the SVG implementations need to start accepting this as well
... you also need to say how do you know when you've reached the end of the attribute
... but if you have spaces and other things, then how do you know

CM: HTML5 has some defined method to define an end of an attribute

CL: It doesn't. HTML5 assumes you know all of HTML5 and you have all these complex rules
... to figure it out
... you need to have this case by case
... you don't have any extensibility at this point
... you can't skip them silently

CM: I can see that difference
... but I was under the impression that attributes were not in that case

ED: I read the parser of HTML5
... and it uses states to determine where you are
... they use a space and something else
... to determine the end of an attribute

CL: How would that work in SVG when attributes have spaces

CM: I think it's maybe not as complex as you think

CL: I think it is
... I've seen earlier problems with HTML
... at the moment it works as defined
... and any deviation from that means that you can't copy and paste
... between implementations

ED: Sounds like we are almost resolving here to not have unquoted attribute values

AE: It's more of a higher level

CM: Or a subset

<ChrisL> yes, i would argue strongly to not allow unquoted attribute values, so that content can be pasted back into authoring tools for future editing, or pasted into new content without change.

<ChrisL> also, and unquoted syntax meansd authors have to remember which atteras can be safely unquoted and which can not

AE: Seems like the first two points that Doug has covers what you are talking about
... so this is a discussion page to see what ideas we have that overlap

CL: We could make several proposals
... one is you use an island to allow XML
... another is you only use it in XHTML

<ChrisL> both of those options would keep the svg actually compatible with all existing svg renderers and authoring tools

CM: I think his underlaying reason is not taking the fallback option
... if the UA hasn't implemented SVG in HTML, then the UA may not understand it then somethings may wrongly appear

CL: We don't have element content that is meaningless
... in fact if you end up displaying SVG confusing it with HTML
... then you will see some text
... with anchors in it
... and that was by design

<ChrisL> You will notice that SVG avoided having meaningless numbers as element content. pretty much the only element content iis human readable text. the rest of it is in attributes

AE: So now we are getting to does requirement of a fallback
... so you can provide fallbacks like flash, text, another image

CL: I do think you should provide fallbacks
... in HTML there is object, which uses nesting

ED: That still doesn't really work in I.E.

CL: It took a while for vendors to figure out how it works correctly

AE: So Doug's other point was unrestricted growth
... if you cover requirement 1 and 2, then it seems to be covered by that

ED: I would like Doug's 1st requirement put a bit stronger
... is about having it render, having the same DOM

<aemmons> Should allow for SVG Fonts to be included in HTML, and ideally to be usable in HTML text.

<aemmons> Should allow for the creation of scripted content that works identically for inline SVG and standalone SVG (though there may be certain limitations placed on the script author). This may entail SVG elements be in the SVG namespace in the DOM.

AE: So there'd need to be a way for this to work outside the island

CL: Want it so it could be used with HTML and other things

<ChrisL> It should; its indirected through a property for exactly that reason

<ChrisL> so it should work for svg fonts on html via css, and there are two implementations that do this

ED: I agree with that
... not sure about the certain limitations

<aemmons> Should have a clean model for how the various DOM interfaces work together.

ED: would be good if there are a few examples there

CM: Not sure what the last one means

CL: I assume what it means is the DOM interfaces should work the way they currently do
... if that what it means it should be expressed more clearly
... there are no barriers really
... when you parse tag-soup HTML5 you get an XML DOM

AE: So the island is more from the parser point of view

<ChrisL> if it means 'the existing dom methods continue to work' then I agree

<aemmons> From Maciej:

<aemmons> # Existing pages must not break (to a significant extent), even if they are currently using crazy broken syntax.

AE: Moving into Maciej's requirements

CL: This is more a proof of concept

CM: In Ian's large email he did quote some sites that had some broken syntax
... when I asked Ian about the sites asked in that email he said they were representative of the uses of the crazy SVG things
... where he doesn't want the rendering to change
... but I haven't read through the whole email
... I think it might be worth reading the top bit

<ChrisL> Of course its trivial to produce a test page that bady misuses something like svg syntax, if all you want is a discussion point or exhibit. if you want an existing page that uses svg *and renders as svg currently* then the amount of broken svg content with a non-xml syntax out there is very small

AN: We have the opportunity to have more stricter conformance from the browers
... the market share of alternative browsers is rising
... I.E. is dropping

<aneumann> AN: and people won't ignore Firefox (with somewhere between 25 and 50%) if it is stricter in conformance

<heycam> CM: i think the argument about breaking pages is a subjective one. if there is a single page with weirdo svg in it that would break, then perhaps it is ok.

<aemmons> Any constructs added inline to text/html must specify a tolerant error handling model, for the following reasons:

AE: The last requirement is this one here
... so that seems to be the main argument
... to not have an XML island

ED: No one has specified where the draconian handling would be

CL: The XML would have two children, one which is XML and one which is fallback
... if XML is not understood then use fallback
... or if XML is not well formed
... then use the fallback
... so you hand of the subtree to the XML parser
... and if it returns an error then you go to the fallback

AN: So if you didn't define a fallback then would have some default rendering?

CL: Perhaps nothing is rendered

ED: In a legacy browser you'd get the text

CL: That's right
... given that XML tag would have a common name, you could style that
... and hide it

<ChrisL> you could easily make a stylesheet to hide the xml part if needed

AN: I think one of the reasons for tag soup is none of the browsers don't display the error messages well enough
... I.E. has the "!" to show the error
... it would be a good idea to have something like this for HTML and SVG as well
... would be a good idea to be able to see the error rather than open up a console

CL: The browsers get used as authoring preview tools
... they have a preview mode
... that shows errors and warnings
... if the error is going to give you problems
... then they'll fix it
... it's knowing what the consequences are

AE: It sounds to me like we could keep the last requirement
... and we have a reasonable way of satisfying it

ED: So I guess we have some solid requirements
... we should update the wiki from this discussion
... and try to make a good proposal

AE: Should we do up the requirements?

CL: I think we need to write up the requirements better first
... I don't think we need to send them out separately

ED: Since we can't edit the wiki (atm) will be have to wait until Doug gets back

AE: my impressing is that there is a second stage to enable editing
... if you send an email to him
... and copy me

<scribe> ACTION: Emmons to update the wiki with the SVG in HTML requirements discussed [recorded in http://www.w3.org/2008/04/29-svg-minutes.html#action05]

<trackbot-ng> Created ACTION-2006 - Update the wiki with the SVG in HTML requirements discussed [on Andrew Emmons - due 2008-05-06].

SVG Open

<ChrisL> Andreas says that paper review is about to start

- DRAFT -

SVG Working Group Teleconference

29 Apr 2008

Attendees

Contents