- From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
- Date: Tue, 29 Apr 2008 22:15:33 +1000
- To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
29 Apr 2008
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJun/0008.html
See also: [3]IRC log
[3] http://www.w3.org/2008/04/29-svg-irc
Attendees
Present
aemmons, ed, heycam, anthony, Andreas_Neumann, ChrisL
Regrets
Chair
Erik
Scribe
anthony
Contents
* [4]Topics
1. [5]Upcoming F2F meetings
2. [6]XMLHttpRequest
3. [7]WAI-ARIA
4. [8]SVG in CSS
5. [9]SVG in HTML requirements TBD
6. [10]SVG Open
* [11]Summary of Action Items
_________________________________________________________
<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> [12]http://www.w3.org/Graphics/SVG/Group/wiki/NuremburgF2F2008
[12] 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
[13]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
[14]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>
[15]http://lists.w3.org/Archives/Member/w3c-svg-wg/2008AprJun/0134.h
tml
[15]
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
[16]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
[17]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> [18]http://www.w3.org/Graphics/SVG/WG/wiki/SVG_in_text-html
[18] 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>
[19]http://www.w3.org/Graphics/SVG/WG/wiki/SVG_in_text-html
[19] 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
[20]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
Summary of Action Items
[NEW] ACTION: AndrewE to contact Alex Adam about the SVG Face-2-face
in August [recorded in
[21]http://www.w3.org/2008/04/29-svg-minutes.html#action01]
[NEW] ACTION: Emmons to contact Alex Adam about the SVG Face-2-face
in August [recorded in
[22]http://www.w3.org/2008/04/29-svg-minutes.html#action02]
[NEW] ACTION: Emmons to update the wiki with the SVG in HTML
requirements discussed [recorded in
[23]http://www.w3.org/2008/04/29-svg-minutes.html#action05]
[NEW] ACTION: Erik to respond to the WAI-ARIA email regarding the
organisation of the multi-group telcon [recorded in
[24]http://www.w3.org/2008/04/29-svg-minutes.html#action03]
[NEW] ACTION: Erik to send an email to the CSS list regarding SVG in
CSS [recorded in
[25]http://www.w3.org/2008/04/29-svg-minutes.html#action04]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [26]scribe.perl version 1.133
([27]CVS log)
$Date: 2008/04/29 12:07:40 $
_________________________________________________________
[26] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[27] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51
Check for newer version at [28]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[28] 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: [29]http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJu
n/0008.html
Found Date: 29 Apr 2008
Guessing minutes URL: [30]http://www.w3.org/2008/04/29-svg-minutes.html
People with action items: andrewe emmons erik
[29]
http://lists.w3.org/Archives/Public/public-svg-wg/2008AprJun/0008.html
[30] http://www.w3.org/2008/04/29-svg-minutes.html
End of [31]scribe.perl diagnostic output]
[31] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Tuesday, 29 April 2008 12:18:24 UTC