- From: Cameron McCormack <cam@mcc.id.au>
- Date: Thu, 28 Jul 2011 17:44:11 -0700
- To: www-svg@w3.org
- CC: public-svg-wg@w3.org
The HTML minutes for the Seattle F2F day 2 are at:
http://www.w3.org/2011/07/27-svg-minutes.html
but have unfortunately been merged with yesterday's minutes. Below is
the text version of just day 2.
Present: Cameron McCormack, Erik Dahlström, Vincent Hardy, Doug
Schepers, Brian Birtles, Tab Takins Jr., Cyril Concolato, Rik Cabanier,
Jennifer Yu, Anne van Kesteren, Chris Lilley (phone), Jonathan Watt (phone)
Chair: Erik
<switch> in SVG 2
<jwatt> sure
<ed>
[53]http://lists.w3.org/Archives/Public/www-svg/2011Jun/0039.html
[53] http://lists.w3.org/Archives/Public/www-svg/2011Jun/0039.html
ED: switch in SVG is not very useful as its' designed, because if
you introduce new SVG elements in say SVG 3, the requiredFeatures
attribute will not be seen on that elemnet, because it's not
recognised as an SVG element
... which is something I found a bit weird, it's kind of not very
cleverly designed in that sense
... so I had a few questions on what to do with that
... what we want to decide for switch in SVG 2, either deprecate it
or fix it somehow
... in my example, I show a few different cases
... one would be a newly introduced element
... one woudl be a custom element, maybe that just one UA implements
experimentally
... and because of the requiredFeatures just being in the null
namespace, it's not recognised
... and it's not switchedo n
s/o n/ on/
scribe: in my case I wanted to use it on video elements, but since
the video element from 1.2T is not recognised as an SVG element it
didn't work
... you cannot currently have a 1.2T video element with switch, and
then fallback to a foreignObject with html:video
DS: you could nest it in a group
... it's a kludge, but I agree
ED: another aspect is what to do with non-chosen subtrees
... currently we don't really say what's supposed to happen with
those
... but in some cases we get behaviour just from ebing in the
document
... audio elements might start playing
... which can be a problem
DS: I thought we resolved at some point that "rendered" could mean
that audio doesn't play
ED: I think the larger question is what we want to do with the
switch element
... do we still want to keep it around, and if so, how should we fix
it?
VH: can you give an example of what you would do with a new element?
ED: say SVG 2 introduces a new element foo
... and we add a new feature string for that
... so we put requiredFeatures="string" on taht element
... in UAs that don't support that new foo element, it won't
actually pick up that requiredFeatures attribute
... it's seen as not have a requiredFeatures
CM: so it doesn't look for a DOM attribtue requiredFeatures, but
because it doesn't implement SVGConditionalSomething?
VH: so the processing model of switch currently is to find the first
element in the switch, and if you understand that element and it
passes the attributes, then you use it
DS: it seems particularly ill designed
VH: originally switch was introduced to help with progressive
implementation of the spec
... so authors could do some animation in UAs that didn't implement
animation yet
CC: would it help to have requiredFeatures in an SVG namespace?
ED: how do we want to proceed?
DS: you could put it on a g
BB: what about failing unknown elements?
CM: you could just force it to look at that attribute in the null
namespace, regardless of the namespace of the unknown element
ISSUE: define switch to work with unknown elements and processing
behaviour for audio elements etc
<trackbot> Created ISSUE-2422 - Define switch to work with unknown
elements and processing behaviour for audio elements etc ; please
complete additional details at
[54]http://www.w3.org/Graphics/SVG/WG/track/issues/2422/edit .
[54] http://www.w3.org/Graphics/SVG/WG/track/issues/2422/edit
Starting on SVG 2
JW: basically I've been mucking around with a website we can use as
a staging server to be able to get mercurial hooks
... I've given up on the w3c systeam to have the resources for that
... so I'm using this server as a staging thing which can do a bunch
of checks, before passing it on to the w3c hg repo
... I started a wiki page
<jwatt> [55]http://www.w3.org/Graphics/SVG/WG/wiki/Svgwg.org
[55] http://www.w3.org/Graphics/SVG/WG/wiki/Svgwg.org
DS: why was this necessary?
JW: for the mercurial hooks section
CM: [explains the hooks]
JW: we could make it so that when successful changesets get pushed,
that it pushes it to the w3c server automatically
ED: how much of a problem would it be if we pushed to the w3c repo?
JW: it would be a pain
... this is one of the things I was going to bring up
... if we want to deal with this system that allows checks and
things, it might be a good idea to have a special key for svgwg.org
so that it's the only person pushing to the official server once the
changeset has passed the checks
... but you're right we don't want to have to merge
... if one person pushes in one place and others in the other
DS: how hard was it to do those hooks?
JW: to write them, I didn't really know anything about it before
... took me a few days to work out
... but it's easy now that I've looked at some examples
DS: do you think this initial infrastructure would be difficult for
the w3c team to install?
JW: the thing they're not happy about is that hooks are basically
scripts that run on the server
... and they don't trust anyone to be pushing random stuff
... not that people would be malicious, but if they make a mistake
in their hook and it makes something bad on the server, or whatever
... so they would want to review the hooks every time we made a
change to them
... at least in the early stages that might be frequent
DS: so the idea is that we develop our system, get our hooks in
place and then we could maybe deploy it on the w3c site?
JW: yes, perfectly possible
DS: long term, it seems having this weird redirection is ...
ED: I think it would help to be able to expierment with checking
systems for the spec itself
... I use that for my site, for example
... catching errors before allowing pushing to the server
DS: ok, that's cool
JW: one of the main things I want to sort out from the start is line
ending changes getting pushed
... one of the things that hg has to stop trashing their diff and
trashing hg blame/annotate, is an extension that lets you have a
file with patterns in it, say files ending in .txt are text files
... and .whatever is binary files
... and also certain files that are fixed unix or windows line
endings
... so you clone the repo, and when you check out the working copy
on the machine, it autoamtically converts normal text files to those
you have on your machine, so you can work in your normal text editor
... so you won't screw up the diff when committing due to the line
ending differences
<jwatt> [56]http://www.w3.org/Graphics/SVG/WG/wiki/Mercurial
[56] http://www.w3.org/Graphics/SVG/WG/wiki/Mercurial
JW: some of you already have an hgrc file in your home directory
... if we're going to use this ul extension, it would be good to
have all these lines in your config file
... that page tells you where to put your config file and what to
put in it
<cyril> s/ul extension/eol extension/
JW: as far as users are concerned, that's all you need to do
<jwatt> [57]http://mercurial.selenic.com/wiki/EolExtension
[57] http://mercurial.selenic.com/wiki/EolExtension
JW: that's the documentation if anyone wants to look it up to set
particular line endings for some files
... so one of the hooks on the server checks for line ending changes
and blocks the push if someone screws them up
DS: I'm trying to compare my existing hgrc file with yours
... I'm wondering what the key parts to change are
JW: the important parts are the [eol] section
... and in the [extensions] section, the "hgext.eol =" line, which
is the line that enables the extension
... the extension comes bundled with hg, so there's nothing to
install, it just enables it
s/it just/that line just/
DS: is 1 and True the same thing?
JW: I imagine so
... tbh I would suggest adding all of these to your config file
DS: so everyone who's planning on committing, let's add this config
now
JW: so basically, in terms of the repo, I went ahead and imported
the Second Edition files
... but I split things up a bit
... any files that are generated are no longer in the repository,
they will just be created locally on your machine
... the .hgignore file that comes with the repo will make the build
directory ignored
... and I split the tools directory out, since I discovered there's
quite a bunch of tools down the cvs repo that were required
ED: the generated files, that includes the publish directory?
JW: I've made the builds create a directory build/publish/
... all files generated that aren't published go in build/
... and the stuff in build/publish/ would be zipped up, whatever
ED: is it fine to have this kind of set up?
... currently it seems everything on the w3c site is on some kind of
version control system
... everything that's public
... but can we have the publish/ directory something that is
generated on the w3c server?
JW: what I changed is that instead of having master/ and publish/ at
the root, we have a . and a build/publish/
... and erik is asking whether the w3c servers will have a problem
with build/publish/ not being in version control
<jwatt> what's the code?
DS: would we not have somewhere to point the public to?
JW: it would be easy to have a hook on svgwg.org to publish the
generate spec there
... maybe that could be done on the w3c server
DS: couldn't you check it in somewhere on the w3c server?
ED: we could have a hook on the svgwg.org server, that syncs the
build version or checks it in somewhere else
DS: that would be a feature
CM: it could be checked in to www.w3.org/Graphics/SVG/
JW: or a separate repo on dvcs.w3.org
DS: we should consider whether this infrastructure could be
generalised to other WGs in the future
JW: fwiw I just checked, on my machine the master directory is a
quarter of the size compared to having the publish directory in
there too
DS: ok
JW: for the moment, I've pushed these repos up to a sandbox on
svgwg.org
<jwatt> [58]https://svgwg.org/hg-sandbox/jwatt/svg2/
[58] https://svgwg.org/hg-sandbox/jwatt/svg2/
<jwatt> [59]https://svgwg.org/hg-sandbox/jwatt/svg2-tools/
[59] https://svgwg.org/hg-sandbox/jwatt/svg2-tools/
JW: you could just check those two out side by side, then run make
inside the svg2 directory
... starting with the tools repo
... first change is I added the hgeol file for the eol extension
<jwatt> it's saying the conference is restricted
jwatt, do you want to try skyping in to one of us here directly?
<vhardy_> jwatt, what is your skype id?
vhardy_ will place his laptop in the middle of the table
<jwatt> msg username
jwatt, vhardy_ will just try to set up a conference bridge here,
might be better actually
<jwatt> ok
<vhardy_> jwatt, can you call 408-536-9900 (code: 5108463, pwd:
20112011)
<jwatt> calling
<vhardy_> there is a UK number +44 208 606 1105
<jwatt> no
<jwatt> it's reading options
<jwatt> this isn't working
<jwatt> vhardy: I think it's empty
<vhardy> what isn't?
<jwatt> the meeting
<jwatt> it seems to thing I'm in
<jwatt> but is reeling of a list of numbered options
<vhardy> you should not get the options.
<vhardy> Let me try to restart the conf and then you can dial in
again. ok?
<jwatt> ok
<vhardy> you can dial in now.
<jwatt> [60]https://svgwg.org/hg-sandbox/jwatt/svg2/rev/4367b97a680a
[60] https://svgwg.org/hg-sandbox/jwatt/svg2/rev/4367b97a680a
<jwatt> see comment at top in the meantime
JW: I copied 4 directories from CVS and a few files and put them in
the tools repo
... I just want to check to see if it's ok
... I annotated it r=WG as if we have approved it
<jwatt> argh, it's interupted me to read more options
JW: the hooks are actually managed in the repo itself
<jwatt> [61]https://svgwg.org/hg/svg-repo-hooks/file/tip
[61] https://svgwg.org/hg/svg-repo-hooks/file/tip
JW: the hooks are there
... everyone who has access to the server can access those hooks
... so all the hooks are in the hooks.ui file
... and hg is told which ones of those to actually use in the hgrc
file there
... let's look at the svg2 repo
... the comment at
[62]https://svgwg.org/hg-sandbox/jwatt/svg2/rev/4367b97a680a
indicates which directories and files are gone compared to the 1.1F2
repo in CVS
... I was also wondering if there was a few other files we could get
rid of
... one of those is master/copyright-notice.html
[62] https://svgwg.org/hg-sandbox/jwatt/svg2/rev/4367b97a680a
CM: that's a vestige, you're fine to remove that
JW: the other one was master/indexlist.html
... which is mentioned in publish.xml but doesn't seem to get used
... I'll take that out too
... also master/names.html
CM: don't know why that's there
JW: ok, those were my main questions
... one thing I would note is that the relaxng directory I haven't
added yet
... it seems to have 1.2T stuff and 2.0 stuff according to a
comments
s/comments/comment/
scribe: we can always add it in later
CM: I think we should wait until murata-san has done the rng for
1.1F2, and start from there
JW: the third commit was just me fixing build scripts and things
... and any other files so that make would work with the tools
directory where it is now
... if you check them out side by side, you should be able to build
... so don't pull those repos, I'll create new ones without those
files we mentioend
... should I then push them into svgwg.org/hg/svg2/?
CM: please mail the WG list once the repos are set up in their final
position, and list instructions for us to build the spec
shepazu,
[63]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2/Specification_author
ing_guide
[63]
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2/Specification_authoring_guide
CM: how we will review patches? attach them to bugs?
<jwatt> [64]https://svgwg.org/hg/svg-repo-hooks/file/tip/hgrc
[64] https://svgwg.org/hg/svg-repo-hooks/file/tip/hgrc
JW: not sure, we do have a bugzilla instance
<shepazu> s/hook/höök/
JW: don't know how useful the review will be in the end
[we review the hooks listed in the hgrc file]
<ed> --- 15 min break ---
<ed> ok, so we moved some topics around today
<vhardy> ScribeNick: vhardy
path extensions
<heycam>
[65]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Path_data_turtl
e_graphics_proposal
[65]
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Path_data_turtle_graphics_proposal
heycam: some things are hard to do.
... one is to have a part segment at a particular angle.
... turtle graphics type commands would be a lot easier.
... it would solve a usability problem. It would also make animation
easier.
heycam shows a segment as in
[66]http://www.w3.org/Graphics/SVG/WG/wiki/File:A2.svg
[66] http://www.w3.org/Graphics/SVG/WG/wiki/File:A2.svg
scribe: it is not easy to animate that segment properly to rotate
around the elbow.
... with the proposed value, animating the single rotation value
would be sufficient
... shepazu wanted to talk about a simpler arc command.
... my proposal and a simpler arc command would make doing things
like pie charts a lot easier.
... in the wiki page there are two different proposals.
... the first proposal adds new path commands (r and R)
R would set an absolute degree value.
r would set a relative rotation
f would be a straight line from the current point using the current
rotation angle, for a given length (see wiki).
f would always be relative
scribe: with this proposal, can only do straight line segments.
... Second proposal is to not introduce an f and modify existing
path commands to say that they may be subject to the rotation angle.
e.g., M 0, 0 h 10 r 45 ~ 10
(discussion on what r45 L 100 200 would mean)
shepazu: adding an implicit rotation in the path command that
influences the following commands can be confusing.
heycam: the default rotation is the tangent to the curve at the
current point.
shepazu: what if we had syntax like r 15, 10 (rotate 45, length 10)
(going over the second example)
shapazu: there was a discussion about extending the path syntax
v.s., doing a super path.
heycam: I think there it is better to extend the path syntax.
(discussion about similarity to adding paint servers to SVG with the
image values)
vhardy: I think the feature is very valid.
shepazu: let's take a pie chart use case.
(discussion about pie segments, showing different people have
various ways of thinking about them).
cyril: there was improvements for SVG 1.2.
shepazu: may be we should not touch the path syntax at this point.
<TabAtkins_> TabAtkins_: <path><segment transform='...' d='...'
/><segment .../></path>
heycam: the behavior for syntax error is precisely defined, so this
is not introducing a new risk.
shepazu: then you have things that are poorly drawn.
heycam: it would be the same with other solutions.
shepazu: but you could switch to an alternate content.
heycam: with this too.
shepazu: you are right, we are going to extend SVG, so we are going
that have this in multiple areas.
<cyril> CC: I was talking about:
[67]http://www.w3.org/TR/2004/WD-SVG12-20041027/vectoreffects.html
[67] http://www.w3.org/TR/2004/WD-SVG12-20041027/vectoreffects.html
shepazu: I was thinking about adding a <shape> element.
heycam: should we think about having a new way to extend the path
syntax and not change the <path> element.
shepazu: I am uneasy about it, but I do not have a good alternate
solution.
tab: I think we can add to the syntax and not create problems we
would not have otherwise.
... that argument applies to anything you could add.
... <shape> wont help that issue.
shepazu: I think we may get an adverse reaction to changes to <path>
heycam: may be the expectation was there that we would not change
the path syntax.
vhardy: what about having an API for the feature?
heycam: it would not help for the declarative animation use case.
shepazu: I think the use case is valid.
(discussion about the ~ proposal).
cyril: could it be that after the rotation command, then it affects
everything that comes after it. No need for a ~
(general agreement that this is better)
vhardy: how do you get back to the current tangent if you have
modified it?
heycam: not currently possible in the proposal.
(discussion on how to address that).
<scribe> ACTION: heycam create a proposal where the R/r commands
impact the following commands (until the next r/R command occurence)
and add a way to set the rotation to the current tangent on the
path. [recorded in
[68]http://www.w3.org/2011/07/27-svg-minutes.html#action13]
<trackbot> Created ACTION-3084 - Create a proposal where the R/r
commands impact the following commands (until the next r/R command
occurence) and add a way to set the rotation to the current tangent
on the path. [on Cameron McCormack - due 2011-08-04].
cyril: it would be good to have a list of changes we want to path.
... last year, we presented use cases at SVG Open. e.g., the ability
to compose path, concatenate, reverse.
... I will send a link to the paper.
<cyril> perso.telecom-paristech.fr/~concolat/SuperPathSVGOpen.pdf
<cyril>
[69]http://perso.telecom-paristech.fr/~concolat/SuperPathSVGOpen.pdf
[69] http://perso.telecom-paristech.fr/~concolat/SuperPathSVGOpen.pdf
<heycam>
[70]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements
[70] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements
<heycam> cyril, you can add dot points to that "Path improvements"
section there?
Catmul curves
<shepazu> [71]http://schepers.cc/getting-to-the-point
[71] http://schepers.cc/getting-to-the-point
shepazu: look at the pictures
... if you mouse over the line, you see the actual Bezier curve
control points. It is not intuitive.
... this is a lot of control points.
... you can see that if you add the proposal, the path is a lot
simpler.
... I could use 'P' instead of 'R'
... if you look at the Update 3 example, you can see a comparison of
spiro curve and catmull-rom curve.
... the catmul version just has a few more segments, but you have
more control too. And I added line to segments.
heycam: are Spiro curves much more complicated.
shepazu: if you mouse over the curve, you see the spiro curve
control points.
... spiro curves make very nice curves, slightly unpredictable.
... the key essensece of catmull rom, all the points are on the
curve.
... there is also a tangent parameter which I ommited.
<heycam> ScribeNick: heycam
<scribe> Scribe: Cameron
shepazu: I think it makes it harder to use with the tension
parameter
s/tangent/tension/
s/ommited/omitted/
scribe: I think authors would rather not think about that, and just
want some smooth path through the points
<vhardy> ScribeNick: vhardy
shepazu: the tightest tension parameter makes line segments, the
losest one make swoops.
... if you look at the "Awesomeness of SVG path Element" figure, you
see how there is no line segment. If you want line segments
... you can splt the Catmull-Rom command and add line commands.
ed: if you just want the points, why not add to polyline?
shepazu: because you may want to mix it with other path segments.
... I was currious if you needed extra parameters for each of the
points.
... you might if you wanted to control the tightness per point. You
would need three numbers per point.
ed: the syntax is easier to modify on polyline.
shepazu: this is really easy if you just want to use Catmull-Rom.
heycam: people have wanted 'point on a path' for a while.
... my only concern is the default tension.
<ed> s/the syntax is easier/the syntax and SVG DOM is a bit easier/
shepazu: I chose a default tension, but we could wait for
implementation feedback.
heycam: I am wondering if different kinds of paths would benefit
from different tension parameters.
vhardy: I agree. I think it is fine to have a default for the
tension, but we should have a way to control it.
(some agree).
tab: you could specify a tension in a command.
shepazu: you could have something like
... P <tension> <list of points>
vhardy: but then it is not per point.
shepazu: if someone wants to implement it and provide suggestion for
syntax, that would be fine.
heycam: none of the existing path commands have optional arguments,
so we do not have a syntax for that, like a slash /
tab: I think we could go by fine with a default tension.
shepazu: you could have P t (x, y)+
vhardy: that is still for the whole curve.
shepazu: I think that is the most common case.
... if you want to vary the tensions, you create different curves
but you still have the issue at the connecting points where there is
a different tension before and after.
... having an initial tension may be a [0, 1] parameter instead of
the actual range in the Catmull Rom formulas.
RESOLUTION: we will add a Catmull Rom syntax to the path syntax with
a tension parameter to control the whole curve (not per-point
control).
<scribe> ACTION: shepazu to make a Catmull Rom editor that takes
variable tension parameters. [recorded in
[72]http://www.w3.org/2011/07/27-svg-minutes.html#action14]
<trackbot> Created ACTION-3085 - Make a Catmull Rom editor that
takes variable tension parameters. [on Doug Schepers - due
2011-08-04].
shepazu: for the tension at the junction between P curves, we could
have an optional end tension for the last point on the curve.
... P t (x, y)+ (t2)
<cyril> s/(t2)/(t2)?/
Capturing previous resolution.
RESOLUTION: we will add a path rotation command.
chrisl: how is this going to work in existing SVG 1.1 content.
chris: why not add a new element with these commands instead.
chrisl: what is the advantage of appending to the path command.
... I want to make sure that we considered this?
heycam: we had a discussion about this.
... if you want a reasonnable behavior on all implementation, you
would use a <switch>/requiredFeature.
chrisl: I just wanted to make sure this was a concious decision.
heycam: yes, it was a conscious decision.
... a new element means that you get a marginal difference in the
loss of functionality in ua that do not support the new behavior.
And it would be confusing to authors to use different elements for
different path commands.
chrisl: another element might still be easier/better. Have you
considered it? We could also add NURBS.
... similarly for perspective transform, we would have something odd
if some part of the curve can be subject to it (NURBS) and others
not (Beziers).
shepazu: I had similar objections. We need to be ready to justify
it.
... anything we add should be normalizable to SVG 1.1 syntax.
... we could provide utilities or algorightms for the conversion.
heycam: I think that is a good idea.
chrisl: yes, and authoring tools could also offer that as an option
and include a switch between the new and old syntax.
cyril: we did not talk about the verbosity aspect. Path commands are
compact. Adding elements is move verbose.
heycam: I think there is still room for new path commands and the
things you were suggesting.
chrisl: we need both the spec. and scripts providing the equivalence
between the syntaxes (additions and old path syntax).
heycam: we have agreed to work on the SVG graphics API.
... we did not discuss the switch for these new features.
<cyril> s/move verbose/more verbose/
shepazu summarizes the earlier discussion on <switch>
ed: there was no resolution on that issue.
cyril: the behavior of <audio> on switch is defined in SVGT 1.2 and
we should port it to SVG 2.0.
heycam: what does display:none do for audio and video in HTML5?
anne: nothing. No effect.
tab: if you dont want it to play, you don't put it in the document.
(discussion on audio and video in HTML5).
LUNCH BREAK
<shepazu> ACTION: shepazu to suggest audio-volume control properties
to CSS WG [recorded in
[73]http://www.w3.org/2011/07/27-svg-minutes.html#action15]
<trackbot> Created ACTION-3086 - Suggest audio-volume control
properties to CSS WG [on Doug Schepers - due 2011-08-04].
<ed>
[74]http://www.w3.org/TR/SVGTiny12/multimedia.html#AudioLevelPropert
y
[74] http://www.w3.org/TR/SVGTiny12/multimedia.html#AudioLevelProperty
<ed> ACTION-3086:
[75]http://www.w3.org/TR/SVGTiny12/multimedia.html#AudioLevelPropert
y
[75] http://www.w3.org/TR/SVGTiny12/multimedia.html#AudioLevelProperty
<trackbot> ACTION-3086 Suggest audio-volume control properties to
CSS WG notes added
<ed> 1 hour
<shepazu> [76]http://schepers.cc/svg/path/dotty.svg
[76] http://schepers.cc/svg/path/dotty.svg
<ed> [77]http://www.imdb.com/title/tt0137523/quotes?qt=qt0479254 ?
[77] http://www.imdb.com/title/tt0137523/quotes?qt=qt0479254
<birtles> ScribeNick: birtles
Easier integration of HTML into SVG
TA: If we could abandon XML it would be really easy
VH: I've done a write-up covering both directions
<ed>
[78]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/H
TMLinSVG
[78]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011/Agenda/HTMLinSVG
<anne> doug
VH: The reason I bring this up is author convenience
... to match expectations
... I believe the issues we have can be fairly easily overcome
... this is pretty well implemented currently wrt to foreignObject
... the only the thing foreignObject does is provide an initial
viewport
... in the last e.g. if you specify the containing block/viewport
then that's all you need to apply the box model
... for the opposite direction (SVG in HTML)
... it's useful, e.g. to put a circle in a cell
... but it doesn't appear in the middle
... the gist of this here is to say if you have an SVG element
that's not in an <svg> then it should follow regular HTML
formatting, the box model
... in this example, if I had x/y it would be handled differently
... if you have an SVG element which is not <svg> then it becomes
part of the box model
CM: rather than adding a new attribute on div can be just use
left/height etc.?
VH: I don't think you can because they will reference the nearest
containing block
CM: you want to values to be in SVG co-ordinate space
... so you can just interpret them as SVG would
CL: that's why we have foreignObject
... to deal with that mapping
AK: I think you need to keep it
VH: I think you need to keep the handshake
CL: It's defining two--the SVG space and the CSS canvas and mapping
the two together
VH: The first case, my proposal is to provide a shorthand for what
foreignObject does
... it's just a matter of syntax
<cyril>
[79]http://dev.w3.org/SVG/modules/integration/SVGIntegration.html
[79] http://dev.w3.org/SVG/modules/integration/SVGIntegration.html
AK: If you want to introduce a new attribute you'd have to extend
HTML as well
<ed>
[80]http://dev.w3.org/SVG/modules/integration/SVGIntegration.html#fo
reignobject
[80]
http://dev.w3.org/SVG/modules/integration/SVGIntegration.html#foreignobject
VH: My real question is, I think it would be nice to have a
shorthand
... it seems unnatural to me to have this kind of overhead
... I think it's very natural to want to integrate text into your
graphics
... you should be able to do that simply
CL: foreignObject also makes the content display
<ChrisL> because svg says that foreign namespace stuff mixed in is
okay and does not display
CM: it the past mixing SVG and HTML was a kind of extension feature
but now its commonplace
VH: The naming now seems inappropriate "foreign" object
AK: you could add an "html" element in SVG
CM: if you're going to do that, then you may as well drop the
requirement for a container element
TA: the reason we require the <svg> root in HTML is because of
namespaces
... I suspect the same problem occurs in reverse
CM: e.g. <font>
AK: In the e.g. (in the doc) the <div> would end up in the SVG
namespace
<ChrisL> so it sounds like te current html5 spec does it the right
way and the namespaces come out the right way.
<ChrisL> if we added an html element in the svg namespace, as an
alias of foreignObject, it would not work in html5
AK: to escape from HTML you need <svg> or <math>, to escape <svg>
you need <foreignObject>
... the problem is you need to establish a bounding box in SVG
CM: so it's not a parser problem
TA: it shouldn't be
DS: Can html add x/y/width/height to the root?
... or use CSS to establish the viewport of the html
VH: so instead of the containing-block attribute you use CSS
... so it's a new property for establishing the viewport, not just
left/top
... you need to define which viewport you're going to define your
element into
... you need the rectangular viewport you're going to put it into
<ChrisL> anne: if you had two divs following each other they would
make two canvases
CM: just use the top/left/width/height props to specify the SVG
coordinate space for rendering the HTML
... and that's also the width/height of the CSS box
... need to consider interaction with max-width/height
TA: I think you should be styling the box directly
VH: one thing is to size the box, but foreignObject also defines
which box you're going to layout into
TA: we can just define how the absolute positioning model means in
SVG
... what is the reference box there
VH: even the static positioning, if I just have a div what does 100%
mean?
TA: we can assume it's absolutely positioned
VH: the computed value of the position property would be static
TA: svg|* > html|* { pos: abs }
AK/CM: I don't think we need to force it to be absolute
AK: but we have to define how width/height works
VH: if you look for a CSS block in SVG it's only the <svg> element
s/block/box/
<ChrisL> I think the problems introduced by removing fO are worse
than the current situation
AK: CSS requires a root element
... so it's difficult if e.g. you have two paragraphs
CM: so you'd have to specify the behaviour
AK: it's not been specified yet
CL: I think it's a bad idea, I understand the motivation but I think
it introduces more problems
... SVG has a lot of mention of the containing element, rootmost
element etc.
... if you remove that you lose the definition of units and
introduce all sorts of other problems
... yeah you have to type fO etc. but it all works
... both of these changes require the html parsing to change
... would introduce CSS problems
... I don't think it would work
CM: we wouldn't half solve the problem, we'd have look at all the
implications and tricky cases
... we just have to look at it carefully
DS: what we have now works, but if we introduce different syntax
there'll be a transition period where it won't work
... but people with SVG-capable browsers are generally only the
latest version and getting updates
s/only/on/
scribe: if we're going to do this we should do it soon
... especially before new releases of IE (after version 8)
... 8
VH: from a user's point of view
... if you want to do any business graphics, every time you want to
do a paragraph of text you have to wrap it in fO
... and compare that with a single line of text
... which you can just drop in
... functionality-wise it's odd that we don't have this yet
CM: it makes the platform look less cohesive that you have to do
that
... presuming that parser changes are OK
TA: switching over to using html directly should cause no problems
... it's symmetrical with what we do with svg in html
... people have been doing that for a long time
DS: it wasn't that common, there were just a few obscure platforms
TA: We can ask about that parser change from the point of the HTML
parser
AK: The proposal is to embed any html element
TA: embedding svg/math in html is easy, we can control the size of
it using things in those elements
... in the reverse situation we don't have that information
... because x/y aren't valid html attributes
... in the SVG case at the min. we'd need the HTML root to take x/y
... if you're within the SVG model you need to use the SVG
positioning model for coherence
... We have 3 possibilities
... 1) keep fO
... 2) add x/y to html root or to all elements
... (we already have width/height)
RC: we have CSS transforms
<ChrisL> yes, we already have width ad height *and they mean
different things*
TA: 3) cast SVG model in terms that CSS can manipulate
VY: is the last one already in discussion for the purpose of
animation
TA: yes, that's in discussion
VH: it might be interesting to investigate option (3) further
DS: we can map that fairly easily
TA: or just have x/y be CSS properties that would only be valid
within the SVG positioning model
... like using grid properties within a grid
<scribe> ACTION: Erik to put on the FXTF agenda, discussion about
HTML positioning in SVG and contact dbaron [recorded in
[81]http://www.w3.org/2011/07/27-svg-minutes.html#action16]
<trackbot> Created ACTION-3087 - Put on the FXTF agenda, discussion
about HTML positioning in SVG and contact dbaron [on Erik Dahlström
- due 2011-08-04].
<scribe> ACTION: Vincent to illustrate the three options put forward
by Tab in the SVG/HTML integration proposal [recorded in
[82]http://www.w3.org/2011/07/27-svg-minutes.html#action17]
<trackbot> Created ACTION-3088 - Illustrate the three options put
forward by Tab in the SVG/HTML integration proposal [on Vincent
Hardy - due 2011-08-04].
Moving onto the second part, SVG in HTML
AK: the second part doesn't work with the parser
TA: we tried to do it and it makes the parser too difficult
VH: why was that
TA: it has to do with keeping namespaces working correctly
... particularly wrt to XHTML/HTML compat
... that's why you need an svg/math root
AK: we'd need to rev the html parser every time an SVG element is
added
DS: so a bare <svg> in HTML would do what?
(some discussion about what the defaults are)
DS: there are 3 cases where people want to make SVG content
... 1) where you want it to be fixed width/height
... 2) as with (1) but with stuff outside the viewport (still fixed
size)
... 3) everything automatically scales to fit the content
... I think you get the most benefit from (3)
... auto-scaling SVG is the most beneficial SVG
... if you want it to be fixed width/height there are ways of doing
that
CM: but we don't have automatic viewport
DS: If we just have "<svg>" that should be mean auto-scaling
viewport
... i.e. = <svg vb="bounding box">
<ChrisL> tat is what we have already. if uou omit the viewbox then
you get autoscaling
CL: if you don't have a viewport and add content everything will
scale down
CM: I think what implementations do is compute 100% to a pixel size
based on the size of the containing block of the SVG
... and then that number of pixels becomes the implicit viewBox
width/height and starting at 0,0
<ChrisL> if that is the case, then current implementations dont give
us doug's third case 9even thoygh that was the original intent)
DS: my proposal is that a bare "<svg>" (no attr) takes the bbox of
the content in +ve coordinate space
<ChrisL> s/9e/(e
<ChrisL> so you would only get first quadrant displaying?
DS: and auto-scale that
(DS draws a circle with origin 0,0 and shows that only the
lower-right quadrant would be shown)
VY: that is problematic for text
... where if you don't specify 'y' it won't be visible
DS: that's something the authors just have to figure out
s/VY/JY/
DS: then an alternative is just take the bounding-box
CL: I don't think you don't need to restrict it to the positive
quadrant
DS: ok
... so we take the bounding box of all the content
(DS draws a square with "TEXT" positioned at 0,0, i.e. above the top
edge of the rect)
CC: You're proposing different behaviour for the same syntax
CM: I think the existing behaviour is useful
DS: In those cases use the attributes
CM: So you're keying the distinction off the presence/absence of the
attributes
<cyril> CC: You're proposing to break compatibility
DS: Yes
... and most content is produced by authoring tools that produce
those attributes
... so I don't think we'd break compatbility
... this proposal matches authors' expectations
... I think this is the most intuitive behaviour
<ChrisL> that sounds god to me
<ChrisL> s/god/good/
<shepazu> 0:)
VH: yes, in my proposal I was assuming this behaviour
CC: I think it changes the way implementation works
... previously you would prepare the buffer beforehand
ED: you already have that with the overflow property
VH: I think it's unfortunate that the parser issues prevent us from
including SVG elements directly
... so Doug you're talking about keeping a wrapper <svg> element but
making it simpler
DS: Yes
... it avoids the parser problem
... ensures we have only one SVG root
... which simplifies it
... if you have two circles (as per the document)
ED: yeah what coordinate space do you use if you reference a
gradient
DS: If people don't realise that every time that include an SVG
element they're creating a new viewbox you'll run into perf problems
... generally people don't want to use a single <circle> but
something more complex
... so the cost of adding an <svg> root is not so great
<ChrisL> i agree
<ChrisL> <svg bboxtype="stroke">
DS: we're going to have different bounding boxes (e.g. the current
defn doesn't include stroke width)
<ChrisL> current bbox is purely geometric. it exclides stroke,
markers and filters
DS: and the new bbox that includes everything would be the one we
use for the autoScaling behaviour
<vhardy> s/exclide/exclude
DS: there are two options
... one simply sets the viewBox to include the content
... the other also then stretches the <svg> containing block to take
as much room as is available
... in either case we want some simple behaviour for a bare "<svg>"
VH: I agree it's less common to want to include a single SVG element
in HTML than the other way around
... the new scaling behaviour is nice but not strictly necessary
... I withdraw my proposal to allow SVG elements in HTML without an
svg root
... for the reasons we discussed
(discussion about how the CSS overflow property got split into
overflow-x/y)
<birtles_> ACTION: Jen to propose auto viewBox sizing and SVG
container box sizing for bare <svg> in HTML [recorded in
[83]http://www.w3.org/2011/07/27-svg-minutes.html#action18]
<trackbot> Sorry, couldn't find user - Jen
<birtles_> ScribeNick: birtles_
<ChrisL> trackbot, status
<birtles> ACTION: Jennifer to propose auto viewBox sizing and SVG
container box sizing for bare <svg> in HTML [recorded in
[84]http://www.w3.org/2011/07/27-svg-minutes.html#action19]
<trackbot> Created ACTION-3089 - Propose auto viewBox sizing and SVG
container box sizing for bare <svg> in HTML [on Jennifer Yu - due
2011-08-04].
<birtles> ScribeNick: birtles
<ed> --- 15 minute break ---
Text layout
<cyril> Scribe: Cyril Concolato
<cyril> ScribeNick: cyril
CM: text layout, positioning, anchoring, bidi ...
<birtles>
[85]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Text_layout
[85] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Text_layout
CM: going through my text layout proposal
... there are examples on the wiki, but no image, didn't have time
to make snapshots
... the primary problem is that the x/y attributes on text elements
are used for 2 purposes
... 1) as an anchor position
... 2) to position glyphs
... sometimes they can be in conflict
... for <text x="10 20 30">abc</text> if you have text-anchor=start
and ltr text there is no conflict
... but if you have bidi text like <text x="10">ABCabc</text> with
ABC rtl and abc ltr, what is the x for ?
... is it for the A or for the whole text chunk ?
... probably you don't want to do anchoring and positioning
... and if we separate we would not have this conflict
VH: should we consider a solution for text and a solution for glyph
CM: I think for glyph positioning we can use the previous proposal
but for text positioning we cannot break the existing
... when it is ambiguous we could disable anchoring
VM: if there is one value that is anchoring and multiple values is
glyph positioning ?
CM: yes
VH: then what is the anchor ?
CM: my proposal is that there is no shifting to do anchoring
ED: you could do a middle thing to have each character centered
CM: it is not a use case I have considered
<ed> s/middle thing/text-anchor=middle/
BB: what happens when you're positioning text chunks instead of
glyphs/characters
<vhardy> [86]http://www.w3.org/TR/SVG/text.html#TextChunk
[86] http://www.w3.org/TR/SVG/text.html#TextChunk
CM: ligatures still work across chunks
<ChrisL> ok so basically the string of characters is laid out to a
sequence of glyphs, including bidi reordering, then the eft or right
edge of *that* is used for text anchoring
<ChrisL> cm: yes
<ChrisL> in that case i think this is a good proposal
s/eft/left/
<ed> "Ligatures only occur when a set of characters which might map
to a ligature are all in the same text chunk."
CL: what happens if you have tspans ?
... with two different colors ?
<ChrisL> ... and ligature formation
ED: tspans would define a new text chunk
CM: only if it has an x on the tspan
<ed> s/x/x or y attribute/
CM: I don't really consider that in my proposal
VH: the first issue and proposed solution is chunk, anchor and bidi
... is there anything else ?
CM: that's the rationale I gave for the whole thing
... to distinguish between positioning and anchoring you use the
number of values in x/y
ED: what happens when you have 1 value in x and multiple values in y
<ed> s/ in y/ in a tspan child/
<text> <tspan x="10 20"> ab
in this case there is no anchoring in my proposal
CM: one problem with multi-line text with text and tspans
... you wouldn't want bidi across those things
... BB: could you illustrate the 2 cases with discontinuity: rtl/ltr
s/... BB:/BB:/
[CM illustrating on the board]
CC: if you change the number of values in the attribute, you would
have discontinuity in the rendering
CM: that's a downside of the solution
VH: no there would be continuity
ED: anchoring is what people use
VH: there are authoring tools that use it for positioning
CM: the problem comes only for bidirectional text
... for purely rtl or ltr there is no problem
<ed> s/people use/most content uses/
CM: there is another problem, when you don't supply enough values
for bidi text, it's not clear where the remaining characters go
<text x="10 20 30">ABcd
scribe: where does the d go
s/d go/d goes/
scribe: if it's chunked you avoid this problem
... if you don't have chunking then you lay the text out, then you
override the position of some glyphs and the remaining glyphs are
not touched
VH: if the proper solution is to use glyph indexing, why not
deprecating character-based positioning
<birtles> CM: I wrote a bunch of tests and everyone is doing it
differently
<ChrisL> yes
ED: I don't think implementations are so consistent with diacretic
text
<ChrisL> why?
<ChrisL> ok
<ed> s/diacretic /diacritic /
ED: so we should text this feature separately
s/should text/should test/
ED: ligature is not the same as diacritic mark
<ed> [87]http://www.w3.org/TR/SVG11/text.html#CharactersAndGlyphs
[87] http://www.w3.org/TR/SVG11/text.html#CharactersAndGlyphs
ED: it's refered to as a composite character
VH: are we trying to fix 1.1 and produce an addendum or are we
trying to define what we want for 2.0 ?
CM: I just want some defined behavior for comibination of
character-based glyph positioning, anchoring, ... but to have the
glyph indexing
... I want the problems resolved in a way that makes enough sense
given the fact that we are using character-based positioning
VH: we recognize that it's broken so people cannot use it properly
<ChrisL> whiteboard photo
[88]http://lists.w3.org/Archives/Public/www-archive/2011Jul/att-0026
/IMAG0034.jpg
[88]
http://lists.w3.org/Archives/Public/www-archive/2011Jul/att-0026/IMAG0034.jpg
CM: I don't want that for simple cases that are interoperable, I
don't want to disable certain features
<ChrisL> the ones with multiple xy are often from PDF to SVG
conversion
CM: Adobe would in the future move to glyph-indexing and positioning
RC: yes probably
CM: what I should do is condense that wiki page into a slide show of
current spec contradictions and proposed solutions
VH: I will ask feedback internally
ED: you might want to look at I18n tests for bidi
<ed> s/for bidi/for bidi in svg/
<scribe> ACTION: heycam to produce a condensed description of the
problems and solutions [recorded in
[89]http://www.w3.org/2011/07/27-svg-minutes.html#action20]
<trackbot> Created ACTION-3090 - Produce a condensed description of
the problems and solutions [on Cameron McCormack - due 2011-08-04].
<scribe> ACTION: heycam to upload the tests for complex text cases
[recorded in
[90]http://www.w3.org/2011/07/27-svg-minutes.html#action21]
<trackbot> Created ACTION-3091 - Upload the tests for complex text
cases [on Cameron McCormack - due 2011-08-04].
CM: on the top of the wiki page, there are the 3 use cases that I
want to preserver
s/preserver/preserve/
ED: yes
... I'm not sure the current spec wording matches the
implementations
CM: one aspect of the proposal was to add a value to text-anchor to
turn off explicitly anchoring
<ed> s/ I'm not sure the current spec wording matches the
implementations / I don't think the current spec wording matches the
implementations exactly/
<ed> ED: in opera, the bidi reordering happens first, then the
result is mapped to the given positions
CM: when you have a long run of text rtl followed by a character ltr
then the last two characters are separated by a large distance
... and if you don't have enough value in x/y then you may consider
the last two characters as a chunk and therefore the distance
between them won't be as big
Canvas in SVG
BB: should we define a canvas element in SVG ?
VH: we said we are going to put it on the agenda of an FX meeting
AVK: if you go with the design where you get rid of the
foreignObject, it does not make sense to define the canvas element
in SVG
CM: this might be a good argument for dropping foreignObject and
allow the bare elements inside SVG
... it would be good for harmonization of audio, video, canvas ...
VH: I agree
<heycam> [91]http://www.w3.org/Graphics/SVG/WG/track/issues/2417
[91] http://www.w3.org/Graphics/SVG/WG/track/issues/2417
event attribute
AVK: the IDL attribute is generic on the Element but SVG would have
to define event handler content attribute
CM: what is generic ?
AVK: the bits about how functions are defined
... DOM Core provides an interface that allows the SVG spec to say
this is an event handler attribute
... and all the requirements follow from that
... for the entire list, it would be useful if SVG provides the
delta compared to what HTML has
CM: we don't want HTML and SVG both define onclick for example
AVK: it would make sense to have the union of events between SVG and
HTML in DOM Core
<scribe> ACTION: ed to collect the events from SVG as a delta with
respect to HTML [recorded in
[92]http://www.w3.org/2011/07/27-svg-minutes.html#action22]
<trackbot> Created ACTION-3092 - Collect the events from SVG as a
delta with respect to HTML [on Erik Dahlström - due 2011-08-04].
AVK: I would like to discuss also the event vs evt issue
... what we discussed was that there would be a single argument
event passed to the function
<ed> that's ISSUE-2055
<ed> ISSUE-2055?
<trackbot> ISSUE-2055 -- Define 'evt'/'event' relationship more
formally -- closed
<trackbot> [93]http://www.w3.org/Graphics/SVG/WG/track/issues/2055
[93] http://www.w3.org/Graphics/SVG/WG/track/issues/2055
AVK: and that there would be a scoped variable with the same value
called evt defined
<ed> ISSUE-2176?
<trackbot> ISSUE-2176 -- evt vs event Redux -- raised
<trackbot> [94]http://www.w3.org/Graphics/SVG/WG/track/issues/2176
[94] http://www.w3.org/Graphics/SVG/WG/track/issues/2176
<ed> [95]http://www.w3.org/TR/SVGTiny12/script.html#HandlerElement
[95] http://www.w3.org/TR/SVGTiny12/script.html#HandlerElement
<ed> "The 'event' parameter shown above is an Event object
corresponding to the event that has triggered the 'handler'. An
'evt' variable can be used instead of 'event' ('evt' is an alias to
'event')."
RESOLUTION: We decide to resolve ISSUE-2176 by introducing evt as an
alias to event in event handlers
<scribe> ACTION: heycam to add a note to the SVG spec about
ISSUE-2176 [recorded in
[96]http://www.w3.org/2011/07/27-svg-minutes.html#action23]
<trackbot> Created ACTION-3093 - Add a note to the SVG spec about
ISSUE-2176 [on Cameron McCormack - due 2011-08-05].
<ed> [everyone looks over their open actions]
<heycam> trackbot, close ACTION-3068
<trackbot> ACTION-3068 Investigate reference updates per Innovimax's
comment closed
Received on Friday, 29 July 2011 00:45:05 UTC