See also: IRC log
<trackbot-ng> Date: 29 April 2008
<scribe> Scribe: anthony
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
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
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].
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].
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].
<ChrisL> Andreas says that paper review is about to start
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/are26-29/are Aug 21-24 for the F2F/ Succeeded: s/So we have/The WebAPI WG/ Succeeded: s/public mailing list/public SVG mailing list/ Succeeded: s/svfg/svg/ Succeeded: s/parse HTML/parse tag-soup HTML5/ Found Scribe: anthony Inferring ScribeNick: anthony Default Present: aemmons, ed, heycam, anthony, Andreas_Neumann, ChrisL Present: aemmons ed heycam anthony Andreas_Neumann ChrisL Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJun/0008.html Found Date: 29 Apr 2008 Guessing minutes URL: http://www.w3.org/2008/04/29-svg-minutes.html People with action items: andrewe emmons erik[End of scribe.perl diagnostic output]