W3C home > Mailing lists > Public > public-svg-wg@w3.org > April to June 2008

Minutes, SVG telcon Tuesday 29 April 2008

From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
Date: Tue, 29 Apr 2008 22:15:33 +1000
Message-ID: <48171165.5080504@cisra.canon.com.au>
To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>



       [1] http://www.w3.org/

                                - DRAFT -

                    SVG Working Group Teleconference

29 Apr 2008



    See also: [3]IRC log

       [3] http://www.w3.org/2008/04/29-svg-irc


           aemmons, ed, heycam, anthony, Andreas_Neumann, ChrisL




      * [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

    <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

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

    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

    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

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

    <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

    <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

    <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


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

    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

    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

    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

    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
    ... and hide it

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

    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

    <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
    [NEW] ACTION: Emmons to contact Alex Adam about the SVG Face-2-face
    in August [recorded in
    [NEW] ACTION: Emmons to update the wiki with the SVG in HTML
    requirements discussed [recorded in
    [NEW] ACTION: Erik to respond to the WAI-ARIA email regarding the
    organisation of the multi-group telcon [recorded in
    [NEW] ACTION: Erik to send an email to the CSS list regarding SVG in
    CSS [recorded in

    [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

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

      [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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:08 UTC