See also: IRC log
<cabanier> scribenick: cabanier
<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Alpha_mask
cm: mask are currently unintuive
since they use luminance
... it is quite confusing
... we opened an issue where you can use the alpha values
... I opened a small proposal where you can specify luminance
or alpha
... there were a proposal where you could combine the 2 by
having a seperate property for each mask type
rc: are alpha values currently ignored?
cm: no they contribute to the luminance.
rc: this is similar to what
PDF
... except noone uses the alpha version
bb: there seems to be some confusion in the spec about what mask apply to
it seems pretty unlikely for a given mask mask element that it can be use for both luminance and alpha
rc: why is that?
cm: it's unlikely that you use the same element but then use it with alpha in one place and luminance in the other
<birtles> (re the confusion in the spec, specifically http://www.w3.org/TR/SVG11/masking.html#MaskProperty says the mask property can refer to "another graphical object", not just a <mask>. That restriction appears earlier in the prose.)
<ed> another way could be mask: <funciri> | none | alpha(<funciri>) | luminance(<funciri>)
<ed> replace those <funciri> in the last two with <iri> I guess though
<ed> that would make it rather easy to do fallbacks because old useragents would fail parsing the css
bb: it would be nice if you wouldn't have to create id's
cm: not everyone puts masks in
the defs
... that does seem handy
bb: very often you have to write a unique id generator to create the id's
cm: maybe we can raise an issue
ed: people have asked for this for gradients
<heycam> ISSUE: Consider allowing <mask>, <clipPath>, etc. as direct children of elements they'd apply to, to avoid IDs
<trackbot> Created ISSUE-2431 - Consider allowing <mask>, <clipPath>, etc. as direct children of elements they'd apply to, to avoid IDs ; please complete additional details at http://www.w3.org/Graphics/SVG/WG/track/issues/2431/edit .
bb: this does impace how it impacts alpha and luminance
cm: you can have new keywords for mask: 'mask: child' and then if there is a mask element child that that is using it as a child.
ed: having a keyword like that
because we don't always traverse into an element. this keyword
would tell us to examine the element.
... I have no problems with the functionality itself
... I think that's what we want
cm: bb do you want to investigate this further?
bb: yes, I would like to look into this further to make sure there are no issues
action birtles to investigate issue 2431
<trackbot> Created ACTION-3205 - Investigate issue 2431 [on Brian Birtles - due 2012-01-19].
action heycam to proposal a final syntax on alpha mask after Brian investigate 2431
<trackbot> Created ACTION-3206 - Proposal a final syntax on alpha mask after Brian investigate 2431 [on Cameron McCormack - due 2012-01-19].
resolution: we will add alpha mask functionality to SVG 2
<ed> http://www.w3.org/Graphics/SVG/WG/track/
ed: until the break we will work on some open actions
<ed> http://www.w3.org/Graphics/SVG/WG/track/users
<heycam> -- doing actions until morning tea break --
<ed> -- <tbreak dur="15min"/> --
<heycam> scribenick: heycam
<ed> previous discussion of this: http://www.w3.org/2012/01/05-svg-minutes.html#item04
DS: there's strong resistance from browser vendors to add elements to the HTML <head>
… because it breaks backwards compat, and requires changes to the parser
… the parser is pretty much set in stone at this point
CL: I don't think we need to put things in head
… our <defs> is like a <div> with display:none
… so you can stick whatever you want there
… there's no need to put it in the <head>
… the only thing we do have that maybe belongs in the head is the <meta> element, though our <metadata> is structured
… in SVG you can nest elements in <metadata>
… so it really doesn't belong in <head> either
DS: I do think it's not unreasonable for people to think they should add things to the head
CL: at first sight it's very reasonable
DS: I think our best course of action is not to follow up on hixie's recommendation to define our elements as metadata content
… rather to simply to educate people that you can't do that
… I think it's very unusual that hixie would recommend this course of action
… I will respond to the original commenter
RESOLUTION: SVG will not allow elements to be put in HTML <head>
<ed> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Shorthand_presentation_attribute
<birtles> ScribeNick: birtles
CL: CM's proposal on the wiki where you put the shorthands before all the properties in doc order satisifies my earlier concerns
CM: proposal is to allow pres
attr for properties which are shorthands
... at the moment you can't write marker="" b/c marker is a
shorthand
... creates confusion for authors
... don't understand why they need to use marker-start etc. if
they're using pres attr
... with style you can just use "marker"
... last time this issue came up was in context of when CSS
properties get split and orig becomes a shorthand
... e.g. overflow becoming overflow-x and overflow-y
... overflow is now a shorthand
CL: likewise whitespace might go that way
CM: we want to allow overflow to
continue to be a pres attr
... even if it becomes a shorthand
... original reluctance was you have multiple attr targetting
the same property
... and override behaviour was not clear since attr are
unordered
... unlike styles where you have doc order
... but the proposal addresses that by taking shorthands
first
ED: so you if have marker-mid
before marker (as attributes) then marker will override
marker
... so you if have marker-mid before marker (as attributes)
then marker will override marker-mid
CL: it's something we're going to
have to address with properties being split up and becoming
shorthands
... any comments from implementors?
ED: it's probably fine but I need
to check the code
... it would be pretty simple to verify if there were some test
cases
CM: I think it should be ok
... is there a difference between animating the style or the
presentation attribute
CL: attributeType is just for
disambiguation when the attribute name and property name
overlap and are not the same thing
... not to provide different behaviour
RESOLUTION: We will allow shorthand properties to be used as presentation attributes (ISSUE-2430) according to Cameron's proposal
<scribe> ACTION: Cameron to describe using shorthand properties as presentation attributes in spec [recorded in http://www.w3.org/2012/01/12-svg-minutes.html#action01]
<trackbot> Created ACTION-3207 - Describe using shorthand properties as presentation attributes in spec [on Cameron McCormack - due 2012-01-20].
ED: is there an order normally to style
<heycam> ACTION-3207: http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Shorthand_presentation_attribute
<trackbot> ACTION-3207 Describe using shorthand properties as presentation attributes in spec notes added
CL: yes, if it's in a stylesheet (incl style attr)
ED: if you start modifying the element by script, then the order is not guaranteed
CL: the assertion was attributes are unordered
CM: the stylesheet is not exposed
to script though right?
... you can getComputedStyle but there's no order requirement
there
ED: if it's just for when it's parsed then it's ok
CM: even if you're modifying the
attr then you still need the shorthand first
... if you're actually creating stylesheets you could create
two (one for shorthands)
... might be simpler than managing the order
ED: what about font? you have to
use CSS rules such as requiring units
... isn't that confusing?
... for all shorthands you have to use units
... whereas elsewhere you don't
CL: it's only really for lengths
where we have this different
... where you don't need units in SVG
... marker etc. are ok
... it's only really 'font'
... so it would be a rule that shorthands have to use CSS rules
which includes using units (and excluding scientific
notation)
CM: what if we came up with our
own shorthand
... that wasn't ambiguous
CL: that would be confusing to
use a different notation
... and might outweigh the benefit of using shorthands
... because you'd add syntax to disambiguate
CM: so we'll just require CSS parsing for shorthand presentation attributes
ED: I think that would be ok, better than adding quirks
CM: what about new CSS
properties?
... we have font-size in SVG so we can explicitly allow
unitless lengths
CL: do we want to revisit
scientific notation in SVG 2?
... because perhaps it's not used?
CM: many scripts default to using exponential notation
CL: we were originally expecting
much more use of the world coord system with very large
numbers
... but in practice you actually run into precision
problems
Up to: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Improve_to-animations
<cyril> we should also deal with http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#SMIL_time_containers
deciding on time containers depends on me finishing action-3202
BB: not sure what this means
CM: I guess it's about addressing differences
BB: what are the differences?
CM: underlying value is fixed, reversing
BB: my guess is reversing?
VH: we should find out what is specificallly required here
<scribe> ACTION: Cameron to contact Dr. Olaf Hoffmann to ask what is specifically required to make to-animation similar to CSS transitions [recorded in http://www.w3.org/2012/01/12-svg-minutes.html#action02]
<trackbot> Created ACTION-3208 - Contact Dr. Olaf Hoffmann to ask what is specifically required to make to-animation similar to CSS transitions [on Cameron McCormack - due 2012-01-20].
ACTION-2308: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Improve_to-animations
<trackbot> ACTION-2308 Draft an email response for the second half of ISSUE-2089 notes added
ACTION-3208: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Improve_to-animations
<trackbot> ACTION-3208 Contact Dr. Olaf Hoffmann to ask what is specifically required to make to-animation similar to CSS transitions notes added
CL: we are going to have transitions anyway based on Patrick's proposal to allow using SVG's attributes in CSS
<cyril> RESOLUTION: SVG 2 will allow CSS-transitions-like animations
<cyril> RRSAgent pointer
<heycam> ACTION-3208: Say to Olaf we have interpreted his request in this way, and we agree, but if he means something else please explain
<trackbot> ACTION-3208 Contact Dr. Olaf Hoffmann to ask what is specifically required to make to-animation similar to CSS transitions notes added
next, Transitions for discretely animated properties, text-anchor in particular
<ChrisL> commenter wants to smoothly animate from
<ChrisL> .................|..................
<ChrisL> SOME_TEXT_1
<ChrisL> SOME_OTHER_TEXT_2
<ChrisL> to
<ChrisL> ................|..................
<ChrisL> SOME_TEXT_1
<ChrisL> SOME_OTHER_TEXT_2
ED: even though text-anchor-end animation is discrete it would be possible to provide linear interpolation
CM: it is a bit of a violation of the model and the idea of "discrete"
<ChrisL> I think that breaks the modelof animation. at all points in the animation, the value of the animated property has to be one of the actual values
VH: there's a difference between calcMode="discrete" and calcMode="linear" that falls back to discrete
CM: if we wanted it to work for text-anchor we could allow it to take numeric values
<ChrisL> we could imaging a mapping with for example-100% as start, 0 as middle,100% as end
CM: e.g. -100 to 100
CL: we could spec it fairly
easily
... I think it's ok if we're just talking about
calcMode="linear" that falls back
... as opposed to calcMode="discrete"
CM: but I often rely on that
fallback behaviour
... and don't specify calcMode="discrete"
CL: if we did this change and people are relying on the discrete behaviour they might get a surprise
<ChrisL> butthey could fix it by adding calcmode discrete to keep the old behaviour
BB: so you have to modify the definition of those attributes to allow numeric values
CL: the approach is to make attributes that take discrete values to be shorthand for those that take numeric values
CM: in font-weight, some of the keywords are synonyms for numbers
CL: but it's an ordered series
CM: what happens when you
getComputedStyle---which do you get? the keyword or the
number?
... likewise what will happen here if we use getComputedStyle
on the new text-anchor etc. that takes numeric values
CL: I'm proposing promoting some
values so that can take *continuous* values
... so font-weight would not be an example
RESOLUTION: SVG2 will allow linear interpolation for properties which were previously discrete
<scribe> ACTION: Chris to write up a proposal for allowing linear interpolation of properties that were previously discrete but could be reasonably interpolated linearly [recorded in http://www.w3.org/2012/01/12-svg-minutes.html#action03]
<trackbot> Created ACTION-3209 - Write up a proposal for allowing linear interpolation of properties that were previously discrete but could be reasonably interpolated linearly [on Chris Lilley - due 2012-01-20].
<scribe> ACTION: Brian to look for text in SVG/SMIL that suggests using different calcMode's based on the values used (enum values versus numeric) [recorded in http://www.w3.org/2012/01/12-svg-minutes.html#action04]
<trackbot> Created ACTION-3210 - Look for text in SVG/SMIL that suggests using different calcMode's based on the values used (enum values versus numeric) [on Brian Birtles - due 2012-01-20].
next, animateTransform with matrix-decomposed like CSS
CM: diff between animateTransform
and CSS Animations with transform property, is CSS considers
the whole transform list, but SVG Animations does one transform
at a time and post-multiplies
... request is to add a new type to animateTransform that
matches CSS Animations
... but we could just <animate> to get that
behaviour
... <animate attributeName="transform" values="scale(...)
rotate(...); scale(...) rotate(...)"/>
... it overrides the whole list
... need to define how additive works with whole lists of
items
VH: so how does animateTransform add to the end of the list?
BB: it differs between
browsers
... if you inspect the animVal in the DOM some browsers will
just append a matrix transform, some will try to preseve the
animateTransform's type, others just replace the whole list
with a matrix
VH: even if we deal with lists we already have a model for adding that to the underlying transform, it doesn't change the model
CC: it doesn't change the
post-multiplication
... it doesn't change the final value
... but it does change the animVal
VH: but given the way the
requirement is worded I think it wouldn't change
... we want to allow <animate
attributeName="transform">
CM: I agree
RESOLUTION: We will support animation using a transform-list
http://dev.w3.org/csswg/css3-2d-transforms/#animation
http://brian.sol1.net/svg/animatetransform-issues/accumulation-of-transformations/
BB: Addition of transforms is a
bit unusual (see above link)
... we can rely on CSS Transform's behviour for interpolation
but we need to specify how addition works for transform
lists
CM: this difference is specific
to animateTransform
... so if we go to using animate, do we want to just use the
default behaviour?
... which would mean adding the transform components rather
than post-multiplication
<scribe> ACTION: Cyril to investigate different methods for adding transform in animation [recorded in http://www.w3.org/2012/01/12-svg-minutes.html#action05]
<trackbot> Created ACTION-3211 - Investigate different methods for adding transform in animation [on Cyril Concolato - due 2012-01-20].
ACTION-3211: http://brian.sol1.net/svg/animatetransform-issues/accumulation-of-transformations/
<trackbot> ACTION-3211 Investigate different methods for adding transform in animation notes added
---break 1hr for lunch---
<vhardy> http://dev.w3.org/SVG/profiles/1.2T/test/htmlObjectHarness/animate-elem-81-t.html
<patrickdengler_> Sorry, I didn't catch the end of this discussion, and I hope you had a good lunch :)
<patrickdengler_> When we talk about adding a new element, such as animateTransform, are we consulting with the HTML group as well?
<patrickdengler_> Not animateTransform but any *new* element (sorry)
<ChrisL> scribeNick: ChrisL
<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Planning_Page
heycam: need some target dates
<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Planning_Page
<heycam> http://dev.w3.org/SVG/profiles/2.0/reqs/publish/
heycam: was supposed to add stuff back into the wiki page from the separate document
ChrisL: and people were to add explanation for the accepted items
vhardy: whatabout use cases?
heycam: should be in the wiki
page
... if its useful we can continue working on a /TR requirements
doc
ChrisL: want oto avoid work that is of no beefit. wiki page is more easily updated
ed: easier to update wikipage
heycam: easier to read a published doc though
cyril: we have 90 left to
do
... out of 180 at the start
... wereat 40% after tpac
vhardy: think its a big effort to migrate to a new document
ChrisL: people do not read reqts
top to tail, they drill down on a particular issue
... still feasible to do by end of this f2f?
cyril: we have 2/3 by scrollbar
birtles: doc gets longer as we edit
ChrisL: earlier ones were more
vague and we took a lot of time to understand the comments.
later ones are specced features from 1.2T so its either in or
out
... next, whatdo we have in fpwd - lots or a little (ipp
implications)
<heycam> CM: the other question is whether we go forward with this grand refactoring of the document that we talked about before
<heycam> … I think it would be better to not do that upfront
<heycam> … instead we just add the features/changes according to the existing structure
<heycam> … so we can get drafts published with them
<heycam> … rather than having the first couple of working drafts just consist of reorganisation of existing text, with no other changes
ChrisL: would prioritise
documenting new features over refactoringexisting ones
... patent exclusions are at fpwd and last call, and are
per-feature
... so its better to at least list a feature even if the spec
is incomplete or the syntax not stable
... want to see tests early
heycam: so when new feature is added, add tests as well
ChrisL (explains how automatic test assertion annotation is added)
ed: good to get some tests using the new harness, to see how it works
ChrisL: we need to decide link mechanisms. WOFF used this new mechanism (but the files were mostly html)
<scribe> ACTION: chris to continue to work on test suite linking mechanism for new harness [recorded in http://www.w3.org/2012/01/12-svg-minutes.html#action06]
<trackbot> Created ACTION-3212 - Continue to work on test suite linking mechanism for new harness [on Chris Lilley - due 2012-01-20].
ed: we can update the milestones to add this testsuite item
<cyril> http://test.csswg.org/
birtles: good reftests use lime green for pass and red for fail
that is not the right link
http://w3c-test.org/framework/
ChrisL (walks through the new reporting framework)
heycam: need stubs for every new
feature for fpwd. say 3 months after the editors draft
... so July
... then another in October for TPAC
vhardy: who can lead the spec editing effort
cyril: needs someone who already has ssh mercurial access
ed: tav has done most of the editing so far
heycam: last entry depends on the feature owners
vhardy: in reqts we have big sections then a lot of tiny ones
heycam: as we go through the list we can allocate owners
vhardy: we need to triage the requirements to prioritise the most important ones
heycam: we did not do that, so we accepted a lot of requirements some of which might not be for 2.0
vhardy: need priority on all the accepted requirements
cyril: once we have commitments for the popular features this will lead to priorities. if no-one commits its low priority
heycam: and if that is loo long we can cut it
cyril: up to individuals how many new features to take on
vhardy: priority needs to be
decided before fpwd
... march is better
<scribe> ACTION: erik to remind people early March 2012 about prioritisation [recorded in http://www.w3.org/2012/01/12-svg-minutes.html#action07]
<trackbot> Created ACTION-3213 - Remind people early March 2012 about prioritisation [on Erik Dahlström - due 2012-01-20].
heycam: looks good for the milestones
vhardy: management nightmare to weigh the priorities
heycam: happy to make a form for that
<scribe> ACTION: heycam to make a form for priorities [recorded in http://www.w3.org/2012/01/12-svg-minutes.html#action08]
<trackbot> Created ACTION-3214 - Make a form for priorities [on Cameron McCormack - due 2012-01-20].
ChrisL: goot time for lc would be after tpac so (with holidays) jan would be good, finished by May/June and CR in August depending on need for a second LC
vhardy: for selecting
requirements we could update - things thatare broken, graphical
features
... for 2.1 2.2 etc we could put the theme that adds value for
each iteration, nt too ambitious each time
... first priority could be graphical features, with animation
and dom refactoring left for a dot release
heycam: seem to have a range of killer things that do not fit those themes
cyril: this discussion is easier when we have a prioritised list
vhardy: main point is to limit the scope to what is acheivable
heycam: ok so lets aim for LC in January 2013
<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/getBBoxOf
heycam: this is getting the bbox
in a different elements coordinate system
... often want to do this
... proposal is to add getBBoxOf that you call in the element
whith the desired coord system and you apss the element you
want the bbox of
... need not be a descendent
cyril: bbox is always axis aligned?
heycam: yes
ed: its like getScreenBBox in Tiny
cyril: (points out an error in the proposal, this and element are transposed
vhardy: do we want a rect or a set of points?
<ed> http://www.w3.org/TR/SVGTiny12/svgudom.html#svg__SVGLocatable_getScreenBBox
vhardy: (draws on whiteboard)
ed: agrees with vhardy, you want four points for a non axis aligned bbox
vhardy: want the points, or an option to get the points
cyril: last step is trivial, min maxso return the points
ChrisL: getBBoxCorners ?
birtles: what will people do more often?
vhardy: adding handles is common so the points would be better there
cabanier: illustrator gives the full bbox
heycam: we don't want to multiply the number of methods unecessarily
cabanier: if you miter corners and transform, miter will go further
ChrisL: recall that we also
wanted to have an inked bbox that includes stroke and
markers
... so for this one which is geometric, stroke mitering does
notaffect it
vhardy: bbox is for dirty areas, editing
birtles: hit testing
ChrisL: for painted bbox we would need the analog of this (get painted bbox in another coord system)
cabanier: if transformed, miters would become sharper
vhardy: we do pre-transform
stroking
... illustrator gives you both
... non scaling stroke strokes the transformedgeometry
heycam: so maybe instead give a much easier way to get quads and then transform them to another coordsys
vhardy: like the quad idea
getBoundingQuad and then transform and getBBox on that
<scribe> ACTION: heycam to revise getBBoxof proposal based on this discussion [recorded in http://www.w3.org/2012/01/12-svg-minutes.html#action09]
<trackbot> Created ACTION-3215 - Revise getBBoxof proposal based on this discussion [on Cameron McCormack - due 2012-01-20].
<vhardy> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Auto-sized_image
<birtles> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Auto-sized_image
cyril: is it auto size or auto scale
heycam: (rapidly corrects
proposal)
... its the same rules css uses for intrinsic aspect ratio
vhardy: the initiial viewport is
there is there is no bbox
... defaults to 100% 100% and the width is known
heycam: so you dont use any 150 300 ratio
cyril: like the idea to not give
w & h if you don't want
... do no t want to break backwards compat
<vhardy> vhardy: at the end of the day, we need to align with the CSS 2.1 behavior.
heycam: prefer 1 over 2 but
itdoes change existing meaning
... second one doesn't
... in old viewers, missing attrs gives zero so no display - do
that all the time
vhardy: if you have w h and viewbox there is enough to work out the aspect ratio
ChrisL: people depend on missed attrs going to zero, so I prefer the second option
vhardy: common case of images with same width and variable height
cyril: so that leads to proposal
2
... how aboutsizing="intrinsic"
ed: i've seen some (rather complex) js driven frameworks that fill out w and h later and it does not want it to render if zero
cyril: used for image preload
birtles: is the preload specced?
(we think not)
vhardy: to display an unknown image you load by script just to calculate the w and h
1 - two
2 - four
ppl voting 1 can live with 2
resolution: image resizing will use option 2 with sizing="intrinsic" as an attr not a property
---break---
<cyril> scirbe: Cyril
<cyril> scribe: Cyril
<scribe> ScribeNick: cyril
CM: are we only having ref tests or scripted tests?
CL: they are not mutually exclusive
CM: yes
BB: the scripted tests have the
advantage of finding the reason for a failure easily
... you don't have to dig
CM: there is the CSS thing (ref test) and the testharness.js
ED: James Graham worked on making
sure it works with our existing test harness
... so it is possible to use the existing test suite if we had
script snippets
... but I' mot sure that's the best way to convert the
tests
... I don't know if the existing test set is the best
test
... Opera is working on publishing the existing animation tests
for SMIL but scripted so that we don't have to look at the
output
... it has some requirements on the API: pauseAnimation, and
setCurrentTime
<ChrisL> http://w3c-test.org/resources/
CC: at TPAC, the break out on testing was explaining how to use the harness
<ChrisL> http://w3c-test.org/resources/apisample.htm
<ChrisL> http://w3c-test.org/resources/apisample2.htm
<scribe> ACTION: Erik to check in an example on how to use the testharness.js [recorded in http://www.w3.org/2012/01/12-svg-minutes.html#action10]
<trackbot> Created ACTION-3216 - Check in an example on how to use the testharness.js [on Erik Dahlström - due 2012-01-20].
CL: the current tests, we only
have the image patches in the case where Batik does not
pass
... now we want one of all
... and they need to be a lot simpler
VH: that could be a real time
sink
... I would like to say that we don't touch the old tests
CL: that's a good comment
ED: apart the animation tests, that should be fine for the others
VH: especially with the new Browser API, is there anything to do screen capture
CL: it has been proposed as modal and for the specific purpose of testing
<ChrisL> but not enabled by default, for security
VH: do we agree to keep the old
test suite
... as is and work on a new one
CL: yes
ED: yes
CL: we can copy over if needed
CM: we would need to annotate the old tests for the coverage evaluation
CL: the current annotation does
not have the granularity
... that we need
... you need an id and a class, the test points to that
id
... I did that with the WOFF spec and it's quite simple
... an id on each assertion and a class for viewers, authoring
tools ....
CM: we got two requests to review
CSS specs
... we need to assign actions so that that gets done
VH: a third one is shadow dom
CL: CSS Values and Replaced Content
<ChrisL> Title: CSS Image Values and Replaced Content Module Level 3
<ChrisL> Temporary URL: http://dev.w3.org/csswg/css3-images/
<ChrisL> Title: CSS Basic User Interface Module Level 3:
<ChrisL> Editor's draft: http://dev.w3.org/csswg/css3-ui/
RC: the first one has gradients
CM: UI has pointer events and
cursor
... UI is meant to be reviewed by 14th of Feb
... Image Values byt the 17th
<scribe> ACTION: Vincent to review the Shadow DOM draft [recorded in http://www.w3.org/2012/01/12-svg-minutes.html#action11]
<trackbot> Created ACTION-3217 - Review the Shadow DOM draft [on Vincent Hardy - due 2012-01-20].
CM: it told dmitry we will find
in the SVG spec, where shadow dom is useful
... I didn't give him a timeline
<scribe> ACTION: Chris to review CSS UI [recorded in http://www.w3.org/2012/01/12-svg-minutes.html#action12]
<trackbot> Created ACTION-3218 - Review CSS UI [on Chris Lilley - due 2012-01-20].
<scribe> ACTION: Erik to review the 3 specs [recorded in http://www.w3.org/2012/01/12-svg-minutes.html#action13]
<trackbot> Created ACTION-3219 - Review the 3 specs [on Erik Dahlström - due 2012-01-20].
<scribe> ACTION: Cyril to review CSS Image Values and Replaced Content Module Level 3 [recorded in http://www.w3.org/2012/01/12-svg-minutes.html#action14]
<trackbot> Created ACTION-3220 - Review CSS Image Values and Replaced Content Module Level 3 [on Cyril Concolato - due 2012-01-20].
<vhardy> ScribeNick: vhardy
<heycam> Shadow DOM spec: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html
<cyril> http://www.w3.org/TR/SVGCompositing/
ag: last time we edited the spec,
I started putting in parts for CSS so that the document could
apply to CSS and SVG, both.
... I do not remember how far we went, and there is more work
to be done.
<cyril> http://dev.w3.org/SVG/modules/compositing/master/SVGCompositing.html
rc: did you send a pointer.
(group looking for the draft).
ag: the wording was changed, for
example, on enable-background, to be generic and talk about
'host language' and use SVG as 'an example host language'. The
document in dev is doing that migration.
... same for knockout and compop
rc: do you remember why did you add Porter Duff.
ag: filters were not enough because when you use the compositing operators in filters, they include the background twice and so you get an incorrect result. This is why we added the PD operators in the spec.
cyril: I have dug up in previous
documents/proposals, one of the reasons was that filters
require a filter region, but for PD, you can do it while
rasterizing and you do not need a region.
... I'll send a link to a document created by Craig
Brown.
... if you have a set of elements that are composited with the
painter's algorithm, and you want to make one compositing
change on one element, you would have to completely modify the
DOM (if using filters).
rc: I would like to see an example to understand.
<cyril> example:
<cyril> <?xml version="1.0" encoding="utf-8"?>
<cyril> <svg>
<cyril> <path fill="#00FFFF" stroke="#000000" d="M103,120.5c0-33.137,26.863-60,
<cyril> 60-60c33.137,0,60,26.863,60,60s-26.863,60-60,60
<cyril> C129.863,180.5,103,153.637,103,120.5z"/>
<cyril> <path fill="#FF0000" stroke="#000000" d="M151,114.5H37V0.5h114V114.5z"/>
<cyril> <path fill="#00FF00" stroke="#000000" d="M223,69.5l-51,58l-76-97L223,69.5z"/>
<cyril> </svg>
<cyril> you want to modify to the third object to be composed with multiply
<cyril> <?xml version="1.0" encoding="utf-8"?>
<cyril> <svg>
<cyril> <defs>
<cyril> <g id="BoverA">
<cyril> <path fill="#00FFFF" stroke="#000000" d="M103,120.5c0-33.137,
<cyril> 26.863-60,60-60c33.137,0,60,26.863,60,60s-26.863,60-60,60
<cyril> C129.863,180.5,103,153.637,103,120.5z"/>
<cyril> <path fill="#FF0000" stroke="#000000" d="M151,114.5H37V0.5h114V114.5z"/>
<cyril> </g>
<cyril> <filter id="X" filterUnits="objectBoundingBox" x="-50" y="-50"
<cyril> width="100" height="100">
<cyril> <feImage xlink:href="#BoverA" result="blah"/>
<cyril> <feComposite in="SourceGraphic" in2="blah" operator="multiply"/>
<cyril> </filter>
<cyril> </defs>
<cyril> this introduces the filter element
<cyril> whereas:
<cyril> <?xml version="1.0" encoding="utf-8"?>
<cyril> <svg>
<cyril> <path fill="#00FFFF" stroke="#000000" d="M103,120.5c0-33.137,26.863-60,60-60c33.137,0,60,26.863,60,60s-
<cyril> 26.863,60-60,60
<cyril> C129.863,180.5,103,153.637,103,120.5z"/>
<cyril> <path fill="#FF0000" stroke="#000000" d="M151,114.5H37V0.5h114V114.5z"/>
<cyril> <path fill="#00FF00" stroke="#000000" comp-op="multiply" d="M223,69.5l-51,58l-76-97L223,69.5z"/>
<cyril> </svg>
<cyril> is much closer to the original
rc: ok, so the argument is that it is easier to use.
ag: thre is more than an ease of use issue, there are functional limitation, the background is included twice.
<cyril> Note that
<cyril> using feBackground has the effect of the background being used twice – once
<cyril> as an input in the filter – and a second time as the result being drawn onto….
<cyril> If the background is not initially opaque this causes strange effects.
rc: I have proposed to separate
the spec. in two. For PD, you never need the background.
... explains the way PD happens within a group and does not
effect anything outside the group.
<svg>
<rect id="r1">
<g>
<rect id="r2">
<rect id="r3">
</g>
No matter what the compositing operator is on r3, it only composites with the content of <g> at the time it is rendered. In this example, only with r2. There is no compositing done with r1 when rendering r3.
The rendering of <g> will then composite with r1.
<Anthony> http://www.svgopen.org/2005/papers/abstractsvgopen/
Discussion on enable-background and compositing, looking at the examples in section 8 of http://www.svgopen.org/2005/papers/abstractsvgopen/.
There is agreement that compositing is done between a src and dst and that following the painter's algorithm, the default dst would be the content of the parent group at the time an element is rendered (i.e., the rendering of the element's previous siblings in the parent group). There might be use cases for compositing with the a destination that contains the rendering of the parent group's siblings. In the preceding example, it means that r3 would
composite with either the content of its parent group (r2 only) or, in a different mode, with the content of r1 and what is already in it's parent group (r2).
ag: the reason for the naming of new/accumulate is that it describes the initialization of the group buffer used with compositing.
<scribe> ACTION: cyril to work with Rik and discuss with Alex to resolve whether, for the purpose of compositing only, we need a control to select the destination used for the compositing operation. [recorded in http://www.w3.org/2012/01/12-svg-minutes.html#action15]
<trackbot> Created ACTION-3221 - Work with Rik and discuss with Alex to resolve whether, for the purpose of compositing only, we need a control to select the destination used for the compositing operation. [on Cyril Concolato - due 2012-01-20].
Moving on to blending.
(discussion about enable-background in blending context).
<svg>
<rect id="r1">
<g>
<rect id="r2">
</g>
r2 is multiply
g is is enable-background: accumulate
Agreement that in both compositing and blending, the behavior and controls for enable-background are the same. In both cases, the need is to control how the 'group' buffer is initialized before it is used as an input in the blending or compositing operation.
(demo of compositing, blending and knockout groups in a popular illustration authoring tool)
<cabanier> example of knockout and enable-background: http://lists.w3.org/Archives/Public/www-archive/2012Jan/att-0007/KO_isolate.pdf
RESOLUTION: the group agrees to separate compositing from blending in the specification. The group agrees to add the missing blend modes. The group agrees to have the default blend mode to be 'normal'.
<scribe> ACTION: rik to resolve issues on clip-to-self, enable-background on compositing and knock-out. [recorded in http://www.w3.org/2012/01/12-svg-minutes.html#action16]
<trackbot> Created ACTION-3222 - Resolve issues on clip-to-self, enable-background on compositing and knock-out. [on Rik Cabanier - due 2012-01-20].
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/CM: do we/CL: do we/ Succeeded: s/then/... then/ Succeeded: s/ecery/every/ Succeeded: s/Get/get/ Succeeded: s/getScreenBox/getScreenBBox/ Succeeded: s/swt/set/ Succeeded: s/d=// Succeeded: s/seen lots of js driven stuff that fills out w and h later and it does not render if zero/i've seen some (rather complex) js driven frameworks that fill out w and h later and it does not want it to render if zero/ WARNING: No scribe lines found matching ScribeNick pattern: <Cyril> ... Found ScribeNick: cabanier Found ScribeNick: heycam Found ScribeNick: birtles Found ScribeNick: ChrisL Found Scribe: Cyril Inferring ScribeNick: cyril Found ScribeNick: cyril Found ScribeNick: vhardy ScribeNicks: cabanier, heycam, birtles, ChrisL, cyril, vhardy WARNING: No "Present: ... " found! Possibly Present: ACTION-2308 ACTION-3207 ACTION-3208 ACTION-3211 Anthony CC CL ChrisL DS ISSUE RC Title VH ag bb birtles cabanier cabanier_ cm cyril ed example fat_tony heycam jun patrickdengler_ scirbe scribenick shepazu stakagi thorton_ trackbot vhardy whereas You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Got date from IRC log name: 12 Jan 2012 Guessing minutes URL: http://www.w3.org/2012/01/12-svg-minutes.html People with action items: brian cameron chris cyril erik heycam rik vincent[End of scribe.perl diagnostic output]