See also: IRC log
<trackbot> Date: 30 August 2012
<krit> Zakim: aaaa is me
<scribe> scribenick: nikos
<heycam> http://www.w3.org/mid/FBBDBDBC-F3CD-404E-AFC1-0369A75DAA89@adobe.com
krit: Doesn't matter about the
version. I'd just like to use CSS image
... then we get linear gradient and other gradients
... If we use CSS image as a paint server then it's possible to
use images or filters or anything that is defined by CSS
image
birtles: What about making paint
servers part of images?
... a lot of CSS specs refer to image values, why not do it the
other way around
... then you could use an SVG gradient in CSS
krit: That is in CSS4 image
<ed> so <rect fill="linear-gradient(bottom, rgb(149,227,138) 47%, rgb(179,255,166) 74%)" .../> for example
krit: we need to figure out how
it works because it could lead to circular dependency
... The element function can reference paint servers from
SVG
heycam: Do you want paint server references just inside that element or do you allow urls?
<krit> http://dev.w3.org/csswg/css3-images/#image-values
krit: I am just asking if we can
use the css image type in SVG fill and stroke properties
... in the beginning I'd be fine with gradient
<heycam> ack
krit: image would be cool but if we just have gradient that would be good
cyril_: for gradients or patterns
you have the gradient limits that tells you how the gradient
space maps to the image space
... how would you do that
krit: you need to define how the bounding box is defined for svg and it would maybe be object bounding box
cyril_: would the svg objects crop the image or would the image be entirely contained in the svg object?
krit: you mean referencing an image with a url?
cyril_: any image. css3 image
fills an object with an image
... you might end up with an image size different from the svg
object size so you need to crop, or reflect, or something
krit: at the beginning we might just define gradient. its easier
<krit> http://dev.w3.org/csswg/css3-images/#gradient-type
cyril_: Using percentages or
integers or fixed values, you can say the image will take more
or less than the bounding box of the object
... you have to define if you crop, or what you do
krit: I agree with that
... At the beginning I'd be fine to just use gradients as this
isn't a problem for them
... you just need to define a box, and we'd just use the object
bounding box
heycam: I think cyrils concern
was that it's not clear whether gradients cover the entire box
or whether you pad or repeat
... I think we need a way to specify whether you repeat in
horizontal or vertical directions
nikos: I think dirk is saying you use the object bounding box so the dimensions always match up
cyril_: in css gradients I don't think you can specify where the 2 end points of the vector defining the gradient are - except for top or bottom
heycam: you can give a length value
cyril_: I'm seeing left, right,
top, bottom, thats it
... you can't say I want the points to be 10% inside
... then you don't have to specify pad or repeat
... there is a repeating linear gradient
krit: that's a limitation in css gradients in general, why is it a problem for svg?
cyril_: I'm just saying it needs to be specified how the object is filled when the gradient is not big enough
heycam: from what I can see it
will always be big enough
... you have stops that go from 0 to 100%
cyril_: Yeh with gradient it seems you will always fill the object
heycam: With images I think
you're right about fitting.
... Are the only types images and gradients?
cyril_: url image_list and gradient
heycam: I'm sure we could define
how the image renders without adding more controls like various
background repeat properties
... I don't know how useful it is to solve that here
... maybe in that case you need to use a pattern for
example
krit: Can we resolve for linear gradient and solve the other problems later?
heycam: I'm happy with it
ed: I agree
cyril_: what would be the benefit compared to using svg gradient?
krit: you can apply a linear
gradient to a class of object
... and use the same gradient for html and svg content
cyril_: ok
heycam: it's also an easier way to specify a gradient
Resolution: Paint values will allow gradients from CSS3 image
krit: CSS image 3 is already a REC
<heycam> http://dev.w3.org/csswg/css3-images/#repeating-gradients
heycam: I see you can do repeating gradient styles in CSS
cyril_: in any case it's going to fill the whole object
krit: will it be in the SVG2 FPWD or is it for the future?
heycam: I think we've discussed this before in the context of referencing as many CSS specs as possible
krit: so SVG 2 then
... next draft release
heycam: If you have time
<scribe> ACTION: Dirk to edit SVG 2 draft to add CSS 3 gradients as a paint value [recorded in http://www.w3.org/2012/08/30-svg-minutes.html#action01]
<trackbot> Created ACTION-3346 - Edit SVG 2 draft to add CSS 3 gradients as a paint value [on Dirk Schulze - due 2012-09-06].
ed: I sent my comments to the
public mailing list
... I think it addressed both discussions
... feOffset and how to define input and output clipping
<ed> http://lists.w3.org/Archives/Public/www-svg/2012Aug/0143.html
ed: so in Opera we treat feOffset not exactly as the spec tells us to, because if you consider the example in the mail, feOffset itself doesn't specify a primitive subregion - doesn't have x, y and width. Intuitively for me I wouldn't expect it to clip, I'd expect it to move the previous primitive
krit: I would agree that we don't
need to clip the offset, we move it around
... Do you clip if you move a primitive to the outside of
filter regions then bring it back in?
heycam: do you clip at each step or just once at the end?
ed: Could you post an example?
<krit> <filter id="feoffset1" primitiveUnits="objectBoundingBox" x="0%" y="0%"
<krit> width="100%" height="100%">
<krit> <feFlood width="100%" height="100%" flood-color="lime"/>
<krit> <feOffset dx="0.1" dy="0.2"/>
<krit> </filter>
ed: So you move the result out
and back again?
... what would you expect in that case?
krit: I think the spec says it's
clipped away
... when you move it back you are just moving transparent black
back
ed: I'm not really sure what I'd
expect in that case
... I think I might expect to be able to move the result
back
... it would be interesting to see what the implementations
do
krit: it would be interesting to see what gaussian blur does
ed: I think it would be interesting to have some way of letting the user agent find out what the filter region is automatically, but we'd have to be careful not to break content
krit: In this case we definitely
should clip, the question is does opera clip
... Do you clip the input or the output?
... that's a general question
ed: I think we do input clipping
krit: filter effects spec requires input and output clipping, which is not useful in my eyes
ed: So do we want to control this, or do we require one particular way?
krit: I think both input and
output is not useful
... I don't care if we go with input or output
heycam: what might break if we switched? if we specified just output
krit: we are really discussion an edge case so I wouldn't expect much to break
heycam: it only matters to
primitives that do things outside their region
... most filter primitives say their input and output regions
are the same
... is that right?
krit: by default, firefox's
subregion depends on the previous subregion so if you have 2
filters of different size, it is the union of both
... when you specify x, y, w and h what should be clipped, the
input or the output?
ed: do you have a test case?
krit: I have posted something to the mailing list
ed: I'm looking for something that doesn't use feOffset
krit: it's difficult without feOffset
ed: We treat it differently, we don't take the union of the inputs, we use the filter region itself if you don't specify
heycam: apart from whether you do clipping on input or output. Dirk, do you think it makes sense to special case feOffset?
krit: if you don't have input
clipping it doesn't matter
... in that case the subregion depends on the clipregion of the
feOffset filter
... I'd have to think about it some more
... right now the specification wants to clip to the region
always
heycam: the spec only says clip
the input and output both
... to make feOffset more useful, would we need to change it to
only output or only input? or is that a separate issue
krit: I think it's separate
ed: I think it would be nice to have an analysis of where and when it's useful to have each clipping method
heycam: I think it would be good too, I find it hard to visualise why you'd take one or the other
ed: There's one example in the
spec but I don't think it uses feOffset
... There's also the example from the mail and the bug
report
... but apart from that I don't think we have many tests for
this
<scribe> ACTION: Dirk to investigate and expand on the proposal of sub region clipping for Filter Effects [recorded in http://www.w3.org/2012/08/30-svg-minutes.html#action02]
<trackbot> Created ACTION-3347 - Investigate and expand on the proposal of sub region clipping for Filter Effects [on Dirk Schulze - due 2012-09-06].
heycam: what about for the other issue of whether feOffset behaviour should be special?
krit: I'll look into that as well
ed: They're similar but not quite the same
<krit> nikos: great, thanks. Let us share the examples next week
<krit> haha
heycam: i imagine you could construct the filter to avoid the problem - don't shift outside the region
ed: not many people write such advanced filters that they would run into this issue
heycam: we'll pick up the discussion once dirk has had a look
heycam: does anyone support percentage values for dx and dy?
krit: if you use 50% then it is
treated as 50
... on webkit
heycam: we should make percentages work or disallow them
krit: We already support percentage - but indirectly
heycam: why is it that dx and dy
unitless values are treated as unit bounding box values and not
...
... if you have unit less values they are just user units
... there's nothing weird and I'd expect percentages to be
percentages of the viewport
... if you have primitive space = user space on use, dx and dy
should be percentages of the viewport?
krit: if you supported percentages, but we don't
heycam: do we have other primitives that take percentages?
krit: no
heycam: my feeling is that we should make percentages work
krit: and for other cases?
... where percentages could work?
heycam: so the issue with standard deviation is it's a number not a length right?
<krit> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#FilterFunction
heycam: in the corresponding
shorthand if we are going to support lengths, we should take
lengths in the element
... I'm thinking whether it would be more consistent in general
to support that, but I'm not sure that it's important
ed: is there any particular
examples?
... I'm looking for some kind of testcase to try out
... just wondering if you had one handy
heycam: I think dx and dy look like they go with width and height, you might expect them to take the same kinds of value
krit: I agree
heycam: I would be happy to say dx and dy take lengths and percentages and forget about the other things like standard deviation
ed: I'd like to see an example before we make any changes
<scribe> ACTION: Dirk to provide examples of percentages with dx and dy in Filter Effects [recorded in http://www.w3.org/2012/08/30-svg-minutes.html#action03]
<trackbot> Created ACTION-3348 - Provide examples of percentages with dx and dy in Filter Effects [on Dirk Schulze - due 2012-09-06].
<krit> http://dev.w3.org/csswg/css4-images/#image-fragments
heycam: Robert brought up in the
mailing list some text in the linking chapter that talks about
how you must use commas rather than spaces in the viewbox part
of an svg fragment. You can use %20 to encode spaces but it's
easier to use commas.
... there's a similar issue in preserve aspect ratio, because
you can have the slice value after the xMinyMin part
... and that normally takes a space between them
... I think viewbox also would normally take a space, so
there's no issue saying just use a comma
... I think Robert was asking for a clarification on the
grammar
krit: I don't like spaces in
iri
... I pasted a link to css image fragments, they comma
separate
... I don't have a really strong opinion but I feel its more
natural
heycam: I agree, you don't really want to url encode
ed: I agree with the comma, even though I don't like the svg view syntax.
krit: the css specifications use
uri and svg uses iri
... in theory there's a difference but in practice there's
not
... do we have a strong opinion that we should use iri?
heycam: I raised something on the mailing list about the differences. I didn't get a clear idea in the end whether one or the other should change or whether we ignore the situation
krit: Filter Effects uses iri and
the discussion on exclusions they want to use parts of svg that
use iri
... it would be good to harmonise the specifications
<heycam> http://lists.w3.org/Archives/Public/www-style/2012May/0772.html
heycam: here's the mail where I
asked how things in brackets are parsed, because I think the
spec doesn't really say.
... I didn't really get a satisfactory answer
ed: The Filter Effects spec uses iri because SVG 1 used iri
heycam: If you look at the data url in the email I linked to
krit: iri just supports more characters right?
heycam: yes, you can use non
ascii characters
... for uri you would have to escape them somehow
... the test uses a css background image that has some non
ascii characters
... and that seems to work everywhere so I assume browsers are
interpreting as iri
krit: you tested locally?
heycam: no it's on a server
... if you view my example and 'view source'
krit: it doesn't work in Safari
ed: It doesn't seem to wokr in Opera either
heycam: It may be because I left
a bracket out of the example
... I think the issue is that the css spec needs to define how
things inside the url brackets are parsed and interpreted
<heycam> http://lists.w3.org/Archives/Public/www-style/2012May/0824.html
<heycam> http://räksmörgås.josefsson.org/raksmorgas.jpg
heycam: That's the test I meant
to do... oh wait it doesn't have the brackets either
... I tried to link to that url in background-image
... I think the css spec needs to say that the things in the
brackets are interpreted as iris or whatever they need to do to
take non ascii characters
krit: Can you bring it up with the css group?
heycam: well I sent the mail, I
think if you want to bring it up you can
... back to the topic. I think the question is whether we allow
commas or spaces
<heycam> https://svgwg.org/svg2-draft/linking.html#SVGFragmentIdentifiers
heycam: if you look at the
grammar, you can see that the part of the grammar that refers
to preserve aspect ratio, aspect params is defined in the list
beneath and it's not defined properly
... given that spaces are said to be not allowed, we need to
define it so that spaces are allowed or we can allow a
comma
... I don't have a strong preference
ed: i was wondering about another
issue, url escaping, firefox did allow the url escaped spaces
to work
... I couldn't find anything in the spec but it would be nice
to have it clarified
heycam: I'm not sure what what
level it should do that
... is suspect if we look at the html spec it will define
it
... there was meant to be a new url spec, but I don't think it
progressed much
... I think it was going to define this sort of thing
shepazu: is anyone working on it?
heycam: I think so but I don't
know
... I suspect that that spec would define how to encode the
fragments and decode them
... that's the level it should be at
... I agree it would be nice to have a link to somewhere that
defines how to parse these fragments
<scribe> ACTION: Cameron to look at the url spec or find out what we need to reference to make sure url fragments have a well defined encoding and decoding [recorded in http://www.w3.org/2012/08/30-svg-minutes.html#action04]
<trackbot> Created ACTION-3349 - Look at the url spec or find out what we need to reference to make sure url fragments have a well defined encoding and decoding [on Cameron McCormack - due 2012-09-06].
heycam: Erik or anyone do you
have an opinion on what to do with the preserve aspect ratio
part?
... I don't have a strong opinion
ed: this is a special case, I'd
prefer if parsing was the same as the attributes
... might not be possible
heycam: we can make it possible
ed: that would be easier
implementation wise
... it's not hard anyway but consistency would be nice
shepazu: consistency means a better experience for everyone
heycam: are there any other examples?
shepazu: any attribute can have keywords
<ed> requiredFeatures is space-separated I think
<ed> http://www.w3.org/TR/SVG11/struct.html#ConditionalProcessingRequiredFeaturesAttribute
heycam: I think you can't just
have an arbitrary name in there or the property would fail to
parse
... I was wondering about non property attributes
... I don't know any off the top of my head
... I'm concerned whether we allow commas in preserve aspect
ratio whether that will lead to it happening elsewhere
... there may not be any other cases
shepazu: there's the text, they're not keywords, they're values. Like x or y for text
heycam: we do allow commas there
shepazu: there was a kerfuffle
with stroke dash array because it wasn't specified
... we fixed that
<shepazu> http://www.w3.org/TR/SVG/attindex.html
heycam: Unfortunately the type of
value isn't in that table
... there's things that take number-space-number and they don't
take commas
shepazu: number-delimited-number
should allow anything
... should allow comma or space or a combination rather
... oh transforms!
... you can have a space separated list of values and I don't
think you can use a comma there
heycam: I think you're right
krit: they can be comma or space separated
heycam: they can in the attribute but not in the property
viewbox and zoomAndPan are the only ones I can see
heycam: let me, suggest we allow commas in preserveApsectRatio
<richardschwerdtfe> have to drop
Resolution: preserveAspectRatio will allow commas in the attribute and that part of the view specification
<scribe> ACTION: Cameron to update preserveApsectRatio in view specification to allow commas [recorded in http://www.w3.org/2012/08/30-svg-minutes.html#action05]
<trackbot> Created ACTION-3350 - Update preserveApsectRatio in view specification to allow commas [on Cameron McCormack - due 2012-09-06].
heycam: We might need to discuss this at the F2F
shepazu: I think that we should not capitalise anything
heycam: I think that's what Simon
wanted
... at least on new things
<shepazu> CAPITALIZE NONE OF THE THINGS!
heycam: Maybe allowing lowercase everywhere might be the cleanest solution
shepazu: I'm struggling to think
of a place where caplitalisation would matter if we had error
correction
... is there anywhere where capitalisation would matter?
heycam: it matters from the
perspective of making a dom call
... you need to use the correct capitalisation there
... I want to think about this more deeply
... it might tie in with switching modes in the SVG DOM
... like switching to no namespace
... and in that case everything is in lower case, for
example.
... I do think it's an issue that we need to resolve.
... or if we keep inventing camel case names we need to make a
concious decision to go that way
... we'll continue the discussion at a later point
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/definining/defining/ Succeeded: s/people write advanced filters/people write such advanced filters that they would run into this issue/ Succeeded: s/IRI/iri/ Succeeded: s/preferences/preference/ Succeeded: s/somwhere/somewhere/ Found ScribeNick: nikos Inferring Scribes: nikos Default Present: +1.415.832.aaaa, birtles, nikos, krit, ed, [IPcaller], heycam, +33.9.80.39.aabb, Rich, cyril_, +33.9.53.77.aacc, Tav, Doug_Schepers Present: +1.415.832.aaaa birtles nikos krit ed [IPcaller] heycam +33.9.80.39.aabb Rich cyril_ +33.9.53.77.aacc Tav Doug_Schepers Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2012JulSep/0179.html Found Date: 30 Aug 2012 Guessing minutes URL: http://www.w3.org/2012/08/30-svg-minutes.html People with action items: cameron dirk[End of scribe.perl diagnostic output]