W3C home > Mailing lists > Public > public-svg-wg@w3.org > July to September 2011

minutes, Seattle 2011 SVG WG F2F day 2

From: Cameron McCormack <cam@mcc.id.au>
Date: Thu, 28 Jul 2011 17:44:11 -0700
Message-ID: <4E32025B.1020001@mcc.id.au>
To: www-svg@w3.org
CC: public-svg-wg@w3.org
The HTML minutes for the Seattle F2F day 2 are at:


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


      [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
    ... 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
    ... but in some cases we get behaviour just from ebing in the
    ... 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

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

    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

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

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


    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



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

    heycam shows a segment as in

      [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

    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

    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

    <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


      [69] http://perso.telecom-paristech.fr/~concolat/SuperPathSVGOpen.pdf


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



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

    <scribe> ACTION: shepazu to make a Catmull Rom editor that takes
    variable tension parameters. [recorded in

    <trackbot> Created ACTION-3085 - Make a Catmull Rom editor that
    takes variable tension parameters. [on Doug Schepers - due

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


    <shepazu> ACTION: shepazu to suggest audio-volume control properties
    to CSS WG [recorded in

    <trackbot> Created ACTION-3086 - Suggest audio-volume control
    properties to CSS WG [on Doug Schepers - due 2011-08-04].


      [74] http://www.w3.org/TR/SVGTiny12/multimedia.html#AudioLevelProperty

    <ed> ACTION-3086:

      [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



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


      [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



    VH: My real question is, I think it would be nice to have a
    ... it seems unnatural to me to have this kind of overhead
    ... I think it's very natural to want to integrate text into your
    ... 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
    ... 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

    <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
    ... 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
    ... what is the reference box there

    VH: even the static positioning, if I just have a div what does 100%

    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


    <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


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

    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

    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

    <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

    <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

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

    CM: but we don't have automatic viewport

    DS: If we just have "<svg>" that should be mean auto-scaling
    ... 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


    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

    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

    <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

    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

    <birtles_> ACTION: Jen to propose auto viewBox sizing and SVG
    container box sizing for bare <svg> in HTML [recorded in

    <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

    <trackbot> Created ACTION-3089 - Propose auto viewBox sizing and SVG
    container box sizing for bare <svg> in HTML [on Jennifer Yu - due

    <birtles> ScribeNick: birtles

    <ed> --- 15 minute break ---

Text layout

    <cyril> Scribe: Cyril Concolato

    <cyril> ScribeNick: cyril

    CM: text layout, positioning, anchoring, bidi ...


      [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

    <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


    <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

    <ChrisL> yes

    ED: I don't think implementations are so consistent with diacretic

    <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


    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

    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

    <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

    <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


    ED: yes
    ... I'm not sure the current spec wording matches the

    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

    <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

    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

    <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:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:46 UTC