W3C home > Mailing lists > Public > public-svg-wg@w3.org > April to June 2009

Minutes, Monday April 27 2009 telcon

From: Erik Dahlstrom <ed@opera.com>
Date: Mon, 27 Apr 2009 10:06:47 +0200
To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
Message-ID: <op.us1ctedigeuyw5@blorp.xn--dahlstrm-t4a.net>
Minutes in HTML format:

   http://www.w3.org/2009/04/27-svg-minutes.html

or as text here:

    [1]W3C

       [1] http://www.w3.org/

                                - DRAFT -

                    SVG Working Group Teleconference

27 Apr 2009

    [2]Agenda

       [2]  
http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0072.html

    See also: [3]IRC log

       [3] http://www.w3.org/2009/04/27-svg-irc

Attendees

    Present
           Shepazu, [IPcaller], heycam, ed, anthony

    Regrets
    Chair
           heycam

    Scribe
           erik

Contents

      * [4]Topics
          1. [5]Publishing the Compositing spec
          2. [6]Updating broken CSS2 links
          3. [7]Referencing CSS 2.1 from SVG 1.1 Second Edition
          4. [8]Pattern and rendering order
          5. [9]�image-fit� vs preserveAspectRatio
          6. [10]ref/params spec
      * [11]Summary of Action Items
      _________________________________________________________



    <trackbot> Date: 27 April 2009

    <shepazu> nope

    <scribe> scribe: erik

    <scribe> scribeNick: ed

