W3C home > Mailing lists > Public > www-svg@w3.org > January 2012

minutes, 5 January 2012 SVG WG telcon

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 06 Jan 2012 08:37:47 +1100
Message-ID: <4F06182B.5000503@mcc.id.au>
To: SVG public list <www-svg@w3.org>
Minutes for today's telcon:


and below as plain text.


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

                                - DRAFT -

                    SVG Working Group Teleconference

05 Jan 2012



    See also: [3]IRC log

       [3] http://www.w3.org/2012/01/05-svg-irc


           Rik, Doug, Cameron, Erik, Vincent, Dirk, Tav, Cyril


           Cameron, Vincent, Cameron


      * [4]Topics
          1. [5]Sydney F2F
          2. [6]introducing Dirk Schulze who will represent Adobe on the
             SVG WG.
          3. [7]May F2F
          4. [8]Allowing select SVG elements in <head>
          5. [9]SVG2 requirements
      * [10]Summary of Action Items

    <trackbot> Date: 05 January 2012

    <vhardy> ScribeNick: vhardy

Sydney F2F

    ed: if you have not added your agenda request, now is a good time.
    If we do not manage to fill up on the time, we will use the time for
    spec editing and discussing the requirements.



    heycam: discussing the requirements will take time, but we can
    finish it off. Looking at the remainder of the agenda, we may not
    fill all the time. Probably a lot of us did not have time to do all
    the work they needed to do.

    ed: today is the last day people can register for the SVG F2F.

    <ed> [12]https://www.w3.org/2002/09/wbs/19480/SydneyF2F2012/

      [12] https://www.w3.org/2002/09/wbs/19480/SydneyF2F2012/

    ed: anything more about the F2F?

    cyril: everything should be in order. The hotel is asking about the
    meeting times. I will say 8-9am to 6pm.

    ed: sounds fine to me.

    cyril: when is the SVG event?

    shepazu: then we should finish earlier that day. I'll put you in
    touch with John so that you can get the information.

    cyril: I think I am all set for the meeting.
    ... who is staying at the Novotel?

    vhardy/ed/heycam: we are.

    cyril: I will send an email for the hotel discount.

    shepazu: for the event, here is what John put forward.

    6-6: 30: drinks.

    Talks by Vincent, , Chris and Dmitry.

    <scribe> ACTION: shepazu to send SVG social agenda to the
    www-svg-wg@w3.org [recorded in

    <trackbot> Created ACTION-3193 - Send SVG social agenda to the
    www-svg-wg@w3.org [on Doug Schepers - due 2012-01-12].

    shepazu: there will be a panel session.
    ... I appologize for not being able to attend myself.
    ... the agenda can be tweaked / modified.

introducing Dirk Schulze who will represent Adobe on the SVG WG.

    welcomes from the group :-)

