See also: IRC log
<trackbot> Date: 05 January 2012
<vhardy> ScribeNick: vhardy
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.
welcomes from the group :-)
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
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> <!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 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.
<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.
tav: yes.
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
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Heycam// Succeeded: s/Gekko 9.1.1./Gecko 1.9.1/ Succeeded: s/animate/animation/ Found ScribeNick: vhardy Found ScribeNick: heycam Found Scribe: Cameron Found Scribe: Vincent, Cameron WARNING: "Scribe: Vincent, Cameron" command found, but no lines found matching "<Vincent, Cameron> . . . " Continuing with ScribeNick: <heycam> Use "ScribeNick: dbooth" (for example) to specify the scribe's IRC nickname. Scribes: Cameron, Vincent, Cameron ScribeNicks: vhardy, heycam Default Present: cabanier, Doug_Schepers, ed, +33.9.53.77.aabb, +41.83.2.aacc, Tav, [IPcaller], heycam, +61.2.980.5.aadd, cyril|away Present: Rik Doug Cameron Erik Vincent Dirk Tav Cyril Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMar/0001.html Found Date: 05 Jan 2012 Guessing minutes URL: http://www.w3.org/2012/01/05-svg-minutes.html People with action items: erik shepazu vhardy[End of scribe.perl diagnostic output]