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

Minutes, SVG telcon Thursday 10 July 2008

From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
Date: Fri, 11 Jul 2008 00:30:49 +1000
Message-ID: <48761D19.8080906@cisra.canon.com.au>
To: SVG WG <public-svg-wg@w3.org>


http://www.w3.org/2008/07/10-svg-minutes.html

---

    [1]W3C

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

                                - DRAFT -

                    SVG Working Group Teleconference

10 Jul 2008

    [2]Agenda

       [2] 
http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0025.html

    See also: [3]IRC log

       [3] http://www.w3.org/2008/07/10-svg-irc

Attendees

    Present
           ed_, aemmons, heycam, anthony, Doug_Schepers

    Regrets
    Chair
           Erik

    Scribe
           anthony

Contents

      * [4]Topics
          1. [5]XHTML Access Module
          2. [6]SVG in HTML5
          3. [7]http://lists.w3.org/Archives/Public/www-svg/2008Jul/0000
             .html
          4. [8]Feed back on SVG 1.1 Errata
          5. [9]Duration of an SVG file
          6. [10]Limitation of Units and propose extension
      * [11]Summary of Action Items
      _________________________________________________________



    <trackbot> Date: 10 July 2008

    <scribe> Scribe: anthony

XHTML Access Module

    ED: I read the review
    ... and I think it's fine
    ... I gave Doug some feedback already
    ... anything else we want to add to the review?
    ... or any comments?

    CM: Not if it's the same stuff we talked about on Tuesday

    DS: Was hoping Chris would read it

    ED: We still have today before it has to be sent off right?
    ... unless there are any objections or comments
    ... we can send this off to the XHTML group

    RESOLUTION: We will send the proposed comments to the XHTML Working
    Group

    DS: So I slipped in parts of my original review
    ... any objections?

    AG: None

    ED: I don't see any major issues with sending off

    DS: I'll send it off now

SVG in HTML5

    <ed_>
    [12]http://dev.w3.org/SVG/proposals/svg-html/svg-html-proposal.html

      [12] http://dev.w3.org/SVG/proposals/svg-html/svg-html-proposal.html

    ED: There have been a few updates to the proposal
    ... clarifications
    ... descriptions on what we want to do
    ... so we updated the first section
    ... requirements
    ... we had a requirement form Marceij about error handling

    <ed_>
    [13]http://dev.w3.org/cvsweb/SVG/proposals/svg-html/svg-html-proposa
    l.html.diff?r1=1.5&r2=1.6&f=h

      [13] 