May F2F

    vhardy: the CSS WG decided yesterday to move to Hamburg.
    ... proposes to keep the meeting in Hamburg.

    ed/heycam: yes, makes sense.

    RESOLUTION: The May F2F meeting will be in Hamburg instead of

    <scribe> ACTION: vhardy to update the May F2F meeting page.
    [recorded in

    <trackbot> Created ACTION-3194 - Update the May F2F meeting page.
    [on Vincent Hardy - due 2012-01-12].

    cyril: is anybody from Microsoft or Apply going to attend the SVG
    meeting in Sydney?

    heycam: Jen said she would not be able to attend. I did not hear
    anything about Patrick.

    shepazu: I do not think Patrick will join.

    cyril: what about Apple? Dean?

    vhardy: may be you can reach Dean on the Webkit irc.

    heycam: Doug, what is the current state on Tiling and Mapping task

    shepazu: so far, nothing has happened. We need to be a bit more
    aggressive about it.
    ... the task force has not been started yet. We need leadership
    ... we talked about George Held leading the effort, but I am not
    100% sure. One of the SVG-GIS proponents.
    ... any suggestion on who could lead that.

    vhardy: would Chris Lilley know or have a suggestion?

    shepazu: not sure.
    ... I'll ping Andreas Neuman and see if he has any ideas.


      [15] http://lists.w3.org/Archives/Public/www-svg/2011Dec/0026.html

Allowing select SVG elements in <head>

    ed: this was an old proposal to consider certain elements to be
    placed in the <head> element of HTML. Cameron, do you know if this
    was discussed at any point.

    heycam: not by me. There might have been mails on the whatwg mailing

    shepazu: there are two things requested. One of them is to be able
    to put an svg element in the <head> of an HTML document and put SVG
    content in there. In this case, I would expect the SVG not to render
    because the <head> is not rendered.
    ... this works in most browsers but the validators do not like it.
    Hixie suggests taht the SVG WG categorizes some elements/context,
    some being rendering context and some 'metadata' context.
    ... Then we should discuss the behavior when content is not
    rendered. This seems reasonnable. This is different from SVG
    metadata but that is ok. It should be allowed to have SVG in the
    <head> and it should not be rendered.
    ... The second question is what happens if you only put a <defs>
    section in the HTML <head> element. This is not longer saying that
    this is SVG content. If SVG is one of the fundamental Web content,
    then we could accept that.

    heycam: if you have an HTML document and use the HTML parser, then,
    if there is no <svg> element, the <defs> element is not parsed as
    being in the SVG namespace.

    shepazu: yes, that is the way the parser works. And yes, there is
    relunctance by many people, for various reasons, to change the
    parser at this point. I have heard a proposal that SVG elements
    could be in the HTML namespace.
    ... I think ed suggested that at TPAC.

    ed: I do not remember saying that.

    shepazu: may be someone else suggested it.

    ed: having an SVG element without the surrounding <svg> element is
    hard because it is currently needed to resolve things like

    shepazu: I would contest that view.
    ... that is the case, but if you leave these things out of an SVG
    element, there are lacuna values that kick-in. So the only thing
    that the <svg> element really provides is the namespace scoping. The
    lacuna values provide the behavior that we needed. I think lacuna
    values could apply just like when there is a root but no other
    information. So the scoping argument is not a strong argument I

    ed: I think this is harder than just 'believing' it is there. I
    think you could still have a stub element inserted, but that is
    still a bit of work.

    shepazu: I do not contest the implementation difficulty, but from a
    specification perspective, I do not think it is difficult.

    dirk: we should think about SVG elements fit into the box model of
    CSS. I do not think that defining the bounding box is enough.

    shepazu: may be we should address the first issue first.
    ... we should decide if an <svg> element should be allowed in an
    HTML <head> element. Can we come on a consensus on that?

    ed: is there any browser where this does not work?

    shepazu: the only problem, I think, is that the content does not
    validate. The report says it works in Gekko, WebKit and Opera.
    ... he put an <svg> in the <head> and inside the body of the html,
    he used that first svg in new svg. This seems pretty natual to me.
    ... I think this is pretty common.

    rik: this seems pretty natural.
    ... would foreignObject be allowed in there?

    shepazu: yes, I do not think the SVG would behave any different,
    except that it is not rendered. That seems to be the most consistent
    ... we should ask Hixie what he means by categorizing at metadata?
    ... does anybody have a problem with this idea?

    heycam: the slight reservation I have is that in HTML, there is
    never rendering elements in the <head> element. I am wondering if
    that makes it trickier to implement.

    shepazu: apparently, this is not tricky because it is already

    heycam: the other thing I am wondering is that if we can have a
    foreignObject in the svg in the <head>, you could have a <body>
    element that can interfere with the parser's behavior.

    shepazu: I think that if you have SVG in the body, you can already
    have a similar situation. We could do research ourselves.

    heycam: this may be more involved parser-wise that it sounds.
    ... I think it may have consequences and change the parser. We
    should do some research.

    shepazu: I would like to come to a resolution on this.
    ... Cameron expressed concerns on the implications on the parser.

    <krit> Just for the SVGElement in the <header>. SVG Elements get to
    HMTL elements at the moment for WebKit:

    <krit> <!DOCUMENT html>

    <krit> <html>

    <krit> <head>

    <krit> <svg xmlns:xlink="www.w3.org/1999/xlink">

    <krit> <rect id="test" width="100" height="100" fill="red"/>

    <krit> </svg>

    <krit> </head>

    <krit> <body>

    <krit> <svg xmlns:xlink="www.w3.org/1999/xlink">

    <krit> <use xlink:href="#test">

    <krit> <svg>

    <krit> </body>

    <krit> </html>

    <krit> (rmove the SVG element first :))

    <krit> <!DOCUMENT html>

    <krit> <html>

    <krit> <head>

    <krit> <rect id="test" width="100" height="100" fill="red"/>

    <krit> </head>

    <krit> <body>

    <krit> <svg xmlns:xlink="www.w3.org/1999/xlink">

    <krit> <use xlink:href="#test">

    <krit> <svg>

    <krit> </body>

    <krit> </html>

    heycam: the advantage of having SVG in the head, is that you do not
    need to display=none to have it not show. It is a reasonnable thing
    to want. I think it can work, barring my reservations.

    <ed> should be <!DOCTYPE html>, no?

    <krit> sure, sorry

    <krit> still doesn't work

    shepazu: I propose that we allows SVG in the <head> element of an
    HTML document. We could put that in the SVG 2.0 spec. or in the SVG
    integration spec. We should follow the suggestion by Hixie to
    indicate a metadata mode for SVG inline in HTML <head> elements.

    heycam: I think we need to write something that will change what the
    HTML spec. says and not what the SVG spec. says. This is more of a
    change for the HTML spec. If we can do the change in the integration
    spec. then great.
    ... we need to consult with Hixie to resolve this.

    <scribe> ACTION: Shepazu to coordinate with Hixie on the right
    specification to add allowing SVG content, in metadata mode, in the
    <head> element of an HTML document. [recorded in

    <trackbot> Created ACTION-3195 - Coordinate with Hixie on the right
    specification to add allowing SVG content, in metadata mode, in the
    <head> element of an HTML document. [on Doug Schepers - due

    <ed> ok, I can confirm that the svgs in the <head> do render

    shepazu: reporting on test.
    ... if I put things in a defs, then it hides it. If it is not in a
    defs, then it renders.



    <krit> ed: Let me specify it, first example works, second doesn't

    heycam: the SVG is pushed to the body. I think that is because any
    element that is not recognized as a <head> element is automatically
    closing the <head> element and the result is pushed to the <body>

    dirk: with the surrounding <svg>, the example works, but without the
    surrounding <svg>, it does not work.

    ed: seeing that, I think it would be a little bit bigger change.

    <shepazu> [18]http://jsfiddle.net/WjnSx/

      [18] http://jsfiddle.net/WjnSx/

    shepazu: if you look at the example I just posted, I am surprised
    that it happens that way.
    ... what happens if we make the title below the SVG, then the
    document no longer has a title. Is there something that can only be
    in the head?

    heycam: I think things like <title> get pushed back to the head if
    they appear somewhere else.
    ... after checking, <title> does not do that.

    shepazu: I'll talk to Hixie and Henri Sivonen.

    heycam: the behavior in an XHTML parser is probably different and
    more like what you would expect.
    ... for a feature we intend people to use, we should have the same
    behavior with the HTML or the XHTML parsers.

    shepazu: I checked that if the <title> appears after the <svg> in
    the head, it gets shoved into the body. May be it would still be
    seen as the title.

    rik: yes, it is still showing as the doc title.

    shepazu: yes, I tested hat too.
    ... on the issue of allowing bare svg elements outside an <svg>
    root, I think this is a larger issue that we are going to have to
    solve or not solve.

    vhardy: I think this is the generic issue of svg elements in HTML.

    shepazu: yes, there is not much value in special casing the <defs>
    element to put in an <head> element.

    heycam: if we cannot put non-displayed SVG in the <head>, we would
    still need to provide a way for declaring SVG definitions without
    having to hide the surrounding <svg> element.

    shepazu: I think we agree that we should allow it in the head. If we
    are not going to allow that, there are solutions (e.g., 0x0 SVG).

    heycam: yes, that is true. They can also put it in the <defs>
    section of one of the rendered SVG elements.
    ... I was reverse engineering the reason for his request.

    shepazu: he is trying to separate things into the <head> explicitly,
    because this is what feels right to him.
    ... I think this is what we should optimize for.
    ... I'll email the list and cc Hixie and Henri. We may put it in the
    HTML5 spec, the SVG integration spec. or the SVG 2.0 spec.

    ed: if we do not have any other agenda item requests today, lets
    continue with SVG 2.0 requirements.

    heycam: before we move to that, Tav: what is the current state of
    the 2.0 document.

    tav: it works :-)

    heycam: is it in a state where we can start adding in the new
    features we are talking about. There will be some global editing of
    the HTML file.



    tav: yes.

SVG2 requirements

    ed: back to requirements.

    heycam: async/defer on <svg:script>
    ... I have mixed feelings. On one hand it is good to have the same
    behavior as HTML. On the other hand, these are legacy things that
    people do not use or are they things people do use today?
    ... I think we should ask the HTML group whether it is a good idea
    or not.

    shepazu: async is new in HTML5.

    heycam: ok, I was not sure.

    shepazu: I am pretty sure async was new in HTML5.

    <shepazu> [20]https://developer.mozilla.org/En/HTML/Element/Script

      [20] https://developer.mozilla.org/En/HTML/Element/Script

    shepazu: I am not sure when defered was added.

    vhardy: does it make sense ot only add async?

    shepazu: defer is at least as old as Gecko 1.9.1

    heycam: I retract my relunctance.
    ... Jonas Sicking also says this should be supported.

    vhardy: where do the accepted requirements showing?

    RESOLUTION: accept "consider allowing async/defer on <svg:script>"

    ed: next one is


    dirk: what does SMIL data feedback mean?

    shepazu: I think it means being able to find the current position of

    ed: the request is not clear enough to be discussed.

    <scribe> ACTION: Erik to ask David Dailey to add more details to the
    MIL_data_feedback [recorded in


    <trackbot> Created ACTION-3196 - Ask David Dailey to add more
    details to the requirement:
    MIL_data_feedback [on Erik Dahlström - due 2012-01-12].




    ed: next one


    vhardy: I guess that depends on the convergence work we do on

    ed: is there any resolution so far on convergence?

    vhardy: not that I am aware of.

    heycam: I am relunctant to take on new requirement without knowing
    what our broad direction for animation is.

    cyril: this is not only about animation, it is also about other
    timed elements.


      [27] http://www.w3.org/TR/2005/REC-SMIL2-20050107/smil-timemanip.html

    cyril: we started to discuss time containers on audio and video.
    Chris was not happy we decided to align with the HTML5 <audio> and

    ed: is that for allowing time manipulation.

    cyril: the first step is to allow different timelines in the

    vhardy: could the requirement be just around 'time containers' (and
    not specifically SMIL)?

    cyril: what we want the resources in a document to be on a different
    timeline, not the elements.

    heycam: there are different aspects to time containers.
    ... there are two examples. One is <par> and <seq> elements. The
    other is multi-media elements having their own timelines and
    synchronizing with that.

    shepazu: I like the general approach vhardy is proposing that we
    resolve that we want a form of time containers without going into

    cyril: I think resolving to have time containers in not precise

    <heycam> ScribeNick: heycam

    <scribe> Scribe: Cameron

    vhardy: my point is we already have multiple timelines in svg, with
    audio and video elements

    … you have the main animation timeline, the <svg> is a time

    … if it's playing <audio> and <video> they have their own timeline

    cyril: we don't have them in SVG2 yet

    … they're in 1.2T, yes

    vhardy: but we agreed to have them?

    cyril: the requirement doesn't say if they follow the timeline of
    the document or have their own

    vhardy: we could say we want facilities to sync the timelines of the
    multimedia resources with the document

    … but that's different from being able to start and stop, and have
    completely separate timelines

    … rik could talk more about this, but if you want to have a little
    walking character if you had nested timelines you could easily have
    a character you could start and stop and manipulate

    cyril: that's movie clips in flash

    … you could have that in svg by using a separate document and using
    <animation> to reference it

    heycam: brian will be talking animation at the F2F

    <scribe> Scribe: Vincent, Cameron

Summary of Action Items

    [NEW] ACTION: Erik to ask David Dailey to add more details to the
    MIL_data_feedback [recorded in
    [NEW] ACTION: Shepazu to coordinate with Hixie on the right
    specification to add allowing SVG content, in metadata mode, in the
    <head> element of an HTML document. [recorded in
    [NEW] ACTION: shepazu to send SVG social agenda to the
    www-svg-wg@w3.org [recorded in
    [NEW] ACTION: vhardy to update the May F2F meeting page. [recorded
    in [32]http://www.w3.org/2012/01/05-svg-minutes.html#action02]


    [End of minutes]
Received on Thursday, 5 January 2012 21:40:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:33 UTC