SVG Working Group Teleconference -- 05 Jan 2012

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

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/agenda_proposals

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> 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 http://www.w3.org/2012/01/05-svg-minutes.html#action01]

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

<scribe> ACTION: vhardy to update the May F2F meeting page. [recorded in http://www.w3.org/2012/01/05-svg-minutes.html#action02]

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

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.

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

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

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

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

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> (rmove the SVG element first :))

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 http://www.w3.org/2012/01/05-svg-minutes.html#action03]

<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 2012-01-12].

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

<heycam> http://livedom.validator.nu/?%3C!DOCTYPE%20html%3E%0A%3Chtml%3E%0A%3Chead%3E%0A%3Csvg%3E%0A%20%20%3Cdefs%3E%0A%20%20%20%20%3Cg%3E%3C%2Fg%3E%0A%20%20%3C%2Fdefs%3E%0A%3C%2Fsvg%3E%0A%3C%2Fhead%3E%0A%3Cbody%3E%0A%3Cp%3EHello%3C%2Fp%3E%0A%3C%2Fbody%3E%0A%3C%2Fhtml%3E

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

<cyril> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Consider_allowing_async.2Fdefer_on_.3Csvg:script.3E

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> 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 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SMIL_data_feedback

dirk: what does SMIL data feedback mean?

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

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

<scribe> ACTION: Erik to ask David Dailey to add more details to the requirement: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SMIL_data_feedback [recorded in http://www.w3.org/2012/01/05-svg-minutes.html#action04]

<trackbot> Created ACTION-3196 - Ask David Dailey to add more details to the requirement: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SMIL_data_feedback [on Erik Dahlström - due 2012-01-12].

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SMIL_time_containers

ed: next one http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SMIL_time_containers

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

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.

<ed> 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 <video>

ed: is that for allowing time manipulation.

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

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

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

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

… 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

- DRAFT -

SVG Working Group Teleconference

05 Jan 2012

Attendees

Contents

Sydney F2F

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

May F2F

Allowing select SVG elements in <head>

SVG2 requirements

Summary of Action Items

Scribe.perl diagnostic output