Meeting minutes
Clarify that getPathData() returns the attribute base value, not the CSS resolved/animated value
Vinay: That is about hte pathData implementation which is in FF and is about to get implemented in Chrome
viralipurbey:
viralipurbey: It is not clear which data should get returned during animation. baseVal or value of the path?
viralipurbey: SMIL and CSS Animations (any animations)
viralipurbey: Recommendation: getPathData() returns the base value of the d attribute for any animation.
viralipurbey: Firefox does this already
krit: Is there any other way to get the animation value in any other way? As part of WebAnimation for instance?
viralipurbey: yes, it is changing during animation.
krit: I mean any animation value
nzimmermann: animation like with WebAnimation APIs?
krit: yes
viralipurbey: There are only 3 end points and pathData just returns the base value.
viralipurbey: So there is no JS endpoint to get the animate value
nzimmermann: In WebAnimations, the getComputedStyle is reflecting the current state of the animation. So computed stlye should always reflect the current animation state.
<karlcow> https://
nzimmermann: I need to verify it still though.
<karlcow> Hmm not the right url
viralipurbey: You are right, getComputedStyle returns the animated value.
<karlcow> https://
krit: as long as there is some way to get the animated value I am fine
nzimmermann: this is also consistent with pathLength and other values.
RESOLUTION: getPathData() will return base value for any kind of animation
getPathSegmentAtLength(): Define which segment is returned at exact boundary
viralipurbey: this is another one but pathSegmentAtLength
viralipurbey: what happens if the length is on the boundary between 2 path segments.
nzimmermann: how would that be defined in the spec?
nzimmermann: how would we do it mathematically
krit: I'd say that we use SHOULD to avoid this discussion. It would be up to the implementation how to round the values and choose which segement to return
nzimmermann: fine with using the latter segment
RESOLUTION: Implementations SHOULD return the latter segment on boundaries of 2 segments. It is up to the implementation to define rounding rules/epsilon
ACTION: viralipurbey to update the spec
getPathSegmentAtLength(): Define behavior for NaN distance
viralipurbey: When we specify a distance it should be clammed between 0 and distance of path.
viralipurbey: What happens with NaN or Infinity in the distance?
viralipurbey: these are valid values, we just need to define the behavior
krit: FF returns NULL for NaN and Infinity the last sgement and -Infinity the first segment, what do other implementations?
nzimmermann: sounds mindful to me
nzimmermann: I'd like to avoid exceptions.
krit: wasn't getPathSegmentAtLength in Chrome?
viralipurbey: We deprecated the API and are now implementing the new API.
nzimmermann: you were thinking of getPathSegAtLength krit
nzimmermann: but it shows the point of viralipurbey : we were not throwing an exception for the old API
RESOLUTION: Follow behavior of Firefox: return NULL for NaN, Infinity the last sgment and -Infinity the first segment
Clarify glyph-orientation-vertical - whether it is obsolete or something need to be kept?
karlcow: I was working on it and was writing tests when Robert mentioned it is not in Chrome nor Firefox. Should we keep it or drop it?
karlcow: One section says it has been marked obsolet and the next section that it has been replaced.
karlcow: The spec text seems to be confusing though.
nzimmermann: I would support it. We only implemented because one test in the test suite.
nzimmermann: The text also explicitly did exclude horizontal.
nzimmermann: However, for vertical text layouts in a stand alone context it could be useful.
nzimmermann: you do not want to deal with individual glyphs. But if you want to do layout as usual but rotate the individual glyphs. It could be implemented in InkScape.
Vinay: It seems not to be supported by most browser engines and Webkit agrees to remove it, so shall we remove it?
ACTION: Karl to contact Tav on the implementation status
<Image> auto-rotation due to 'Orientation' attribute in EXIF Data
nzimmermann: It is about an attribute that can be embedded in the EXIF DATA
nzimmermann: there is no attribute in SVG to control if the data point would be used in SVG or not.
nzimmermann: there is a request to implement it. Check the last comment in the ticket.
nzimmermann: 3 options: To repeat, I see at least 3 options:
(a) Always apply image orientation EXIF data in
(b) Use the CSS image-orientation property from the element with the filter property for that instance of the filter.
(c) Define an attribute on to control the orientation (analogous to the CSS property).
nzimmermann: I would need to get more context on some options
nzimmermann: We have the image element which is a defined filter resource.
nzimmermann: If you apply the filter some where, we need a way to choose to honor the data on the source where the filter gets applied
krit: lost here: what is the relation to filter?
nzimmermann: we need to think about more than image like the feImage element
viralipurbey: is it clear for image element or do we still need to figure it out
nzimmermann: we need to figure it out in all situations. This is a request from CSS WG: Do we want to expose it via attribute?
nzimmermann: I missed that this is beyond image initially so I need to think about the other use case more.
nzimmermann: so do we always want to auto-orientate which is a privacy concern by chrome? Or do we want to expose it explictly?
karlcow: there is a similar discussion on HTML image
karlcow: the issue is closed but I don't know the conclusion right now
<karlcow> whatwg/
<nzimmermann> https://
krit: if it is a privacy concern, what does it matter if it is auto or explicitly?
nzimmermann: I am confused by this myself.
<karlcow> https://
nzimmermann: we would need more clarification: What are the privacy concerns? What does it matter if auto or explict?
viralipurbey: it is about cross origin leakage
viralipurbey: EXIF metadata could be leaked
krit: What does HTML do? Aren't the concerns valid there too then?
nzimmermann: I agree: Do not invent our own thing but do what HTML does and unerstand why feImage is special.
nzimmermann: that part might be related to the privacy concern.
ACTION: On Niko to get more information from Stephen about it.
TPAC
caribou: We need to create a github issue to request a room
karlcow: we should use the momentum and meet
<caribou> https://
<caribou> w3c/
<caribou> w3c/
recharter
caribou: We created a git ticket for recharter. Currently we have maintenance as main topic. If you have more ideas, let me know
karlcow: I don't know if we can do much more than finishing SVG2 for the next period
caribou: questions will likely be more about resources and not topics. Discussion will happen on github
caribou: announcement from/to AC will be send soon. Probably next week.