Meeting minutes
<karlcow> I see only Tav and me on the meeting for now
side and path attributes on textPath are missing on the IDL #1086
karlcow: path attribute on textPath not implemented at all
nzimmermann: This could make sense to add. I wouldn't mind. It can be useful.
nzimmermann: Yehonatan suggested to expose it as CSS property (like the d attribute) to animate it via CSS Animation.
nzimmermann: if we keep path, we should make it a CSS presentation attribute
krit: maybe we can add an annotation and put it at-risk unless there is interest to implement it
Yehonatan: We mimic the attribute with a library
Yehonatan: but CSS animation would be very useful
nzimmermann: I am refused by Roberts comment on the issue. If we had an animation, we could only use constants. The suggestion doesn't play well with baseVal or animVal
nzimmermann: ... we would need to define animations for constants which is a nobel task but has risks with backwards compatible way
nzimmermann: we shouldn't mix constants/enum that define animations in one but not another case
Yehonatan: there was a discussion to support logical values in CSS animations
<karlcow> https://
<nzimmermann> krit s/animations/SVGAnimatedEnumeration/
karlcow: If you look at the IDL, there is a specified value for degree/radian/... any other value type should be treated as unknown type
karlcow: would that apply to the side attribute?
karlcow: just want to know which path we are following
<karlcow> > The use of numeric angle unit type constants is an anti-pattern and new constant values will not be introduced for any other units or angle types supported by SVGAngle. If other types of angles are supported and used, the SVGAngle uses the SVG_ANGLETYPE_UNKNOWN unit type. See below for details on how the other properties of an SVGAngle operate with these types of angles.
nzimmermann: we need constants. They are simply missing. for consistency we should follow the existing enumerations.
karlcow: ok.
nzimmermann: later we could have an animated enum type, strongly typed that is backwars compatible to AnimateEnum.
nzimmermann: ...indistinguishable for JS. But right now, not.
nzimmermann: the constants for for side attribute. For path we still need to discuss.
RESOLUTION: Add constants for side attribute to IDL
RESOLUTION: Keep path attribute unchanged. No reflection in the IDL for this attribute
[SVG2] Drop inline-size attribute on text element from SVG2 #1087
<karlcow> https://
karlcow: There was more discussion on the git issue. Tav says InkScape implements the inline-size attribute
karlcow: currently not implemented in any browser
Tav: is it the CSS box model?
nzimmermann: related. Text layout is always hard. I don't think there is a technical issue to implement.
nzimmermann: But there is some resistance by browser vendors but can't tell.
nzimmermann: this is only about defining the size of the box and do text wrapping right?
Tav: yes
nzimmermann: You can not do that to text with CSS as we don't follow the box model.
<karlcow> https://
<karlcow> > The inline-size property allows one to set the wrapping area to a rectangular shape. The computed value of the property sets the width of the rectangle for horizontal text and the height of the rectangle for vertical text. The other dimension (height for horizontal text, width for vertical text) is of infinite length. A value of zero disables the creation of a wrapping area.
nzimmermann: all browsers implement text as CSS inline boxes. So should be easy to implement. Only restrain is that inline boxes are not infinite but have a size constrains.
nzimmermann: everything is there but someone would need to do it.
Yehonatan: Is this the only issue with text wrapping or is there more?
Tav: There is also wrapping in shapes
Tav: Firefox also supports multi-line text in SVG
Tav: So there are 3 ways of multi-line text in SVG2
Yehonatan: Having text wrapping in SVG is a holy grail
Yehonatan: If we would have wrapping it would be a very big thing
karlcow: SVG2 is not a living spec. So it does not evolve over time
karlcow: So if we do not have cross interop we should fix it or remove it
krit: that is a good point but it is in the spec already. So we are not adding it. We have one implementation and interest of the community. So it only requires another implementation. I'd suggest add an annotation that we are interested in it but need to remove if there is no 2nd implementation.
nzimmermann: I was wondering if there is any mention of text path? That is the tricky case.
Tav: agree
karlcow: Is there any issue with RTL or vertical text?
Tav: it works
nzimmermann: it is not just inline-size but als shape inside/outside
nzimmermann: if you look at the scope: if we define text to clip at boundaries with normal text line wrapping, we would get 95% of the use cases.
nzimmermann: So not make it complex and it would get approval
<karlcow> Shape-* issues w3c/
RESOLUTION: Drop text wrapping in CSS shapes for SVG2
<karlcow> https://
RESOLUTION: Keep inline-size as it is the simplest text wrapping suggestion for SVG2 and easy to implement it for browser vendors
Clarify systemLanguage parsing and evaluation algorithm
karlcow: Implementing it in WebKit... Proposal is to clarify the text in the spec.
karlcow: it is a big paragraph
karlcow: I created a PR which is ready for review
karlcow: for empty tokens, 2 commas, the spec says it gets empty items.
karlcow: but what should we do with the empty tokens? Drop it?
karlcow: how do we evaluate the empty tokens?
karlcow: I am suggesting to drop empty tokens as they don't provide any additional value
karlcow: there is only the language of the system so there is no fallback language. Just take what the browser suggests
karlcow: what do we do with invalid language tags? Drop them?
karlcow: I suggest to drop.
karlcow: There is a big chunk what to do with text. I did it reverse and reduced the amount of text. Replacing it with a list of steps.
nzimmermann: I think there is another level of complexity with svg string list
nzimmermann: In other cases there is a 1:1 reflection
nzimmermann: So the comma spearated list needs to have valid entries. So empty token would be an empty string in the string lists?
nzimmermann: Main question: when do we reflect the empty tokens? When we add them to the string lists?
karlcow: I don't have a strong opinion either
karlcow: in WebKit we are parsing the tokens into the string list
nzimmermann: so for WebKit it would be internally and exposed to the web
nzimmermann: and we can clarify that we drop empty tokens and keep them as invalid
RESOLUTION: Drop empty tokens during parsing and not add them to string list
RESOLUTION: Drop invalid system languages and align with error processing
RRSAgent: make minutes