SVG Working Group Teleconference -- 29 Apr 2009

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

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

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> 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 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> 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 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> http://www.w3.org/Graphics/SVG/WG/track/issues/2260

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

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

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 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> 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 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> 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 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 http://www.w3.org/TR/SVGTiny12/painting.html#SpecifyingPaint <FuncIRI> [ none | currentColor | <color>] doesn't seem to contain syntax for a fallback value...

- DRAFT -

SVG Working Group Teleconference

29 Apr 2009

Attendees

Contents