Meeting minutes
present_
Remove "side" attribute from "textPath"
karlcow: It is implemented in Firefox, Inkscape, VSVG, I think it is just a matter of shipping in Blink and WebKit.
krit: So we have enough implementations
karlcow: The test is failing in Firefox due to fuzziness. So we need to make it less error prone
viralipurbey: I will take that and make sure if works in Firefox.
ACTION: Update WPT test for text path so they pass reliably in implementations
RESOLUTION: Keep "side" attribute for "textPath"
Does the entire path need to be valid in order to use a path attribute on a textPath
viralipurbey: We wrote the test for it.
viralipurbey: We added WPT tests and was not sure what the behavior should be. If we have an invalid path, the valid path would be an empty string. Should we fallback to href? But then I checked in FF. If path has an error, the valid path is being used. If that is an empty path, then Firefox would still fallback to href. This is contrary to our last resolution.
viralipurbey: I believe Chromium always falls back to href.
viralipurbey: Safari does only use href if path data is not specified at all.
<karlcow> I just approved web-platform-tests/
krit: so we have 3 different implementations with 3 different behaviors
viralipurbey: if we keep the resolution, we need to change the spec.
dmangal: This is similar to path error handling for regular path?
krit: yes, take the path up to the first error
karlcow: IMO it is easier to debug if one can see at which point there is an error.
nzimmermann: It is misleading to compare the path rendering with text on path. Path rendering does not have a fallback. If I was developer, specifying both does not make sense. Because, why specify fallback in the first place if you have a path. However, we need to deal with the situation.
nzimmermann: I am not opposed to viralipurbey 's request to change the resolution.
viralipurbey: Here we talk about text path which can reference a path element. There we use the error handling logiuc (using the valid sqeuence up to the error).
krit: Is it written in a spec to use href as fallback or as an alternative?
viralipurbey: the spec text at the moment refers to it as both. A fallback for an error.
<karlcow> https://
<karlcow> Current spec text:
<karlcow> > If the ‘path’ attribute contains an error, the ‘href’ attribute must be used.
nzimmermann: that makes sense to me: Path has no fallback. So if it begins with an error, we fallback. If there is an error later on, we take the valid path.
<karlcow> Also https://
<karlcow> > A path data string describing the path onto which the typographic characters will be rendered. An empty string indicates that there is no path data for the element. This means that the text within the ‘textPath’ does not render or contribute to the bounding box of the ‘text’ element. If the attribute is not specified, the path specified with ‘href’ is used instead.
RESOLUTION: If the d attribute would result into an empty path (not specified, no path data or due to an error) we fallback to href. If there is at least some valid path data at the beginning, we will continue to use the path data specified with the d attribute up to the error.
ACTION: viralipurbey will update the spec
Remove/Better testing correspondingElement and correspondingUseElement from SVGElement
Support pathLength via CSS
viralipurbey: I think in 2020 we raised the issue and got a resolution to support pathLength as CSS property and got positive feedback from browsers.
viralipurbey: No spec update and not implementation updates either.
viralipurbey: we have added the support for it to Chromium
viralipurbey: the only thing that is pending is updating the spec. I created a PR for it.
<viralipurbey> w3c/
viralipurbey: Initialy it was just an attribute. Now it follows the CSS cascade.
<karlcow> WPT tests web-platform-tests/
krit: Why not use a <length> value?
viralipurbey: the original attribute is not a number
krit: but we could extend it to <number> | <length>
viralipurbey: It is actually a scale factor
nzimmermann: you are right that it is used as scale factor but it would be very useful to use length. The implementation can compute the scale factor.
nzimmermann: right now, you need to use view boxes.
nzimmermann: would we change it for the attribute?
krit: it is a presentation attribute and shares a common grammar.
krit: viralipurbey would you approve to use length?
viralipurbey: I'd like to experiment first. Lets bring it up next week.
divyansh: I'd also like to talk to FF
nzimmermann: There might be more use cases for non-fixed units that I haven't thought about. Lets discuss next week.
ACTION: To all to investigate the implications of allowing length units on pathLength
RRSAgent: make minutes