http://dev.w3.org/cvsweb/SVG/proposals/svg-html/svg-html-proposal.html.diff?r1=1.5&r2=1.6&f=h

    ED: here's the diff
    ... So you can see in the last bit we loosened the requirement a bit
    ... so one of the things I wanted to ask is
    ... how to deal with broken mark up
    ... [reads out what's currently written]
    ... the SVG fragment will show something
    ... then the HTML parser takes over
    ... the question is do we want the broken fragment to show up
    ... or do we want text description to show
    ... so you'd create elements up to that point
    ... and they'd be rendered in some other way

    CM: You could throw them away

    ED: I guess that's possible
    ... I think what we want to avoid is reparsing
    ... this proposal doesn't do any reparsing

    CM: If you open a comment and then don't close it by the end of the
    file it goes back and
    ... reparses it

    ED: That's true
    ... doing reparsing here would be heavier

    CM: Don't know whether to keep them there or throw them away
    ... which way would be the best?

    DS: I'm concerned that if we allow for recovery behavior of well
    form-ness
    ... that's the slippery slope right

    ED: I thought someone mentioned security issues with reparsing of
    comments
    ... can't remember

    CM: Do you say to close all of the elements right back to where the
    SVG started?

    ED: Yes

    CM: The alternative would be to close the element that had the error
    ... and switch to HTML parser
    ... and continue to set elements at that point
    ... ED do you know if you don't get a closed tag for the thing at
    the top what it does
    ... just wondering if we switch to HTML parser straight away
    ... then as you go down the SVG closing tags that might not make the
    tree so bad

    ED: You may end of up with odd close tags

    <ed_> ...arbitrary case close tags is what's odd in this case

    DS: There was some discussion in the HTML group that a UA should
    allow the user to export valid XML
    ... to solve the extraction problem
    ... I could see Inkscape changing for the new parsing
    ... but I couldn't see Illustrator changing
    ... changing SVG so that it's not well formed would mess with the
    model
    ... that's the way it was designed
    ... now errors in values we already have a description for that
    ... for well formness errors it should close off the SVG right there
    ... everything goes into the tree
    ... but is not rendered
    ... so you would like to see something similar to the proposed model
    ... and you would say anything beyond that would not be rendered

    ED: I can see people would have a problem with that
    ... chances are there would be HTML beyond that
    ... so then IE would render HTML pages that are broken and UAs that
    tried to handle the SVG
    ... parts would not render correctly

    DS: Not sure how that follows
    ... so IE wouldn't simply render the SVG unless there was a plugin

    ED: So any browser today would not handle the SVG part
    ... it would handle it as HTML
    ... try to understand any parts that look like HTML

    DS: What about it puts it into the tree but anything past that is
    not rendered
    ... is it should continue to search for a close SVG

    CM: So if don't have a closing SVG element then nothing passed the
    error would render

    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
    ... what happens a snippet of SVG where they didn't close the SVG
    root
    ... and what happens when they don't close the circle and there is a
    rect after that
    ... should the rect be rendered should the circle be rendered?
    ... if there is a star, circle, and a rect
    ... and there is an error in the circle
    ... I say the star only should be rendered

    ED: That's what we are proposing at the moment
    ... after the point in error it's parsed as HTML
    ... if you have fallback content then you'd show the broken SVG and
    the fallback content

    DS: We should try to accommodate the broken content
    ... fallback content for a well formness error

    ED: We should put that in the proposal

    DS: I did
    ... it describes the different types of fallbacks
    ... I think the way it is fine

    ED: Do we have agreement to close the SVG tag?
    ... in the case of well formness errors
    ... to close all the elements on the stack
    ... to where XML parsing began

    DS: There are only a couple of things will look odd if we do this
    ... if there is a font it will rendered as a HTML font

    ED: It would be odd either way
    ... there is one thing you can do
    ... which is prefix the elements

    DS: That's an interesting point
    ... maybe we should mention that something specific in the proposal
    ... as an authoring tip
    ... would you mind doing that?

    ED: Sure

    DS: Most of these elements would do nothing in HTML
    ... only text would do something

    CM: and textArea
    ... and font

    ED: It doesn't do much
    ... I was curious about the font stuff, but it is possible to
    determine the type from the attributes

    CM: Bit hacky

    DS: The whole reason for fallback behavior is to make a best guess
    at what the author intended
    ... in this case I don't think that it's at all outside the spirit
    of that
    ... to render what text you can
    ... and say I don't know what to do with the rest of it
    ... because the author hasn't given enough information to say what
    to do
    ... as an author I would like to see what I've done wrong
    ... and by it not showing is a pretty good indication
    ... we are trying to do the best for the authors

    <scribe> ACTION: Erik to add prefixing of elements with name
    collisions to the SVG in HTML proposal [recorded in
    [14]http://www.w3.org/2008/07/10-svg-minutes.html#action01]

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

    ED: This way you can make sense of them

    DS: We should be careful about how we name stuff in the future

    ED: Do we want to send this off this week?
    ... do we want to add more to it?

    DS: Maybe we can hold off to tomorrow
    ... and if Chris can look at it tomorrow
    ... we could say it's a tentative proposal and that we are
    interested in feedback
    ... form the group and the public
    ... that will allow Chris to respond to it

    AE: There's no guarantee that Chris can look at it tomorrow

    ED: Just because we send it doesn't mean it can't be discussed and
    changed

    DS: It's not a complete proposal but it's close

    ED: I just noticed that there is a section on SVG resources

    DS: I tried putting some wording in there about that
    ... it's related to what Opera and Moz (roc) is doing with SVG and
    HTML
    ... if you can add some stuff that you've been doing would be good
    ... I mean notes and potential things we could do
    ... sort of an informative

    ED: Ok I'll try to flesh that out

    <scribe> ACTION: Erik to send the SVG in HTML proposal to the HTML
    Working Group [recorded in
    [15]http://www.w3.org/2008/07/10-svg-minutes.html#action02]

    <trackbot> Created ACTION-2094 - Send the SVG in HTML proposal to
    the HTML Working Group [on Erik Dahlström - due 2008-07-17].

    <ed_> z

[16]http://lists.w3.org/Archives/Public/www-svg/2008Jul/0000.html

      [16] http://lists.w3.org/Archives/Public/www-svg/2008Jul/0000.html

Feed back on SVG 1.1 Errata

    ED: On set matrix
    ... I went through my actions and I didn't see anything relating to
    this
    ... this is strange one
    ... because we have to change a proposed

    AG: A proposed errata is not an accepted errata
    ... which means we can probably take it back to draft and work on it

    ED: Has anyone else taken a look at this yet?
    ... I tested it a bit
    ... and it seems the values are copied
    ... in Batik and Opera
    ... and the same for create SVG transform matrix
    ... and the last was for consolidate
    ... how do we want to treat the case where we have a list of
    transforms
    ... and we want to consolidate
    ... do we create a new item in the list?

    DS: What do you think will be most intuitive for users?
    ... I don't have an opinion on this
    ... what do implementations do?
    ... should choose the solution that gives the most options

    ED: Opera seems to consolidate to the first item in the list
    ... so if you have a reference to the first item
    ... you don't have to grab a new reference
    ... Do you want to throw away the value you have and do a new one?
    ... that's what's being proposed
    ... I guess doing consolidate on one item is not a good idea

    AG: Is this an edge case?

    ED: Kind of
    ... Would be good to have feed back form CM
    ... I think it's ok to get a fresh transform item in the list

    <scribe> ACTION: Erik to change the proposed errata item and report
    back to the group [recorded in
    [17]http://www.w3.org/2008/07/10-svg-minutes.html#action03]

    <trackbot> Created ACTION-2095 - Change the proposed errata item and
    report back to the group [on Erik Dahlström - due 2008-07-17].

Duration of an SVG file

    <ed_>
    [18]http://lists.w3.org/Archives/Public/www-svg/2008Jul/0015.html

      [18] http://lists.w3.org/Archives/Public/www-svg/2008Jul/0015.html

    ED: I think this is pretty interesting
    ... it's suggesting that we should have a way of specifying the time
    for an SVG fragment
    ... currently we don't have a way of specifying this
    ... if you author a comic you may want to specify how long it runs
    for
    ... using an intrinsic duration
    ... I guess this would be a nice feature
    ... but probably out of scope for Tiny

    AE: In the very early days when people were asking for SVG
    ... they wanted something that was almost like an Animated GIF
    ... so it has a defined duration
    ... someone would have been able to put the exact duration about how
    long
    ... the file runs for
    ... I guess it would be a bit of a burden on the implementor
    ... to figure out how long the animation runs for
    ... I guess the duration at the top of the file would determine how
    long the animation ran for
    ... there was some stuff in SVG Full 1.2
    ... I'd hesitate to put anything in Tiny at this stage
    ... So we've implemented something ourselves
    ... where we calculate the intrinsic duration
    ... but Julien has made some good points

    DS: I would like to respond to him in some way, I would like to get
    some formal resolution from this group

    ED: I think a resolution would be we want to investigate this

    DS: I don't think this is something we want to do in Tiny 1.2
    ... but the idea has merit

    <scribe> ACTION: Emmons to respond to Julien saying that will
    investigate his idea for future versions of SVG [recorded in
    [19]http://www.w3.org/2008/07/10-svg-minutes.html#action04]

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

    DS: So Julien's email goes right along with getting other properties
    of the SVG such as dimensions

Limitation of Units and propose extension

    <ed_>
    [20]http://lists.w3.org/Archives/Public/www-svg/2008Jun/0068.html

      [20] http://lists.w3.org/Archives/Public/www-svg/2008Jun/0068.html

    ED: I read this
    ... and I thought
    ... this would be quite similar to Cameron's constraint stuff

    DS: I mentioned that to him and he mentioned that he didn't want to
    have
    ... to implement a whole new feature set to get this extension
    ... he pointed out a few cases

    ED: If this is sort of syntax is supported in SVG then it would be
    good
    ... for SVG to have this
    ... I think this would also be good for HTML and CSS
    ... they've often wanted to do what he's wanting to do

    DS: I think this is a special case of the constraints syntax

    ED: So I'm only slightly worried that this will be incompatible with
    older UAs
    ... it will be treated as a default value in the older UAs

    DS: A video element will end up looking like nothing

    ED: Just wondering if there is something that is backwards
    compatible

    DS: Cameron did a bit of work on this stuff and thought using a
    child element that would introduce this
    ... you'd give it 50% and then say -10 pixels
    ... not matter what happens you're not going to get what the author
    expected

    ED: But the author could make it such that it looks ok in older UAs
    ... but look better in newer UAs

    DS: So the solution here is switch
    ... have required feature

    ED: That's fine I guess

    DS: Any plugins or modern browsers that come out at this point
    ... would implement this

    ED: I think his extension seems to be less advanced

    DS: But he is trying to cover different use cases to what Cameron
    was
    ... here's what I'd like say
    ... I'd like to start work on the layout module
    ... it doesn't take a lot to start the specification
    ... this could be a feature of that

    AE: His (Roc's) proposal looks good

    DS: I propose we start the layout module
    ... and we add one of these things as his syntaxes

    AE: As long as it doesn't take the focus away from the test suite

    RESOLUTION: We will start the layout module and we will tentatively
    put Roc's suggestion in

    <scribe> ACTION: Doug to create layout the module and email Roc
    [recorded in
    [21]http://www.w3.org/2008/07/10-svg-minutes.html#action05]

    <trackbot> Created ACTION-2097 - Create layout the module and email
    Roc [on Doug Schepers - due 2008-07-17].

Summary of Action Items

    [NEW] ACTION: Doug to create layout the module and email Roc
    [recorded in
    [22]http://www.w3.org/2008/07/10-svg-minutes.html#action05]
    [NEW] ACTION: Emmons to respond to Julien saying that will
    investigate his idea for future versions of SVG [recorded in
    [23]http://www.w3.org/2008/07/10-svg-minutes.html#action04]
    [NEW] ACTION: Erik to add prefixing of elements with name collisions
    to the SVG in HTML proposal [recorded in
    [24]http://www.w3.org/2008/07/10-svg-minutes.html#action01]
    [NEW] ACTION: Erik to change the proposed errata item and report
    back to the group [recorded in
    [25]http://www.w3.org/2008/07/10-svg-minutes.html#action03]
    [NEW] ACTION: Erik to send the SVG in HTML proposal to the HTML
    Working Group [recorded in
    [26]http://www.w3.org/2008/07/10-svg-minutes.html#action02]

    [End of minutes]
      _________________________________________________________


     Minutes formatted by David Booth's [27]scribe.perl version 1.133
     ([28]CVS log)
     $Date: 2008/07/10 12:07:31 $
      _________________________________________________________

      [27] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [28] 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 [29]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/

      [29] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/anything/nothing/
Succeeded: s/ROC/Opera and Moz (roc)/
Succeeded: s/references/reference/
Succeeded: s/gues/guess/
Found Scribe: anthony
Inferring ScribeNick: anthony
Default Present: ed_, aemmons, heycam, anthony, Doug_Schepers
Present: ed_ aemmons heycam anthony Doug_Schepers
Agenda: [30]http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSe
p/0025.html
Found Date: 10 Jul 2008
Guessing minutes URL: [31]http://www.w3.org/2008/07/10-svg-minutes.html
People with action items: doug emmons erik

      [30] 
http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0025.html
      [31] http://www.w3.org/2008/07/10-svg-minutes.html

    End of [32]scribe.perl diagnostic output]

      [32] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Thursday, 10 July 2008 14:31:32 UTC

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