- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 06 Jan 2012 08:37:47 +1100
- To: SVG public list <www-svg@w3.org>
Minutes for today's telcon:
http://www.w3.org/2012/01/05-svg-minutes.html
and below as plain text.
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
05 Jan 2012
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMar/0001.html
See also: [3]IRC log
[3] http://www.w3.org/2012/01/05-svg-irc
Attendees
Present
Rik, Doug, Cameron, Erik, Vincent, Dirk, Tav, Cyril
Regrets
Chair
Erik
Scribe
Cameron, Vincent, Cameron
Contents
* [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.
<ed>
[11]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2012/agenda_pr
oposals
[11]
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> [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
[13]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
[14]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>
[15]http://lists.w3.org/Archives/Public/www-svg/2011Dec/0026.html
[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
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
[16]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>
[17]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%3Cbo
dy%3E%0A%3Cp%3EHello%3C%2Fp%3E%0A%3C%2Fbody%3E%0A%3C%2Fhtml%3E
[17]
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> [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.
<cyril>
[19]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#C
onsider_allowing_async.2Fdefer_on_.3Csvg:script.3E
[19]
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> [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
[21]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#S
MIL_data_feedback
[21]
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:
[22]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#S
MIL_data_feedback [recorded in
[23]http://www.w3.org/2012/01/05-svg-minutes.html#action04]
[22]
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SMIL_data_feedback
<trackbot> Created ACTION-3196 - Ask David Dailey to add more
details to the requirement:
[24]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#S
MIL_data_feedback [on Erik Dahlström - due 2012-01-12].
[24]
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SMIL_data_feedback
<ed>
[25]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#S
MIL_time_containers
[25]
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SMIL_time_containers
ed: next one
[26]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#S
MIL_time_containers
[26]
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>
[27]http://www.w3.org/TR/2005/REC-SMIL2-20050107/smil-timemanip.html
[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
<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
Summary of Action Items
[NEW] ACTION: Erik to ask David Dailey to add more details to the
requirement:
[28]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#S
MIL_data_feedback [recorded in
[29]http://www.w3.org/2012/01/05-svg-minutes.html#action04]
[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
[30]http://www.w3.org/2012/01/05-svg-minutes.html#action03]
[NEW] ACTION: shepazu to send SVG social agenda to the
www-svg-wg@w3.org [recorded in
[31]http://www.w3.org/2012/01/05-svg-minutes.html#action01]
[NEW] ACTION: vhardy to update the May F2F meeting page. [recorded
in [32]http://www.w3.org/2012/01/05-svg-minutes.html#action02]
[28]
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SMIL_data_feedback
[End of minutes]
_________________________________________________________
Received on Thursday, 5 January 2012 21:40:55 UTC