See also: IRC log
<trackbot> Date: 27 April 2009
<scribe> scribe: erik
<scribe> scribeNick: ed
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
... 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 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].
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?
... 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 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].
CM: I'm not that familiar with
... 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
... 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
... 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
<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
<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 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].
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 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].
DS: any reviews so far, besides heycam?
AG: not yet
ED: only read the proposals so far
DS: heycam has proposed an
... 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
... 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
... 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?
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
... 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
... so I'd like to say e.g 100%-5px without having it in a URL
CM: calc in CSS provides
... 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
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
... 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
... 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 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 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 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
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at 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: http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0072.html Found Date: 27 Apr 2009 Guessing minutes URL: http://www.w3.org/2009/04/27-svg-minutes.html People with action items: ds ed heycam[End of scribe.perl diagnostic output]