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

Minutes, April 29 2009 telcon

From: Cameron McCormack <cam@mcc.id.au>
Date: Wed, 29 Apr 2009 18:06:04 +1000
To: public-svg-wg@w3.org
Message-ID: <20090429080604.GB13858@arc.mcc.id.au>
http://www.w3.org/2009/04/29-svg-minutes.html


   [1]W3C

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

                               - DRAFT -

                   SVG Working Group Teleconference

29 Apr 2009

   [2]Agenda

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

   See also: [3]IRC log

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

Attendees

   Present
   Regrets
   Chair
          Erik

   Scribe
          Cameron

Contents

     * [4]Topics
         1. [5]Publication status (compositing, ref)
         2. [6]CSS3 Values and Units
         3. [7]Raleigh F2F
         4. [8]SVG script and style parsing in HTML
         5. [9]Value of SVGElement::id not defined when there is no
            id="" attribute present
         6. [10]SVGXXXList interfaces perhaps should not throw
            SVGException(SVG_WRONG_TYPE_ERR)
         7. [11]SVGStyleElement should inherit from SVGLangSpace
     * [12]Summary of Action Items
     _________________________________________________________



   <trackbot> Date: 29 April 2009

   <scribe> Scribe: Cameron

   <scribe> ScribeNick: heycam

