- From: Cameron McCormack <cam@mcc.id.au>
- Date: Wed, 29 Apr 2009 18:06:04 +1000
- To: public-svg-wg@w3.org
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 UTC