Publishing the Compositing spec

    CM: we discussed previously to publish the spec this week, sent some
    comments today, but those doesn't need to hold up the publication

    AG: those comments are good, mostly typo corrections, and a couple
    of things that need to be explained
    ... as long as everyone else is ok with publishing

    DS: has it been FPWD?

    AG: this would be the FPWD

    CM: parts were published before in the 1.2 full draft

    DS: this is a new spec though

    CM/DS: we can do the cleanups/typos after the FPWD

    CM: are we resolved to publish compositing?

    DS: any objections?

    all: no objections, let's publish

    RESOLUTION: to publish SVG Compositing as a FPWD

    <scribe> ACTION: DS to publish the SVG Compositing spec [recorded in
    [12]http://www.w3.org/2009/04/27-svg-minutes.html#action01]

    <trackbot> Created ACTION-2527 - Publish the SVG Compositing spec
    [on Doug Schepers - due 2009-05-04].

Updating broken CSS2 links

    DS: doesn't need discussion?

    CM: we need to decide how to deal with it, in the existing spec
    ...summary: because of the shortname /CSS2 and /REC-CSS2 are now
    redirected to CSS21, various links in SVG 1.1 are now dangling
    ... full dated uri:s should have been used from the start in the
    spec
    ... we can replace the SVG 1.1 spec links in place to fix the links

    ED: are we still pointing to CSS2, or 2.1?

    CM: css2
    ... if there are no objections, we can fix the links, have link to
    the files that need to be switched
    ... there are a couple in tiny 1.2 too, not broken ones, but it's
    now pointing to css21...and those features are still in css21 anyway
    ... but css2 is in the ref-section
    ... will forward the mail with the fixups

    <scribe> ACTION: heycam to mail DS the info for fixing up CSS2 links
    in the SVG 1.1 spec [recorded in
    [13]http://www.w3.org/2009/04/27-svg-minutes.html#action02]

    <trackbot> Created ACTION-2528 - Mail DS the info for fixing up CSS2
    links in the SVG 1.1 spec [on Cameron McCormack - due 2009-05-04].

Referencing CSS 2.1 from SVG 1.1 Second Edition

    CM: I'm not that familiar with what's changed
    ... one thing I know of is the webfonts stuff, which is now in CSS3
    webfonts

    DS: I don't think we should change SVG 1.1 that much

    CM: probably more effort than its worth
    ... we don't want to change things, but rather to point to the more
    up-to-date spec (CSS21)
    ... they may be in CR for awhile anyway

    DS: it wouldn't be correct to change it
    ... we may be changing things dramatically for older svg useragents
    ... we should definately reference CSS21 going forward, but not in
    the SVG 1.1 second edition

    ED: yes, I agree with that

    CM: fine with me

Pattern and rendering order

    <heycam>
    [14]http://lists.w3.org/Archives/Public/www-svg/2009Apr/0088.html

      [14] http://lists.w3.org/Archives/Public/www-svg/2009Apr/0088.html

    <heycam> ED: he's asking about the case when the pattern tile has
    some overflow, asking how it's supposed to render

    <heycam> ED: of course, UAs differ on how they interpret this

    <heycam> ED: i think he's saying that the most logical solution
    would be to use the painters model

    <heycam> ED: he's saying that because at least opera and asv don't
    support overflow, you can't do all types of overlapping patterns

    [15]http://lists.w3.org/Archives/Public/www-svg/2009Apr/0093.html

      [15] http://lists.w3.org/Archives/Public/www-svg/2009Apr/0093.html

    <heycam> ED: he refers to the 17 known tiling patterns

    <heycam> ED: in my response i ask him what kinds of patterns
    couldn't you do

    <heycam> ED: he replied with those 17 groups

    <heycam> ED: because you can do quite a few types by rearranging the
    tile itself

    <heycam> ED: if you want to be able to do all these other ones, then
    the pattern rendering would have to be a bit more advanced

    <heycam> ED: the 1.1 spec doesn't really say how you render those
    cases, it just says that you can have overflow:visible, doesn't say
    what that's supposed to look like or handled

    <heycam> ED: i haven't tested that many implementations, it would
    probably be nice to have examples of each of these 17 groups of
    periodic tilings, and to see what all of the current UAs do

    <heycam> ED: one problem would be that there are not that many UAs
    that support patterns

    <heycam> ED: i don't think safari does it

    <heycam> ED: batik, asv, opera and i think firefox 3

    <heycam> ED: those should be tested for all those groups

    <heycam> ED: i think batik/asv/opera all just take the rectangle and
    tile that

    <heycam> ED: i think for 1.1 Second Edition we should disallow it,
    or state that it's undefined explicitly

    <heycam> CM: would we say that overflow has no effect, and that it
    always clips to the pattern viewport?

    <heycam> ED: or we could say that it's undefined behaviour, so we
    could leave it open for fixing later

    <heycam> CM: is it worth having it undefined so that we can define
    it later?

    <heycam> DS: it's worth considering

    <heycam> AG: should email olaf back

    <heycam> ED: we should test the fallback behaviour; it's possible
    it's just clipped to the viewport

    <heycam> DS: this is definitely something we should consider
    following up on, not necessarily something we should change now

    <heycam> DS: IME patterns are useless sometimes

    <heycam> ED: so we could just say that overflow:visible is undefined

    <heycam> AG: raise an issue on svg 2 to define it

    <scribe> ACTION: ed to add an svg 1.1 errata for making
    overflow=visible on patterns be undefined behaviour and to raise an
    issue on solving the pattern tiling for overflow=visible (core2)
    [recorded in
    [16]http://www.w3.org/2009/04/27-svg-minutes.html#action03]

    <trackbot> Created ACTION-2529 - Add an svg 1.1 errata for making
    overflow=visible on patterns be undefined behaviour and to raise an
    issue on solving the pattern tiling for overflow=visible (core2) [on
    Erik Dahlström - due 2009-05-04].

�image-fit� vs preserveAspectRatio

    ED: so the only remaining issue really is the naming it seems
    ... the feature is useful for both CSS and SVG

    CM: so it would be fine if UAs implented both pAR and
    image-fit/content-fit

    DS/CM/ED: we all like 'content-*'

    <scribe> ACTION: ed to reply to the image-fit thread saying that the
    SVG WG would prefer the name(s) 'content-*' [recorded in
    [17]http://www.w3.org/2009/04/27-svg-minutes.html#action04]

    <trackbot> Created ACTION-2530 - Reply to the image-fit thread
    saying that the SVG WG would prefer the name(s) 'content-*' [on Erik
    Dahlström - due 2009-05-04].

ref/params spec

    DS: any reviews so far, besides heycam?

    AG: not yet

    ED: only read the proposals so far

    DS: heycam has proposed an alternate syntax
    ... a suggestion about an alternate syntax that got rid of the ref
    element, and directly put a functional values in the attribute
    values

    CM: yeah, wanted to see if I could get rid of the ref elements

    DS: yeah, we talked about it at the TPAC
    ... paintservers are similar
    ... would it be easier to implement if it used the same mechanism?
    ... thinking about it now, I could implement it in script either way

    CM: the weird part in my proposal is the content attribute, which is
    similar to :content in css
    ... so it would be more general way of inserting text content

    DS: one problem with tref, if the content doesn't resolve then the
    user is left unknowing, nothing will be shown (no fallback content)
    ... so I liked the idea of allowing fallback content for tref
    ... are we talking about markup or just strings?
    ... tref just takes a string
    ... having fallback for tref and having content, not so keen on
    having stirngs in attributes though

    CM: in svg normally if you have a tref reference to a switch would
    it give you the textContent or would it do the switch processing?

    ED: I think it's just textContent

    CM: a problem is that one of the role attributes is named 'content'
    ... the reason I chose 'content' is that it offers the same
    functionality as the css content property
    ... what do you want in terms in of publication?
    ... might be good to publish this to let people know we want to add
    this functionality

    AG: yeah, we should get it out and get comments

    CM: DS you could add some notes there, for these things

    DS: what do you think of changing the values of things like
    geometric values of things like x and y, to have functional values?

    CM: you mean turning attributes into properties?

    DS: did you see the primer?

    <shepazu> [18]http://dev.w3.org/SVG/modules/ref/SVGRef.html

      [18] http://dev.w3.org/SVG/modules/ref/SVGRef.html

    <shepazu> [19]http://dev.w3.org/SVG/modules/ref/SVGRefPrimer.html

      [19] http://dev.w3.org/SVG/modules/ref/SVGRefPrimer.html

    DS: scroll down to the maps
    ... there's a little dot the, parameterising the cx and cy
    ... and same for links, to pass in links for e.g ads

    CM: like the examples

    DS: right now we cna only use functional notation for attribute
    values in presentation attributes
    ... i'd like to extend that to all attributes
    ... one, why wouldn't you want to set anything with css?
    ... two, it would work for camerons constraints stuff

    CM: it will be important to think about how this would work for
    future things

    DS: parameterised attribute values is probably how I would go with
    extending the syntax
    ... so I'd like to say e.g 100%-5px without having it in a URL

    CM: calc in CSS provides that
    ... if we're looking at promoting the attributes to properties, then
    we could gain from that
    ... it makes enough sense to be able to put them there

    <shepazu> [20]http://www.w3.org/TR/css3-values/#calc

      [20] http://www.w3.org/TR/css3-values/#calc

    CM: it does make sense to upgrade them to being properties

    ED: all attributes?

    DS: most, href would be an exception

    ED: lists of things e.g, sometimes you might want to override only
    parts of a list (or a path)

    DS: anything that takes a list couldn't have a fallback
    ... any other attributes could have a fallback

    <shepazu> <rect ... fill="param(color) blue" stroke="param(outline)
    navy" />

    CM: that might mean we have to think about types

    DS: if we do it, it's done, there's going to be flaws with any model
    we come up with
    ... i like functional values
    ... it builds on things laid out in css

    <shepazu> width: calc(100%/3 - 2*1em - 2*1px);

    CM: i would be in favor of investigating making existing svg
    attributes into properties

    DS: given that we want to allow this syntax anyway
    ... I think it makes sense for parameterising things like stroke and
    fill
    ... might make sense for other things (I think it does)
    ... less work to specialcase the ones that aren't properties

    CM: would make it easier to reuse content

    DS: markers is one thing, had to duplicate the markers several times
    to style them differently

    ED: yeah, it's annoying that it behaves different from use, which do
    inherit style into the shadowtree

    DS: i like having an ref element, because you can animate those in
    the document
    ... and we don't have the equivalent of <param> in svg
    ... if I wanted to use a button multiple times, I might like to
    actually like to use this syntax
    ... I was thinking of the <animation> element, or the <image>
    element, anything that references
    ... even the <use> element

    AG: would we run into problems with optional arguments?

    DS: <ref> have default values, but the example with the rect above,
    you could also pass defaults there
    ... it's important

    AG: multiple optional elements
    ... or multiple optional arguments

    DS: this is a new class of things we could start doing...calc, or
    url() and param
    ... there's an attr() function

    CM: often used with css content

    <anthony> transform="param(blah) translate(20 20)"

    DS: we should talk to the csswg about this

    AG: so, would the translate be an additonal transform, or a
    fallback?

    <shepazu> transform="scale(param(blah)) translate(20 20)"

    DS: it's a list, so would need to be specialcased

    AG: needs special consideration yeah

    DS: might be handy with translateX,Y,Z
    ... will add notes with the functional notation for param
    ... and if we're not going to have an element, then it could be
    applied to css as well

    CM: yeah, that might be good

    RESOLUTION: publish the param/ref spec as FPWD

    <scribe> ACTION: heycam to get the ref spec building with the new
    scripts [recorded in
    [21]http://www.w3.org/2009/04/27-svg-minutes.html#action05]

    <trackbot> Created ACTION-2531 - Get the ref spec building with the
    new scripts [on Cameron McCormack - due 2009-05-04].

    <scribe> ACTION: DS to integrate the new potential syntax, and
    publish the ref spec [recorded in
    [22]http://www.w3.org/2009/04/27-svg-minutes.html#action06]

    <trackbot> Created ACTION-2532 - Integrate the new potential syntax,
    and publish the ref spec [on Doug Schepers - due 2009-05-04].

    <scribe> ACTION: heycam to look into making attributes into
    properties, and potential problems with that [recorded in
    [23]http://www.w3.org/2009/04/27-svg-minutes.html#action07]

    <trackbot> Created ACTION-2533 - Look into making attributes into
    properties, and potential problems with that [on Cameron McCormack -
    due 2009-05-04].

    rrs-agent, make minutes

Summary of Action Items

    [NEW] ACTION: DS to integrate the new potential syntax, and publish
    the ref spec [recorded in
    [24]http://www.w3.org/2009/04/27-svg-minutes.html#action06]
    [NEW] ACTION: DS to publish the SVG Compositing spec [recorded in
    [25]http://www.w3.org/2009/04/27-svg-minutes.html#action01]
    [NEW] ACTION: ed to add an svg 1.1 errata for making
    overflow=visible on patterns be undefined behaviour and to raise an
    issue on solving the pattern tiling for overflow=visible (core2)
    [recorded in
    [26]http://www.w3.org/2009/04/27-svg-minutes.html#action03]
    [NEW] ACTION: ed to reply to the image-fit thread saying that the
    SVG WG would prefer the name(s) 'content-*' [recorded in
    [27]http://www.w3.org/2009/04/27-svg-minutes.html#action04]
    [NEW] ACTION: heycam to get the ref spec building with the new
    scripts [recorded in
    [28]http://www.w3.org/2009/04/27-svg-minutes.html#action05]
    [NEW] ACTION: heycam to look into making attributes into properties,
    and potential problems with that [recorded in
    [29]http://www.w3.org/2009/04/27-svg-minutes.html#action07]
    [NEW] ACTION: heycam to mail DS the info for fixing up CSS2 links in
    the SVG 1.1 spec [recorded in
    [30]http://www.w3.org/2009/04/27-svg-minutes.html#action02]

    [End of minutes]
      _________________________________________________________


     Minutes formatted by David Booth's [31]scribe.perl version 1.135
     ([32]CVS log)
     $Date: 2009/04/27 08:03:46 $
      _________________________________________________________

      [31] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [32] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20
Check for newer version at [33]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/

      [33] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/all: no/all: no objections, let's publish/
Succeeded: s/CSSREC2/REC-CSS2/
Succeeded: s/all/we all/
Found Scribe: erik
Found ScribeNick: ed
Default Present: Shepazu, [IPcaller], heycam, ed, anthony
Present: Shepazu [IPcaller] heycam ed anthony
Agenda: [34]http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJu
n/0072.html
Found Date: 27 Apr 2009
Guessing minutes URL: [35]http://www.w3.org/2009/04/27-svg-minutes.html
People with action items: ds ed heycam

      [34]  
http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0072.html
      [35] http://www.w3.org/2009/04/27-svg-minutes.html

    End of [36]scribe.perl diagnostic output]

      [36] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm


-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Monday, 27 April 2009 08:07:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 08:07:35 GMT