Publication status (compositing, ref)

   DS: going slowly
   ... cameron made some progress on the build scripts
   ... did you apply that to template too?

   CM: no i didn't yet

   DS: cameron manually put build scripts in for the integration spec,
   the params spec and the compositing spec
   ... right now i'm in the of making the params spec have "params"

   ED: regarding that, is it in the spec already that you could use
   params for references inside svg? for example for 'use' elements?

   DS: we did mention that last telcon, but didn't really discuss it
   ... so that syntax for a url is
   param([13]http://example.org/something?query#frag)
   ... a use element is just referenced using a uri, don't see why the
   query string shouldn't apply
   ... but it would apply at the global level
   ... we could say that the shadow tree of the 'use' element is a
   special case, and has its own params interface

     [13] http://example.org/something?query#frag)

   CL: so each instance has its own params

   CM: if you do <use xlink:href="?something#else">, then that's going
   to fetch another resource

   DS: we could change that in the context for 'use' elements

   CM: i'd be wary of doing that

   ED: we could allow <param> elements as children of <use>, that could
   fix that

   DS: so svg doesn't have a <param> element
   ... we can't take advantage of that, except for uris
   ... we could add a <param> element or equivalent
   ... <param> in html4 is quite elaborate

   CM: it is simpler in html5, just name/value attributes and no
   children

   <shepazu>
   [14]http://www.w3.org/TR/1999/REC-html401-19991224/struct/objects.ht
   ml#h-13.3.2

     [14] http://www.w3.org/TR/1999/REC-html401-19991224/struct/objects.html#h-13.3.2

   DS: if we did do something like this, i'd take the html5 <param>

   CL: the whole reason for param in the first place was to extend
   things without changing the dtd
   ... i've never seen this other stuff, nor seen it used

   DS: part of me says, yeah it'd be great to just use <param>
   ... then there might be complaints about namespace for parsing in
   html, etc.

   ED: so in html you'd get HTML <param> elements
   ... part of me thinks it would be nice if it were the same

   DS: same question applies to the <link> element
   ... it'd be useful for authors to be able to use <link> in svg
   ... don't know if it would be difficult to have the namespace of the
   Element in the dom to differ, depending on where it lives

   <scribe> ACTION: Doug to ask HTML WG what they think about parsing
   <param> and <link> in SVG [recorded in
   [15]http://www.w3.org/2009/04/29-svg-minutes.html#action01]

   <trackbot> Created ACTION-2534 - Ask HTML WG what they think about
   parsing <param> and <link> in SVG [on Doug Schepers - due
   2009-05-06].

   DS: i think it would be nice for us to have a <param> thing
   ... a child of a <use>, or any referencing element

   CM: i'd love to have <param> child of <use>

   ED: so when would the params spec be ready for publication?

   DS: if i can get everything pubruled tonight, i believe we'll be
   publishing on thursday, for both params and compositing

   <Zakim> ChrisL, you wanted to ask about specs with two documents

CSS3 Values and Units

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

     [16] http://www.w3.org/TR/css3-values/

   DS: last time we were talking about the <ref> element, cameron
   suggested it might not be necessary to have that element
   ... simpler just to do a param() value inside attributes
   ... this was the first thing we talked about at tpac
   ... then i thought what about fallback values, etc.
   ... and it seemed like a paint server, and for text, like <text>
   referenceable by a <tref>
   ... i'd forgotten that if you use the url() syntax, you can have a
   second fallback value (for <color> and <paint>)
   ... that's a mechanism that already exists from css, and it
   simplifies things
   ... cameron suggested param() would have two values, one the
   parameter, second the fallback value
   ... but we could use that fallback syntax similar to <paint>
   ... we started talking about this in the context of other things we
   want to do, in particular allowing relative values
   ... e.g. 100% minus 5px
   ... and we realised that there's calc() in css3-values
   ... not sure it's implemented, but it's pretty well defined
   ... i noticed you and hakon were editors for that spec
   ... where does calc() stand?

   CL: not moving fast
   ... once other things are done, more effort will go in to it
   ... like the syntax module, it sort of rounds up bits
   ... any time a module adds a new value or unit, they'll have to
   modify that module as well
   ... so they're waiting, pretty much

   DS: we thought that that would be the easiest way, for us, for
   having say <rect width="calc(100% - 10px)" ...
   ... we'd have to extend it, because cameron's constraint syntax also
   takes into account references to attribute values on other elements,
   and also a notation to refer to the bbox of an element
   ... so we'd have to take that an extend it
   ... what do you think about that?

   CL: we already have things with fallback values, the attribute takes
   two things

   DS: i thought that came from css. did it not?

   CL: not sure

   DS: in any case, we're considering adopting that syntax
   ... if they didn't want us to extend it, we could make our own
   svg-expression() syntax (or something)

   CM: this was in the context of turning @width a property, too
   ... so we could get this calc() for free

   CL: in svg, when we designed it, we decided that there's separation
   between content and presentation
   ... we decided that the geometry was the content (attributes), and
   the geometry could be styled in various ways (properties)
   ... given that, you can currently have width="" height="" *and*
   style="width: ...; height: ..", which mean different things
   ... if you change them from being an attribute to a property, then
   you have a conflict with the existing properties

   CM: except that width/height properties don't have any meaning on
   svg elements currently

   ED: but there are presentation attributes currently

   CL: but width="" on a <rect> isn't one of those currently

   DS: i know that coming to svg initially, since i knew a bit of css,
   i was very unclear about what the division was between attributes
   and properties
   ... not saying that there won't be problems, but perhaps the gains
   we would get would outweigh the confusion or other problems
   ... what would we lose from doing this, and what would we gain?
   ... gain: for people who already know css, most designers, they
   would be able to use svg more easily
   ... also gain the ability to use css classes to define those
   attributes values
   ... many times i've wanted to do that
   ... also we could get this calc() syntax for free

   ED: what you would lose is backwards compat

   CM: i don't think there's much that would actually break

   DS: i understand chris the distinction you make between
   geometry/styling
   ... but other things, such as stroke-width, change the geometry of
   the element

   CL: well...

   DS: esp if we make these changes where a bbox takes into account
   stroke-width/filters/etc.

   CL: right

   DS: i'm less convinced that the separation of content and style ...

   CL: yes, it can never be absolute, it's a sliding scale
   ... a general principle that you try to keep, rather than argue
   hard-and-fast

   DS: i used to argue that it wasn't presentational, that the geometry
   was the semantics of svg, but i don't think that's affected or
   changed, by being able to changed with css

   CL: i wasn't objecting, just saying that we'd need to be careful not
   to break anything

   DS: not every attribute could be usefully defined as a css property,
   for example xlink:href

   CL: this is for every attribute?

   DS: no i'm saying there are some that don't make sense
   ... but for x/y/width/height, sure
   ... d on path? probably not
   ... positional and sizing attributes
   ... where indeed is the distinction, where do we draw the line?
   ... xlink:href definitely seems not presentational at all

   CL: x/y/width/height css absolute positioning uses those
   ... don't necessarily mean the same thing
   ... vml tried to use those, and it was a mess

   DS: i remember i was looking recently at vml, and thinking why
   didn't they adopt the syntax

   CL: people told us it was horrible
   ... relative/absolute positioning in CSS2 isnt as simple as you
   think
   ... a downside is that maybe csswg would then want to define what
   values we can have in our attributes

   DS: possibly

   <scribe> ACTION: Doug to contact the CSSWG about making some more
   SVG attributes properties [recorded in
   [17]http://www.w3.org/2009/04/29-svg-minutes.html#action02]

   <trackbot> Created ACTION-2535 - Contact the CSSWG about making some
   more SVG attributes properties [on Doug Schepers - due 2009-05-06].

Raleigh F2F

   <ed> [18]http://www.w3.org/Graphics/SVG/WG/wiki/NCF2F2009

     [18] http://www.w3.org/Graphics/SVG/WG/wiki/NCF2F2009

   CL: i can confirm that i can attend

   ED: maybe we should gather a few agenda topics
   ... we'll have all of the modules
   ... particular requests?

   CL: test suites for individual modules, and how we'll work on those
   ... recently in inkscape, there's something that's used by filters
   ... one of the interpolation properties
   ... color-interpolation-filters
   ... i grepped the test suite and found we had none for it

   [19]http://www.w3.org/Graphics/SVG/WG/track/issues/2219

     [19] http://www.w3.org/Graphics/SVG/WG/track/issues/2219

   ED: I plan to test all attributes/properties for filters
   ... for the filter module

   <shepazu> fill="url(#myRedGradient) red"

   ED: so a reminder to fill in the registration form for the f2f

   <ed> [20]http://www.w3.org/2002/09/wbs/19480/NC2009/

     [20] http://www.w3.org/2002/09/wbs/19480/NC2009/

   <ed> ACTION: ed to mail public-svg-wg reminding ppl about the
   raleigh F2F [recorded in
   [21]http://www.w3.org/2009/04/29-svg-minutes.html#action03]

   <trackbot> Created ACTION-2536 - Mail public-svg-wg reminding ppl
   about the raleigh F2F [on Erik Dahlström - due 2009-05-06].

SVG script and style parsing in HTML

   <ed>
   [22]http://lists.w3.org/Archives/Public/www-svg/2009Apr/0096.html

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

   ED: asking about how <script> and <style> should be parsed in
   svg-in-text/html

   CL: this about cdata-marked sections?

   ED: yes
   ... what type of behaviour would be the most intuitive to authors?

   CL: people tend to put in cdata-sections all over the place, just to
   be sure
   ... so if you have a "<" it prevents starting a tag
   ... handy if you've got that in a script
   ... in many cases it makes no difference; just treat them as tokens
   to be gobbled up
   ... but there cases where you need to treat the "<" as character
   data
   ... we could define that implicitly there is a cdata-section around
   script and style
   ... and that you can't open/close elements inside script/style
   ... only </script> would close <script>

   DS: i think that is more-or-less how they handled it
   ... we have as a requirement that svg extracted from an html should
   work as standalone svg

   CM: i think some people were ok with that having to work, and others
   didn't feel the need for it

   DS: iirc sicking was suggesting that the cdata-section syntax would
   be allowed, and would be treated as in xml syntax
   ... it doesn't really matter what gets put into the dom

   CM: i don't think it matters whether CDATASection or Text nodes get
   put into the dom

   ED: i would prefer it for <script> inside svg-in-text/html to be
   parsed the same as html <script>

   <ChrisL> I would prefer that too

   CM: as long as the CDATA-sections still work

   <ChrisL> would that mean that CDATA marked sections should not be
   used? Or should be silently ignored?

   DS: there are other things not being enforced about the xml syntax,
   so it sort of makes that argument moot

   ED: if you look at svg content used on the web today, most is made
   by scripts anyway
   ... i'm not sure how big of a concern it is

   <scribe> ACTION: Cameron to reply to the style/script thread
   [recorded in
   [23]http://www.w3.org/2009/04/29-svg-minutes.html#action04]

   <trackbot> Created ACTION-2537 - Reply to the style/script thread
   [on Cameron McCormack - due 2009-05-06].

   <ChrisL> issue-2260?

   <trackbot> ISSUE-2260 -- Value of SVGElement::id not defined when
   there is no id="" attribute present -- RAISED

   <trackbot> [24]http://www.w3.org/Graphics/SVG/WG/track/issues/2260

     [24] http://www.w3.org/Graphics/SVG/WG/track/issues/2260

Value of SVGElement::id not defined when there is no id="" attribute
present

   <ed> [25]http://www.w3.org/Graphics/SVG/WG/track/issues/2260

     [25] http://www.w3.org/Graphics/SVG/WG/track/issues/2260

   <ChrisL> "Probably we should backport the behaviour from 1.2T, which
   says that the value is null."

   CM: in html5 it's empty string if the id="" attribute is missing

   <shepazu> <rect id="" ... />

   DS: my preference would be null if it's not there, but since html
   already does it empty string, rather go that way

   CL: in tiny it says it should be null

   DS: i don't think it would break any content if we change that

   CL: if we change 1.1, i would like 1.2T to be errataed to make that
   empty string

   RESOLUTION: If it's compatible, make 1.1 return "" for
   SVGElement::id when the attribute is missing, and port that to 1.2T

   <scribe> ACTION: Cameron to check that if it's compatible, make 1.1
   return "" for SVGElement::id when the attribute is missing, and port
   that to 1.2T [recorded in
   [26]http://www.w3.org/2009/04/29-svg-minutes.html#action05]

   <trackbot> Created ACTION-2538 - Check that if it's compatible, make
   1.1 return "" for SVGElement::id when the attribute is missing, and
   port that to 1.2T [on Cameron McCormack - due 2009-05-06].

SVGXXXList interfaces perhaps should not throw
SVGException(SVG_WRONG_TYPE_ERR)

   <ChrisL> issue-2261?

   <trackbot> ISSUE-2261 -- SVGXXXList interfaces perhaps should not
   throw SVGException(SVG_WRONG_TYPE_ERR) -- RAISED

   <trackbot> [27]http://www.w3.org/Graphics/SVG/WG/track/issues/2261

     [27] http://www.w3.org/Graphics/SVG/WG/track/issues/2261

   CM: i think it would be best to just drop the requirement about
   throwing that exception

   ED: you tested and none of the implementations threw the
   SVGException

   RESOLUTION: Drop those exceptions

   <scribe> ACTION: Cameron to drop the SVGExceptions for ISSUE-2261
   [recorded in
   [28]http://www.w3.org/2009/04/29-svg-minutes.html#action06]

   <trackbot> Created ACTION-2539 - Drop the SVGExceptions for
   ISSUE-2261 [on Cameron McCormack - due 2009-05-06].

SVGStyleElement should inherit from SVGLangSpace

   <ChrisL> issue-2264?

   <trackbot> ISSUE-2264 -- SVGStyleElement should inherit from
   SVGLangSpace -- RAISED

   <trackbot> [29]http://www.w3.org/Graphics/SVG/WG/track/issues/2264

     [29] http://www.w3.org/Graphics/SVG/WG/track/issues/2264

   CM: weird that SVGStyleElement doesn't inherit from SVGLangSpace

   ED: if you allow those attributes you should be able to access them

   CM: the only difference would be that now you could access .xmllang
   on a <style>

   RESOLUTION: Make SVGStyleElement inherit from SVGLangSpace

   <scribe> ACTION: Cameron to make SVGStyleElement inherit from
   SVGLangSpace [recorded in
   [30]http://www.w3.org/2009/04/29-svg-minutes.html#action07]

   <trackbot> Created ACTION-2540 - Make SVGStyleElement inherit from
   SVGLangSpace [on Cameron McCormack - due 2009-05-06].

   <shepazu> \me
   [31]http://www.w3.org/TR/SVGTiny12/painting.html#SpecifyingPaint
   <FuncIRI> [ none | currentColor | <color>] doesn't seem to contain
   syntax for a fallback value...

     [31] http://www.w3.org/TR/SVGTiny12/painting.html#SpecifyingPaint

Summary of Action Items

   [NEW] ACTION: Cameron to check that if it's compatible, make 1.1
   return "" for SVGElement::id when the attribute is missing, and port
   that to 1.2T [recorded in
   [32]http://www.w3.org/2009/04/29-svg-minutes.html#action05]
   [NEW] ACTION: Cameron to drop the SVGExceptions for ISSUE-2261
   [recorded in
   [33]http://www.w3.org/2009/04/29-svg-minutes.html#action06]
   [NEW] ACTION: Cameron to make SVGStyleElement inherit from
   SVGLangSpace [recorded in
   [34]http://www.w3.org/2009/04/29-svg-minutes.html#action07]
   [NEW] ACTION: Cameron to reply to the style/script thread [recorded
   in [35]http://www.w3.org/2009/04/29-svg-minutes.html#action04]
   [NEW] ACTION: Doug to ask HTML WG what they think about parsing
   <param> and <link> in SVG [recorded in
   [36]http://www.w3.org/2009/04/29-svg-minutes.html#action01]
   [NEW] ACTION: Doug to contact the CSSWG about making some more SVG
   attributes properties [recorded in
   [37]http://www.w3.org/2009/04/29-svg-minutes.html#action02]
   [NEW] ACTION: ed to mail public-svg-wg reminding ppl about the
   raleigh F2F [recorded in
   [38]http://www.w3.org/2009/04/29-svg-minutes.html#action03]

   [End of minutes]
     _________________________________________________________

-- 
Cameron McCormack ≝ http://mcc.id.au/
Received on Wednesday, 29 April 2009 08:07:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 29 April 2009 08:07:05 GMT