See also: IRC log
<trackbot> Date: 15 August 2013
<TabAtkins> Dear SVG: Please kill your namespaces faster. Love, Tab.
<krit1> TabAtkins: we would need to add the SVG elements to the HTML parser
<scribe> scribenick: nikos
<TabAtkins> krit1++
<TabAtkins> But really it's the xlink that's killing me today.
<TabAtkins> Which requires only local changes to the language.
<heycam> Removing xlink is something we can do without a lot of the other stuff.
<cabanier> I thought we already agree to killing that off
<krit> https://dvcs.w3.org/hg/FXTF/raw-file/tip/matrix/index.html
<TabAtkins> Yeah, but it's not edited in yet. ^_^
<krit> http://dev.w3.org/fxtf/matrix/
heycam: we haven't published this yet?
krit: correct
... 2 issues
... first is name. CSS WG doesn't want CSS prefix
heycam: dictionary ones don't
matter since they're not exposed in script
... interfaces intended to be used outside probably shouldn't
have css in the name
krit: suggestion was either
TransformationMatrix or TransformMatrix
... I don't have others
heycam: if we named it Matrix, there might be a risk of conflicting with scripts that define Matrix already
krit: we also have conflict with
other working groups
... was discussed on fxtf mailing list
... was suggested to name it Deprecated Matrix
heycam: ugly name!
cabanier: web gl want to have
something more primitive
... not useful for authors. The reason we are doing this is to
make operations easier for them
heycam: I'm not convinced by
argument that we shouldn't have it becaues JS authors can write
something that can run faster
... browsers can implement with native js behind the scenes and
avoid the overhead
<TabAtkins> I'm down with TransformMatrix.
krit: because Matrix is so generic, I don't think it's a bad idea to have a prefix
heycam: you said CSS WG has already resolved to publish? what was their final view on name? have an issue in the spec?
krit: we need the name for the url though so it's problematic to do that
heycam: I think it would be fine,
even if we call it CSSMatrix or TranformMatrix to have the url
as just matrix
... I'm fine with publishing and including an issue
krit: CSS WG suggested SVG WG takes care of publication
heycam: couple of other issues
open in the spec
... 1. w part of the point
krit: the main is whether we use
float or doubles
... Mozilla wants floats. Apple wants double
... difference is 10 times on mobile
... javascript just uses double
... so it's just the internal calculation results
... currently I am using doubles in the spec
heycam: I don't think we need to
resolve that before publishing
... what is the plan for replacing SVGMatrix with
CSSMatrix?
krit: The whole point of this is to replace SVGMatrix
heycam: so we'll just use CSSMatrix. Won't have any inheritance.
krit: It's backwards compatible, except the new matrix won't throw exceptions as SVGMatrix did
heycam: I also remember roc was
concerned about the matrix object being used for 3d and
2d
... meaning you need the extra components
krit: I think he's ok with it now
heycam: I'll check with him
resolution: Publish first public working draft of new matrix specification
<scribe> ACTION: Cameron to organise FPWD publication of new matrix specification [recorded in http://www.w3.org/2013/08/15-svg-minutes.html#action01]
<trackbot> Created ACTION-3517 - Organise fpwd publication of new matrix specification [on Cameron McCormack - due 2013-08-22].
<krit> http://www.w3.org/Graphics/fx/wiki/Filter_effects
krit: Erik put together an
implementation matrix
... We need to specify exactly how subregions are
calculated
... I would like feedback on the table
... especially where we have question marks
... we're not clear on how to calculate subregions for some
filters at the moment
... it's important that the filter region doesn't clip things
you don't want clipped
... a lot of people don't understand the 10% margin
heycam: I never liked it. It's
not usually what you want
... are you suggesting to remove filter region primitive
attribute?
krit: no
... if they are not present then the user agent should
calculate automatically
heycam: so changing the default
krit: in a way that fixes content
heycam: I'd be in favour of that
krit: so we need to specify what unbound? is for each in the table
heycam: for filters like feFlood or feTurbulence that conceptually have infinite output, what would we define apart from 'implementation needs to work out how much of the final rendered element to keep'
krit: we could specify 120%. it's not nice though
heycam: can't we just state it needs to be large enough so that it doesn't affect filter output?
krit: If you use feFlood and it
will fill the whole SVG file.
... could use the viewPort
heycam: feFlood is a special case
though
... why can't we say something like 'minimal area based on how
that filter primitive is used in the filter chain'
krit: Need to specify that content looks equal on all implementations
heycam: I think that can be
achieved by saying the filter primitive is big enough so that
it doesn't look different
... when the element is rendered, there will be some clipping
at some point
... then you can determine the smallest rectangle based on how
it is used in the filter chain
... we can require UAs to generate the filter primitive at the
required size
krit: I agree. feFlood is still the problem though
heycam: If you didn't have any other clipping, then feFlood would fill the viewport
krit: Would have to check about breaking content
heycam: do you feel we need to specify how to calculate the area for that primitive?
krit: I think that's a good
idea
... to ensure consistency between implementations
heycam: I'd be fine if we had something like that written down. Do you want to do that?
krit: yes
<scribe> ACTION: Dirk to specify how to calculate automatic filter region for unbounded primitives [recorded in http://www.w3.org/2013/08/15-svg-minutes.html#action02]
<trackbot> Created ACTION-3518 - Specify how to calculate automatic filter region for unbounded primitives [on Dirk Schulze - due 2013-08-22].
intermediate results
krit: a lot of filter effects
short hands can be represented with a color matrix
... ideally you can collapse the filter chain to a single
operation on the matrix
... but we currently define that values should be clamped at
each stage
... do we want to keep current behaviour or can we relax the
specification to allow optimisation in this case?
... it's a balance between performance and ease of
authoring
heycam: is there a benefit to
clamping at each filter? is that something authors would need
or want?
... there are similar thinks in CSS with color values
... I can't remember where exactly but it talks about allowing
values to go out of range and clamp in the final step
... so there might be precedence
nikos: I think it would be confusing for authors to get different results depending on whether a shorthand is used or not
heycam: my feeling is that we should allow intermediate results to go out of range and clamp at the end
<krit> :D
krit: initially I was for
clamping at the end. Now i'm not sure. There are cases where
you can guarantee that you don't need to clamp
... so I support clamping at each step now
heycam: I can't see an author use
for clamping each stage
... if there was one I think it would be better to have
explicit control to opt in to that
krit: there is another case.
contrast 200% then another filter primitive with contrast 50%
and they wonder why they don't get the same result
... it's a corner case though. I don't think it's actually
useful to do that.
heycam: I can imagine cases where
an image has colour values that are almost fully bright and you
apply a brightness filter and you want to clamp
... I'm not sure which I prefer
krit: I think we should keep the clamping for now
shepazu: I've seen some pretty crazy stuff come out of authoring tools
heycam: I'm not sure how much
performance benefit there is from collapsing down to a single
operation on a colour matrix
... I think implementations often slow down with filters
because they are creating lots of off-screen surfaces
... here that shouldn't matter as you can work on the same
surface
resolution: maintain clamping colour matrices for filter effects at each step in the filter chain
shepazu: there are 2 community groups you guys might be interested in
1. SVG accessibility
<shepazu> http://www.w3.org/community/svga11y/
<shepazu> http://www.w3.org/community/svga11y/2013/08/15/roadmap/
2. geometry API
<shepazu> http://www.w3.org/community/geometryapi/wiki/Use_Cases_and_Requirements
<shepazu> http://www.w3.org/community/geometryapi/
use cases and requirements doc (in progress)
SVG accessibility is unclear. There's few normative requirements, a lot comes from the doc that Charles wrote about mapping and authoring guidelines
shepazu: very old. refers to SVG
1.0
... After talking to accessibility experts. The state of SVG is
ok, but there's a lot of tests that need to be run
... so the whole point of this group is to write tests and
write requirements
... we're going to have a workshop/hackathon
heycam: sounds good. for me I don't feel I have the knowledge to know what we need to change in SVG
krit: who would attend the workshop?
shepazu: there's about 16 people
in the group now.
... we want: 1. Accessibility experts who can help us test. 2.
People who use accessibility features. 3. SVG people
... and at least one 'testing' expert
... I gave a presentation about accessible data visualisation
and people were really interested
... that's where this came from
... first step is to make a bunch of tests, run them and create
an implementation report
nikos: what's the make up of the group. Who do you need?
shepazu: we have lots of
interested accessibility experts.
... they should be able to find people who use accessibility
features
... there's two or three people who are pretty good with
SVG
... would be good to have Rich in the group
... looking for someone from Adobe
... I'm looking at September for the hackathon
... October at the graphical web would be good. Cyril, Tav, and
Nikos will be there
... so we can chat about that and try to organise a time that
is good for everyone
... The other group is the geometry API community group
... the goal there is to come up with a geometry api
(SURPRISE!)
... we want to meet use cases for SVG primarily. But if we
satisfies use cases for other web tech that's ok.
... I want to be able to do things like calculate intersection
of shapes
cabanier: Dirk and I signed up
shepazu: If we can come out with a simple set of use cases and requirements that we might include in SVG 2
krit: should get some SKIA guys in the group
cabanier: is this part of SVG or is it just something that interfaces with SVG?
shepazu: I guess you could interact with other web tech
krit: it would be great to have a document that everyone could reference
shepazu: it would be good to have
more people in the group to define the use cases that are
important
... it would be good to have a matrix library (SKIA has), point
and vector maths
... need to drive requirements on those
... in conclusion. It would be good to get people into the
groups to drive the conversation and keep them going
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/matrix as just url/url as just matrix/ Succeeded: s/siz/size/ Succeeded: s/colour/color/g Found ScribeNick: nikos Inferring Scribes: nikos WARNING: No "Present: ... " found! Possibly Present: Doug_Schepers IPcaller TabAtkins cabanier heycam https joined krit krit1 nikos scribenick shepazu svg trackbot You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Regrets: Rich Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSep/0054.html Found Date: 15 Aug 2013 Guessing minutes URL: http://www.w3.org/2013/08/15-svg-minutes.html People with action items: cameron dirk[End of scribe.perl diagnostic output]