See also: IRC log
<birtles> scribenick: birtles
<scribe> scribe: Brian
ed: I added this because someone wrote a blog about inconsistencies about animation
http://www.broken-links.com/2014/01/29/animating-offset-value-svg/
krit: the problem is the attribute should be animated as SVGAnimatedNumber but percentages are also allowed by the attribute syntax
<heycam> ScribeNick: heycam
<scribe> Scribe: Cameron
birtles: I think we can make it
more clear that when it says "attribute type", that refers to
the datatype of the attribute, not the IDL type
... it doesn't mean SVGAnimatedNumber, it means the datatype,
which is either number or percent I think
krit: in Blink/WebKit, we really take the object, SVGAnimatedWhatever, and animate this type
birtles: I don't think that's right
krit: I think the spec implies that
birtles: CSS
Animations/Transitions is clearer about this
... it says "animate this as length or percentage"
... that's the intent of SVG, but it's not as clear as it could
be
... we should fix this, in Web Animations
... as for the DOM, that's up to Cameron
krit: it's the same with
animations of transforms
... in the past if you had <animate
attributeName="transform"> then you can't say
from="translate(...0)"
birtles: animate attributeName="transform" in general is never possible, since the transform attribute was never animatable with <animate>
krit: it is now
birtles: yes, but SVG doesn't define that
krit: we have the same problem
with filters
... you can give a list of filters, but the type would be
string
... according to the SVG animation model
... you want the CSS interpolation
ChrisL: I think at the time, when
SVG was using SMIL, each datatype needed its own definition for
interpolation
... they were really looking on the syntax level, and if they
didn't match you couldn't interpolate between them
birtles: it leaves you with
interesting things like you can't do <setTransform>
e.g.
... which is frustrating
... shouldn't have made different elements for for different
datatypes
... but I understand the history
ChrisL: also it had a lot less
developer input at that time
... it was mostly input from a few SMIL player people
birtles: so this will get fixed
with Web Animations anyway, so no specific actions needed
here
... I posted a comment on the blog post and it hasn't appeared
yet
shepazu: in general your approach with animation, all the features apart from animateColor are going to be possible with Web Animations?
birtles: yes
... we map what we've already defined in SVG onto the
primitives we're defining in Web Animations
<birtles> scribenick: birtles
shepazu: previously we talked
about various use cases
... for having an outline
... I don't think anyone thinks those use cases don't
exist
... I think we had consensus on the use case for outline for
hover etc.
... we want to be able to allow the outline property on SVG
elements
... so that you can have :hover and the outline will
hover
... one assumes it is the bounding box of the element
krit: SVG does not disallow the outline property and CSS does not restrict it to HTML therefore it applies to SVG
shepazu: but we haven't defined what is means for SVG
heycam: there are lots of properties like that but we need to define which box
shepazu: since we don't have a box model it doesn't just fall out of the model
Rossen_f2f: text-wrapping is a
pain
... how does the box model apply to SVG?
shepazu: it doesn't, but for
things like outline the question is do we want to allow the
padding property?
... in this case it would simply increase the size of the
outline
... but would not affect text-wrapping at all
heycam: it wouldn't be difficult
Rossen_f2f: have you looked at shape-margin, shape-padding
shepazu: I haven't, we might do that instead
heycam: they are for text in non-rectangular shapes
Rossen_f2f: it applies to an
element and an element's shape
... it is meant for mapping the meaning of margin/padding in
CSS to non-rectangular shapes
heycam: what happens when you
apply it to a rectangular shape
... what is the difference between margin/padding
Rossen_f2f: one difference is you
can only specify one value
... since you don't have four sides
... so it is meant to follow stroking rather than boxes
... if you have a 10px margin and it is a shape that has
corners then it will round those corners
shepazu: let's consider that for
the future, but not for now
... use case: we have a shape and you want to add an outline on
mouse over
... this already works since outline applies to all
elements
... can we agree that it uses the bounding box of the
element?
krit: which bounding box?
shepazu: the one we discussed
yesterday (stroke bounding box, decorated bounding box,
whatever we call it)
... the same one for filters, masking etc.
... I just think we align it to some pre-existing definition of
a bounding box
krit: we decided already filters,
masking, and clipping do not affect outline
... so the problem is that the CSSWG defines it as: draw shape,
stroke, fill, then filters, then mask/clip
... then if you clip an element outline will be clipped
away
... on HTML it is based on the current rendering model that
browsers implement
ChrisL: the default clip is going to always clip away the outline
heycam: is that right, if you have overflow:auto?
krit: the default is auto where you don't clip
shepazu: can we resolve we'll
have outline and the outline will resolve to whatever bounding
box we deem is appropriate
... of the ones we discussed yesterday
... one of the characteristics of outline is that it doesn't
affect the box model
REO
RESOLUTION: outline will resolve to our definition of stroke bounding box
shepazu: the second issue is, can
we have the background property apply as well
... this would resolve to exactly the same area, it would just
be the background
... it also apply to elements
... in terms of performance characteristics it is the same as
outline
... it is the same area
... we have already resolved to have a viewport-fill using
background
heycam: on the outer SVG element
it would cover the whole viewport but for inner SVG it would
cover the bounding box area
... since we decided not to do viewport-fill but just to
support background
shepazu: how do we feel about having background apply to SVG elements?
heycam: I think it's fine
krit: I don't see the value in
the extra work
... I think it slows down implementations
... I don't think the use case is strong enough
heycam: I think it's useful for text
Rossen_f2f: what will the background be clipped to?
shepazu: the same as outline
Rossen_f2f: so if I have a path,
what will be filled?
... the area around the path?
<Tavmjong> SVG 2 Text currently refers to a "content area" that is the same as defined in CSS.
shepazu: yes
RRSAgent: what is the use case for that?
Rossen_f2f: what is the use case
for that?
... outlines are not hit-testable
... but background is
... and background is often used for hit-testing
shepazu: that is another use case where you use the background to enlarge the hit-test region
heycam: we already solved this with pointer-events: bounding box
shepazu: we could also say that
background in SVG is not hit-testable
... it's simply visual, not hit-testable
heycam: that would be ok with me
Rossen_f2f: so you mean background images etc?
shepazu: no, not images
Rossen_f2f: why not?
shepazu: the use case is having a visual indicator that something is in focus which applies to both outline and background
Rossen_f2f: in order to get
around this, if all you need is selection, can't you specify
your outline to have fill or stroke?
... that way if you specify this fill, it fills in this
area
... you're specifying an outline and you want to indicate that
something is selected
shepazu: how is that different to background
Rossen_f2f: it doesn't open the
door to everything else that is in background
... which is very complicated
heycam: why shouldn't you be able to use backgrounds like gradients?
krit: when you do that you have to work out sizing
heycam: once we work out the size of the box, that is solved
shepazu: I have heard many times
from developers that they expected to be able to set the
background on SVG elements
... right now if you want to have this effect you compose it
yourself using rect
... if you want to have something highlightable you need
transform a container group
ed: I've heard the same but only for text and elements that establish viewports
shepazu: personally, I've done this many times
Thomas: we've used this many
times
... you mouse over something and a background box
highlights
... we do this manually using javascript
... it would be so much easier if it was directly supported
shepazu: and it would also be more intuitive to people who are used to CSS
birtles: does the shape you highlight correspond to the bounding box of the text
Thomas: we actually generate the box from some data mining software... the box might actually be slightly larger than the text bounding box
krit: is the shape always rectangular?
Thomas: it often is
shepazu: I'm just looking for the simplest possible thing that makes sense to developers
krit: I'd like to see the concrete use case
Rossen_f2f: I understand the use case but I'm not sure if this is the right approach
<Tavmjong> We are moving to CSS based text layout. Hasn't CSS already figured this out?
krit: do you use something other than a color for highlighting?
Thomas: generally it's a solid color but I could see people using gradients
heycam: if we are going to restrict it to color, then we should be able to expand it to other paints later
ChrisL: this is how we ended up with viewport-fill, so we could expand it later
shepazu: I don't think the use
case supports having images
... since it's about highlighting things
... but perhaps they could have a subtle stippled image
krit: if it is background-color, this doesn't allow lists of colors
shepazu: I think we should support background but only support colors
heycam: I think we should
specifically just support background-color and then later we
can support background if necessary
... then people don't use background to mean only
background-color
Rossen_f2f: if we support background only, the shorthand, then we have to support everything in background
shepazu: I would be happy with background-color
heycam: my argument against outline-fill is that it's hard to extend later
shepazu: I also don't think we
should add a property
... the other thing to talk about is hit-testing
heycam: whether the background is
hit-testable or not?
... with pointer-events: auto?
shepazu: we could say that background is not hit-testable in SVG
Rossen_f2f: in the previous use
case where the outline is used to indicated that the shape has
been hit-testable
... the background you use to indicate that it has been
hit-tested also changes what gets hit-tested
ed: I wanted to mention the
difference between the outline and the background box
... I expect the outline to be axis-aligned but not the
background
... for example, if you transform some text
heycam: you can achieve that effect
<heycam> <g transform="..."><text>...</text></g>
<heycam> g:hover { outline: ... }
<heycam> g:hover text { background-color: ... }
shepazu: another use case is when something is selected by keyboard etc.
krit: my question is what happens
if you apply a clip path
... in the HTML world the background would be clipped
... do you want the background to be clipped here as well?
shepazu: it should match CSS
krit: so it would be clipped
heycam: in that case you'd need a containing group to stop the background from being clipped
shepazu: is background-color hit-testable in CSS?
Rossen_f2f: yes
heycam: the box is hit-testable
Rossen_f2f: if the background is transparent it didn't used to be hit-testable
heycam: is that right? now that
we have pointer-events?
... in CSS if the background is transparent, the box is still
hit-testable these days
shepazu: (draws some shapes with
boxes around them)
... suppose the backgrounds have alpha
... where does it stack
everyone: with the element
shepazu: how does it blend? is it a problem?
(generally seems to be ok)
krit: we still didn't clarify
hit-testing
... or padding
shepazu: I think hit-testing is
characteristic of the box and not the background
... we should decide that later
krit: for the highlighting use case you don't want backgrounds to be hit-testable
shepazu: we can solve that later
krit: do we want padding??
heycam: I think we do, particularly for Thomas' use cases
shepazu: you could solve that
with a background and thick outline of the same color
... so we don't *have* to have padding
heycam: I think that's problematic if rendering is not pixel-aligned since you'll get seams
shepazu: so do we want shape-padding or regular padding
heycam: I think it's better to have padding if we're talking about a box
shepazu: I think it makes most sense to allow padding
krit: padding would also affect outline
shepazu: yes
krit: what about border?
heycam: we can live without that
shepazu: what about outline-radius?
Rossen_f2f: there's no outline-radius
heycam: interestingly, it's border radius that controls the rounding of the background
shepazu: let's boil this lobster
krit: how does padding work for outer SVG?
shepazu: we special case that
RESOLUTION: add outline, background-color, and padding to SVG2 with hit-testing to be determined later
<heycam> -- 15 minute break --
<cabanier> scribenick: cabanier
Smailus: here's a pdf
... there's a paper in there that contains features that we
think is important
heycam: cgm vs SVG?
Smailus: yes
... the text has to fill the space between the wires
... ... the author generates a diagram and it's important that
it looks the same everywhere
... ... so stylesheets should not affect
shepazu: how important is that?
Smailus: it's not that is
important
... if the diagram looks different, that is very bad
... there can be font differences
... we have ataa and faa requirements
... ... we have outstanding issues with non-scaling patterns
and dashse
... ... if you zoom out, it would be very busy
... ... when you see the diagram as a whole, the user has to
zoom in
... ... the author makes it with certain patterns, you want the
line thickness to stay the same
... ... right not the lines get thicker which is a
problem
... the paper talks about the issues
... line types and line styles are problems
... it would be easier if there was a table of line styles
shepazu: you could do that with a
class
... what's a line style?
Smailus: dash patterns, diamond
shepazu: are these predefined or conventions?
Smailus: I think they are conventions
shepazu: it would be useful to know that
<shepazu> http://www.cgmopen.org/technical/cgm-svg-20030508-2.htm
Smailus: the paper talks about this
Rossen_f2f: wrt non-scaling pattern. do you have requirements for corners?
Smailus: CGM has this and some people use that
Rossen_f2f: so it has meaning in the diagram?
Smailus: yes, whitespace at the corner could be confusing
<stakagi> https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Skeleton_frames
<stakagi> http://lists.w3.org/Archives/Public/www-svg/2013Jan/0009.html
ChrisL: is there an iso standard for the dashing or is it for pay?
Smailus: I will look that
up
... size matters too for us
... it's important to keep it as small as possible
... but not as important as it was in the past
shepazu: one of the things they
do, is that they generate the bounding box at document creation
time
... so having this will reduce the filesize dramatically
Smailus: yes, at authoring time,
we put a transparent rectangle at the front
... similarly for wires
shepazu: so this could change the authoring tools?
Smailus: yes
... preserving authoring intent is key
<ChrisL> catia-authored cgm
shepazu: could SVG replace CGM?
<heycam> https://en.wikipedia.org/wiki/CATIA
smailus: maybe eventually
Rossen_f2f: corner preservation is important?
smailus: people have told me that it sometimes matters. unsure how big of a deal it is?
krit: do you want the dash array to be always the same when you zoom in/out?
smailus: I don't think that really matters
krit: is zooming perserving aspect ratio
smailus: yes
... non-scaling lines would stay the same
ChrisL: the paper that is
referenced here, is the second revision.
... one of the particular things he picks, is bitonal
images
... SVG only has png and jpeg
... his article uses an illustrator svg file that encodes a pdf
file in the metadata
<ChrisL> base64 data uri 16,613 iv-base64.txt
<ChrisL> data uri compressed 12,623 iv-base64.txt.gz
<ChrisL> original png 15,228 Saito_bwStucki.png
<ChrisL> optimised png 12,438 Saito_bwStucki-iv.png
<ChrisL> svg with data uri 16,759 svg-iv-base64.svg
<ChrisL> svg compressed 12,746 svg-iv-base64.svgz
ChrisL: I redid the file so it just contains the svg data
shepazu: what should we be looking for?
ChrisL: the optimized png is 12.6 k and the svg is 12k
Smailus: in our diagrams we have
switches that have a hot spot
... you can click on parts or the whole
heycam: hierarchical regions?
smailus: yes
shepazu: in that case, you'd still use a rect as a hotspot
smailus: in that case, we would probably use that all the time
<ChrisL> the cad generation and the hotspot addition are done at separate stages in the workflow, typically
smailus: the artwork is spread
over the artwork and the hotspot
... often the artwork is sorted for plotting (arcs that are
together)
shepazu: you could do rectangles in certain area but for text you could relay on the SVG
heycam: have you looked at hatch fills that Tav proposed?
smailus: no
heycam: not sure if they're non-scaling
<ChrisL> http://www.w3.org/TR/SVG2/pservers.html#Hatches
Tavmjong: I assume that we'd eventually do that
krit: what about if the aspect ration changes?
heycam: not sure yet. Maybe we don't have to care about that
<ChrisL> also, svg2 has non-scaling stroke http://www.w3.org/TR/SVG2/painting.html#NonScalingStroke
krit: what if you use
percentages?
... if you do, the viewport is not square and is difficult to
implement
... but this is only an issue for relative lengths
<scribe> ACTION: smailus to break his presentation out into specific issues that need to be addressed and take it to the mailing list [recorded in http://www.w3.org/2014/01/31-svg-minutes.html#action01]
<trackbot> Created ACTION-3572 - Break his presentation out into specific issues that need to be addressed and take it to the mailing list [on Thomas Smailus - due 2014-02-07].
<scribe> ACTION: ChrisL to work with Smailus to create examples of the issues [recorded in http://www.w3.org/2014/01/31-svg-minutes.html#action02]
<trackbot> Created ACTION-3573 - Work with smailus to create examples of the issues [on Chris Lilley - due 2014-02-07].
ed: responsize images and
svg
... auto width and height gives you the size you need
... it's issue 3 on the wiki page
<ed> https://www.w3.org/Graphics/SVG/WG/wiki/Intrinsic_Sizing
<krit> <svg width="200px" height="200px" style="width: 300px; height: 300px;" viewBox="0 0 250 250">
krit: there are different
opinions. maybe we want to do it like canvas
... widht and height properties and attributes control
resolution and size
heycam: do you know if this is only for inline out svg?
<ed> <svg width="50%" viewBox="0 0 100 100">
<ed> <rect width="100" height="100" fill="blue"/>
<ed> </svg>
krit: webkit does presentational attribute mapping (sort of)
heycam: we define that the intrinsic aspect ration comes from the viewbox?
ed: I believe so
<ed> http://jsfiddle.net/M445V/
krit: (drawing diagram)
heycam: it seems webkit's interpretation makes more sense
<ed> <div style="width: 100px; height: 100px">
<ed> <svg style="background:blue"></svg>
<ed> </div>
<ed> http://jsfiddle.net/3dy9U/
ed: I pasted a fiddle in
krit: IE and firefox seem to
agree
... http://jsfiddle.net/M445V/1/
... firefox doesn't scale height
<birtles> there's a long discussion about this: https://bugzilla.mozilla.org/show_bug.cgi?id=668163
<ed> another long discussion here: https://code.google.com/p/chromium/issues/detail?id=308992
heycam: we had a bug with bing maps
krit: with/height: 100% seems to
make a different for firefox
... we can say that if you leave them off, it should go to
100%
heycam: what we want to say, if
the presentation is there it maps to the style property.
... but if it's not, it's treated as auto
krit: I suggest that auto is
300/150
... I think we need more tests
ed: we have a lot of tests
krit: IE used to have strange
behavior in the case there was viewbox
... I suggest we follow IE (and webkit)
... what happens if there's a div with no sizing
Rossen_f2f: in CSS, auto goes to
150
... if the containing block has a resolvable height, we use
that
<birtles> the reason we wanted not to map default values for width/height to style is: "The fact that our old behavior did apply to such default values was one of the most confusing things about using SVG in HTML -- for example, SVG elements that *do* have a viewBox used to have that viewBox's intrinsic ratio ignored when they were inside a container with a fixed
<birtles> height (such that percentage heights were meaningful), but the intrinsic ratio was honored if they were in an auto-height container."
<birtles> it seems like webkit/blink don't face this issue because % heights are resolved against the document viewport (unlike a div with % height) according to David Vest: http://lists.w3.org/Archives/Public/www-svg/2013Dec/0095.html
heycam: http://jsfiddle.net/M445V/4/
krit: webkit is not looking at
the containing block
... it seems IE is the most reasonable
Rossen_f2f: 10.3.2
<ed> (the numbers refer to CSS 2.1 sections, right?)
Rossen_f2f: if the width is not
specified, it should go to auto. What is auto on an SVG element
with display: block
... if we follow SVG as a replaced element, 10.3.4 it should go
to intrinsic
... but we are computing as non-replaced
... BUT if you require a shrink-to-fit such as a float, then we
use 300 by 150
... is SVG replaced element?
heycam: is image replaced?
no
krit: x/y/width/height should be presentation attributes
heycam: sure
resolution: width and height attributes are presentation on the svg element
heycam: I would like to see what the issue was
<scribe> ACTION: heycam to investigate why firefox needs to treat SVG as a replaced element [recorded in http://www.w3.org/2014/01/31-svg-minutes.html#action03]
<trackbot> Created ACTION-3574 - Investigate why firefox needs to treat svg as a replaced element [on Cameron McCormack - due 2014-02-07].
<scribe> ACTION: ed to create inline SVG sizing tests [recorded in http://www.w3.org/2014/01/31-svg-minutes.html#action04]
<trackbot> Created ACTION-3575 - Create inline svg sizing tests [on Erik Dahlström - due 2014-02-07].
<scribe> ACTION: krit to make width and height attributes presentation attributes on the svg element [recorded in http://www.w3.org/2014/01/31-svg-minutes.html#action05]
<trackbot> Created ACTION-3576 - Make width and height attributes presentation attributes on the svg element [on Dirk Schulze - due 2014-02-07].
heycam: shepazu do you have ideas?
<Tavmjong> http://tavmjong.free.fr/SVG/SYMBOL/symbol.html
Tavmjong: I would be against
this
... it was mentioned that browsers were not ignoring this. but
that seems not to be the case
... I didn't check chrome or ie
... but all others did
... it is used quite a bit, especially Illustrator
... Andreas is also against removal
... inkscape uses it to populate a dialog
shepazu: I think you
misunderstood
... I was saying that Symbol should be defined as a special
case of the SVG root
Tavmjong: I thought you wanted to deprecate the symbol element
shepazu: I take deprecation
back.
... they are not defined as being non-displayed SVG roots
Tavmjong: according to ???, what
is missing is alignment
... markers have that possibility. Symbols don't
shepazu: we should define marker
and symbol the same way
... a marker should behave like a nested svg root
... so there's only 1 model that developers and browsers have
to understand
heycam: we already allude that they are similar
krit: I have nothing against it but don't see the improvement
Tavmjong: markers also have an orientation
shepazu: I would like to see in the spec, "these are the differences between markers and symbols"
Tavmjong: they are in different sections
shepazu: let's go over that in the coming week
resolution: we will not deprecate
symbol and make it clear in the spec what their differences and
similarities are.
... we will not deprecate symbol and make it clear in the spec
what their differences and similarities are.
... feature freeze for SVG in june and last call in January
2015
<heycam> -- lunch time --
<heycam> Scribe: Cameron
<heycam> ScribeNick: heycam
krit: I just want to make sure the default behaviour is always reasonable
shepazu: what's reasonable?
krit:
background-color:transparent should not influence hit
testing
... but if it has a color, it would be strange by default if it
doesn't affect hit testing
ChrisL: if you're not doing hit testing you can't do :hover
shepazu: you can, you just have to change pointer-events explicitly
birtles: Rossen had a point, that
if you have a background that is transparent, and therefore not
getting hit testing, and you mouse over and fill it in, it's
unusual for it then become hit testable
... so I think it makes more sense to never hit test, but you
can still use pointer-events:bounding-box
krit: ok
RESOLUTION: background-color on SVG elements will never influence hit testing area
krit: I suggest we look at CSS UI to see if there are other keywords to use for pointer-events
<krit> http://www.w3.org/wiki/User:Tantekelik/pointer-events
krit: the only difference there is the new 'auto' value
heycam: so you're proposing a new 'background' keyword for pointer-events?
krit: yeah we could have
that
... it would mean the background area
heycam: is that different from bounding-box?
krit: yes because it does not include padding
heycam: so getBBox() would return the plain geometry bounding box, and we could use the other version of getBBox() that takes a dictionary to select which parts to include
krit: yes
... we need to decide effectively what the content box
shepazu: I think it should be the
stroked bbox
... actually the decorated bounding box
heycam: so including markers
RESOLUTION: The effective content box of an SVG element is the decorated bounding box.
<scribe> ACTION: Doug to make background-color, padding-*, outline-* apply to SVG elements. [recorded in http://www.w3.org/2014/01/31-svg-minutes.html#action06]
<trackbot> Created ACTION-3577 - Make background-color, padding-*, outline-* apply to svg elements. [on Doug Schepers - due 2014-02-07].
<stakagi> http://svg2.mbsrv.net/devinfo/devstd/non-scaling-objects-2/
stakagi: this is an issue that
came up in 2011
... I tried to standardise non-scaling features for SVG 2
... I've found that SVG Tiny 1.2 has such a feature,
ref(svg)
... based on this specification, SVG 2 should have such
functionality
... but I found issues, listed in that document
... one is that is somewhat difficult and has a special
description
... other is that it doesn't consider nested documents
ChrisL: I don't think the restriction to non-nested documents is inherent in the feature, but SVG Tiny 1.2 doesn't support nested documents
stakagi: the issue with nested
documents is described in the last section "Fixed object for
nested documents" on that page
... this section shows that non-scaling characteristics will be
transmuted when nested document embedding is performed
shepazu: does this account for all transforms, including those that are in CSS?
stakagi: yes
shepazu: what about 3D transforms?
ChrisL: no, you'd need to change the formulae here to take into account 3D
shepazu: does it need to?
ChrisL: I don't see 3D being used here, it's more for local 3D inclusions in a 2D world
shepazu: what does this do for
zoom?
... is that defined as a transform?
ChrisL: you do all your transforms up to the root, then an additional one for the zoom, that's where it comes in
shepazu: I think it should take into account zooming, though not necessarily panning
birtles: that page does talk
about using the CTM for zooming
... the very last point it mentions browser chrome
transformations, which further touches on zoom
shepazu: is this the syntax we
want?
... instead of doing vector-effects="...", a CSS property that
says non-scaling with parameters to that?
heycam: either is better than ref(svg)
ed: yes ref(svg) made it hard to integrate with CSS Transforms
shepazu: I would expect this to be a CSS property
birtles: vector-effect is a CSS property
ChrisL: people like
non-scaling-stroke keyword
... I'm not seeing traction for vector effects more broadly
shepazu: if we promoted more it would, but that's another matter
heycam: I don't think I'd like vector-effect being used for non-scaling stroke and then a separate property for non-scaling other things
shepazu: maybe "non-scaling" as the property name
<birtles> scaling="fixed-stroke fixed-coordinate"
stakagi: [translated from brian]
normally with the transform:ref you only have one CTM, but in
the case of nested documents, where you can nest to any depth,
you can have a whole series of CTMs which stack up
... for that case, you'd need a different property value
heycam: so "stop at the current document" or "go all the way"?
stakagi: yes
ChrisL: the "ref" bit means to walk up to where I'm referencing, so skip up to the specified element
birtles: there's no way of
indicating of the reference with this syntax
... four property values in this proposal
ChrisL: one you can give
numerical values
... one you can point to an ID
... one you can count <svg>s from the root, if you know
you're nested 5 times
... (you could say to skip 2 of them)
... (and the default would be 1)
shepazu: I'm uneasy about the
syntax for saying how many levels to go up
... maybe I'm misunderstanding; which transformation contexts
it's skipping is at the nested <svg> barrier
... I think one nesting barrier or all is probably as much as
you need
... by default it might be only the current nesting context,
and the other value would be all nesting contexts
... maybe in the case of widgets...
ChrisL: my concern is
composability
... if you take an existing application that uses
non-transform-up-to-the-root, and you embed that somehwere, now
your widget could break
shepazu: I don't disagree, I
don't see in practice people doing that
... I suggest we keep it simple, so one context or all
ChrisL: I think the composability is important
shepazu: so one place I use that
kind of composability is presentation slides
... I'll use levels of nested SVGs there
... I'm trying to think of a case where I'd want non-scaling
whatever that is only within a certain context; I'm not
thinking of one
heycam: [describes an example]
shepazu: it seems brittle to describe it in terms of levels
heycam: I agree
ChrisL: IDs would be easier
heycam: I think I'd rather solve the number-of-levels issue later if we need to, but keep it simple to start
<ChrisL> so it should aleways refer to the rootmost svg element
birtles: to clarify the four
different keywords from the proposal document
... the additional-fixed-coordinates corresponds to
ref(svg,100,100) ; that's for example for an icon on the map,
which can change its location, its translation, but not its
scale
... whereas fixed-coordinates means that it stays at the same
position; for example for a UI for the map
... then what is it relative to? the coordinate space of the
root of the document, but then the final two keywords,
additional-fixed-coordinates-root and fixed-coordinates-root,
are the coordinate system of the "browser" so to speak
ChrisL: I understand the four things now, but maybe the names could be improved
birtles: you want the property values to be like "fixed-scale", "fixed-position", ...
ChrisL: since you have two types of things, one that can move its position and one not, the "no-pan" thing included the no scaling
shepazu: you could have separate keywords
<ChrisL> nopan-root nopan-viewport noscale-root noscale-viewport
thomas: does that take into
account rotation too?
... your map legend might not want to rotate when you rotate
your map contents
shepazu: my current thinking is
to say a single property, whatever it's named -- maybe
transform-limit -- and a bunch of parameters to say which
things you're limit
... the auto value is no transform limit
... among them would be no-rotate, no-scale-stroke, no-scale,
no-pan
... and then there are the scoping things
ChrisL: those, followed by either a keyword that means viewport or root element, with an initial value that would mean
stakagi: I'm not fussed about
syntax
... regarding no-rotate, previous SVG's transform(ref) couldn't
do that, so I didn't consider it
... but might be convenient, provided the math isn't
convenient
thorton: with a compass rose, you want that to rotate, but the map legend not to rotate
stakagi: I'm looking for permission to write up the stuff from SVG Tiny 1.2 in a better syntax for SVG 2, mostly concerned about bringing across the current functionality
birtles: I think if there are
parts that are difficult to specify, like math for no-rotate,
he might like to defer that
... but at least he wants to cover the two cases for
transform(ref)
stakagi: if someone wants to think about it I'm happy for you to do so
shepazu: to get started, let's accept accept Takagi-san's proposal, he puts it into the spec, and we go from there
RESOLUTION: We will accept the new transform(ref) proposal but with different syntax for SVG 2.
<scribe> ACTION: stakagi to add the new transform(ref) functionality to SVG 2 [recorded in http://www.w3.org/2014/01/31-svg-minutes.html#action07]
<trackbot> Created ACTION-3578 - Add the new transform(ref) functionality to svg 2 [on Satoru Takagi - due 2014-02-07].
birtles: we mentioned non-scaling
hatching
... we'd address that with the same property?
ChrisL: I think we need to look at that
shepazu: the flip invariant text could be handled here too
heycam: yeah, a new value to snap non-rotation to 90 degrees?
<ed> don't see why we should necessarily restrict it to n*90 degrees, let it be author controlled
ISSUE: Consider allowing non-rotation, non-scaling/rotation of fill hatch/pattern options to the new non-transform functionality
<trackbot> Created ISSUE-2453 - Consider allowing non-rotation, non-scaling/rotation of fill hatch/pattern options to the new non-transform functionality. Please complete additional details at <http://www.w3.org/Graphics/SVG/WG/track/issues/2453/edit>.
ISSUE-2453: Also non-scaling rotation of stroke (in case it includes a hatch pattern too).
<trackbot> Notes added to ISSUE-2453 Consider allowing non-rotation, non-scaling/rotation of fill hatch/pattern options to the new non-transform functionality.
krit: the shadow tree has things
where you can isolate style inheritance
... and you can explicitly inherit style into the tree
... is that something we care about for the <use>
element?
ed: I guess
... if it's something you can control
... one part that was requested was to add <shadow> to
SVG
<ed> http://lists.w3.org/Archives/Public/www-svg/2014Jan/0018.html
<ed> http://www.w3.org/TR/shadow-dom/#shadow-element
heycam: this is pdr's review of
web components for SVG
... seems like it makes sense to allow <shadow> in SVG as
he suggests
krit: what about removing the instance tree?
ed: everyone on the mailing list
agreed but we haven't resolved yet
... so that would be removing SVGElementInstance etc.
krit: groups within Adobe would like to extend the instance tree rather than removing it
heycam: I think knowing the
correspondence between template and shadow tree elements isn't
critical
... you can work it out yourself if you need
krit: I think most people agreed about the removal of the SVG instance tree
RESOLUTION: SVG 2 will remove the SVG instance tree for <use>.
krit: next is basing <use>
on the Shadow DOM
... which is now in CR, or at least LC
cabanier: so if it's a shadow tree you have a copy per instance
ChrisL: yes
shepazu: if I have a <use> element, and I change the thing it refers to, does it no longer update?
cabanier: yes
heycam: but I think maybe we want to keep the auto-updating behaviour
krit: that is how Blink
implements <use> in terms of shadow trees
... updates to the original cause the tree to get recreated
heycam: that's how it works internally in Firefox now anyway
[discussion of allowing inherited styles into shadow trees]
RESOLUTION: SVG 2 will base <use> on shadow tree spec.
heycam: pdr's first point in his mail, is that about the HTML parser?
ed: there are two things defined
in Shadow DOM
... <shadow> and <content>
... they're both inheriting from HTMLElement
krit: should they inherit from Element so we can use it?
heycam: not sure about
that.
... don't want to lose all the HTMLElement things in HTML
<ed> http://w3c.github.io/webcomponents/spec/shadow/
<ed> http://w3c.github.io/webcomponents/spec/shadow/#content-element
<ed> http://w3c.github.io/webcomponents/spec/shadow/#shadow-element
<scribe> ACTION: Erik to ask somebody what to do about content/shadow inheriting from HTMLElement [recorded in http://www.w3.org/2014/01/31-svg-minutes.html#action08]
<trackbot> Created ACTION-3579 - Ask somebody what to do about content/shadow inheriting from htmlelement [on Erik Dahlström - due 2014-02-07].
ACTION-3413 is cyril's action to make <use> use Shadow DOM
ACTION-3413?
<trackbot> ACTION-3413 -- Cyril Concolato to Investigate describing use in terms of the shadow DOM -- due 2013-02-10 -- OPEN
<trackbot> http://www.w3.org/Graphics/SVG/WG/track/actions/3413
<scribe> ACTION: Erik to remove <use> element instance tree. [recorded in http://www.w3.org/2014/01/31-svg-minutes.html#action09]
<trackbot> Created ACTION-3580 - Remove <use> element instance tree. [on Erik Dahlström - due 2014-02-07].
-- break --
stakagi: our use case is lazy loading according to clipped bounding boxes
<stakagi> https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/ResourcePriorities_for_SVG#ClippedBBox
stakagi: this URL describes
it
... at first, we should have an API getClippedBBox()
heycam: I think we should have an
API with a single bbox function (maybe in addition to
getBBox(), or maybe exactly getBBox()) that takes options
indicating which parts to include
... so stroke, fill, etc.
... and this function you could also indicate whether the
clip-path is taken into account
... element.getBBox({ fill: true, stroke: true, clipped: true,
markers: false })
... and they'd have some default values
ed: getStrokeBBox() is already implemented in Blink
krit: but probably behind a
flag
... it is in the spec now, and I think the spec says to include
markers, even though the name is Stroke
ed: it's not behind a flag
heycam: I doubt anyone is using it yet
krit: I want to use getBBox() on HTML content too
ChrisL: what would it give you?
krit: the boundaries of the element without its transform
ChrisL: and which boundary would
that be?
... content bounding box?
krit: border boxes
RESOLUTION: SVG 2 will extend getBBox with a dictionary parameter, including whether clip-path is included, and getStrokeBBox will go away.
<scribe> ACTION: Cameron to add the extended getBBox to SVG 2. [recorded in http://www.w3.org/2014/01/31-svg-minutes.html#action10]
<trackbot> Created ACTION-3581 - Add the extended getbbox to svg 2. [on Cameron McCormack - due 2014-02-07].
krit: clip-path should be applied last
heycam: we maybe should talk to CSSOM people, if we want it to apply to both HTML and SVG, and have CSS box keywords
shepazu: for accessibility you
need to make it possible/easy to add title/desc to each
element, and to the document root
... second thing is, in general, consider the case for adding
content for animation and apps, not just static output
... third thing was, be careful how much you use features like
filters, clip-paths (especially), because it hurts
performance
... the other thing is, an SVG file should be scalable by
default, so have the viewBox be specified and width/height
100%
krit: I think we just added that
last one
... there is an option, responsive image, which should allow
that
ChrisL: the blog post said it didn't give you a fixed width/height, but it didn't say how it did it
shepazu: and get rid of the xml
prelude
... the comment about creator:adobe should put it in the
document root
heycam: are internal entities in DTDs gone?
krit: I think so
shepazu: add the ability to add a
metadata license
... for the web case, it otherwise is ambiguous. allow having a
CC-BY license mentioned in there.
shepazu: for the validator, we
don't have an rng schema
... SVG 2 should have one
... I asked around different people, and everyone wanted to
charge to do it
... or charge to train us to do it
ChrisL: who's asking for this?
shepazu: hsivonen, MikeSmith, for the validator
ChrisL: it's not just making a
subset for a subset of rng that is valid, but mixing it up with
html5 schema, arbitrary combinations of these
... a composable schema
... sounds like a lot of work
shepazu: if we want SVG to
validate I think we need to do this
... or at least confirm that this needs to happen
<scribe> ACTION: Doug to ask Mike whether we need an RNG schema for SVG to validate in the validator [recorded in http://www.w3.org/2014/01/31-svg-minutes.html#action11]
<trackbot> Created ACTION-3582 - Ask mike whether we need an rng schema for svg to validate in the validator [on Doug Schepers - due 2014-02-08].
krit: anyone object?
ChrisL: publishing just what's in there right now? or waiting for people to do edits first?
krit: I want to do my stroke edits
ChrisL: do we have a complete list of changes since the last WD?
krit: I think everyone did add to changes.html
shepazu: how about Tuesday Feb 11
ChrisL: ok
krit: ok
RESOLUTION: We will publish a WD of SVG 2 on Tuesday Feb 11.
<scribe> ACTION: Cameron to prepare SVG 2 for publication on Tuesday Feb 11. [recorded in http://www.w3.org/2014/01/31-svg-minutes.html#action12]
<trackbot> Created ACTION-3583 - Prepare svg 2 for publication on tuesday feb 11. [on Cameron McCormack - due 2014-02-08].
shepazu: we have a chapter that
describes how we select text
... we should also say how we select other items, like
graphical items
... and there's some implications to selection because
selection is a prelude to copy and paste
... when you copy and paste what are you copying and
pasting
... just the text, or maybe a png of the section you
selected
... if you're copying the tree, do you copy all the things that
the tree references, do you copy the original thing or do you
expand it?
... do you copy css styles with the fragment you selected?
ChrisL: I can argue for or against for each of those
shepazu: HTML says when something
is selected, it doesn't have a good copy and paste spec
... Clipboard API
ChrisL: that's an API though so needs to be triggered by some gesture
shepazu: I'll talk to the editor of Clipboar API about these questions
<ChrisL> Clipboard API and events
<ChrisL> W3C Working Draft 11 April 2013
<ChrisL> Hallvord R. M. Steen, Opera Software
<ChrisL> http://www.w3.org/TR/clipboard-apis/
shepazu: we've wanted to have a way of exporting a PNG of the SVG, has anything happened on that?
ChrisL: [mumbles about people bringing up security]
[talk about some use cases for getting a rendering of an SVG fragment]
shepazu: I will find out more
about what HTML does
... another consideration is if you select two elements, and if
they are visually close together but in different DOM tree
positions, how much of the tree do you export?
... we should have something on the SVG root, or somewhere, a
method that says give me the selection
... we'll deal with this in whichever spec defines ranges and
selections
<shepazu> http://www.w3.org/TR/SVG2/text.html#TextSelection
[discussion about selection]
shepazu: I will talk with DOM people about setting the Selection object when clicking SVG elements
RESOLUTION: SVG WG will request selection of non-text elements in DOM Range/Selection/whereever is appropriate.
heycam: I wonder ::selection relates to this
ChrisL: once you've defined that selection works on this, it should just fall out
-- meeting adjourned --
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/attributeType/"attribute type"/ Succeeded: s/animateTransform in general/animate attributeName="transform" in general/ Succeeded: s/with mee/with me/ Succeeded: s/only for text/only for text and elements that establish viewports/ Succeeded: s/is not hit-testable/didn't used to be hit-testable/ Succeeded: s/320/300/ Succeeded: s/not to/then/ Succeeded: s/would return the padding box/would return the plain geometry bounding box/ Succeeded: s/that's all the feedback I have right now/if we want SVG to validate I think we need to do this/ Succeeded: s/: o/: ok/ Succeeded: s/though/though so needs to be triggered by some gesture/ Found ScribeNick: birtles Found Scribe: Brian Found ScribeNick: heycam Found Scribe: Cameron Found ScribeNick: birtles Found ScribeNick: cabanier Found Scribe: Cameron Found ScribeNick: heycam Scribes: Brian, Cameron ScribeNicks: birtles, heycam, cabanier Default Present: +1.206.675.aaaa, Tav Present: Thomas Chris Cameron Brian Doug Rossen Dirk Rik Satoru Sylvain Erik Tav Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2014/Agenda Got date from IRC log name: 31 Jan 2014 Guessing minutes URL: http://www.w3.org/2014/01/31-svg-minutes.html People with action items: cameron chrisl doug ed erik heycam krit smailus stakagi[End of scribe.perl diagnostic output]