– DRAFT –
SVG WG

refX/refY keyword forms unimplemented and no WPT tests

w3c/svgwg#1137

karlcow: Implemented refX/refY in markler w/o keywords but percentage/number

karlcow: For symbol, not implemented in browsers but for InkScape it is

Tav: has been implemented a long time ago

karlcow: Keywords implemented on Symbols in InkScape

karlcow: ditto for marker

karlcow: at the moment there is no coverage in WPT

karlcow: The specification text seems vague for now with the SVGLength and how the keywords fit into SVGDOMs SVGLength.

nzimmermann: and from the parsing perspective...

nzimmermann: the grammar only accepts percentage length for SVGLength+percentage. It could be extended.

krit: is it actively used in InkScape?

Tav: likely for canned symbols to make align correct. You don't have to move the symbol to align it to a specific point.

karlcow: I understand the use case for symbol with refX and refY

karlcow: ... but should we expose the mechanism instead of special casing symbol?

karlcow: could it make SVG simpler to use?

Tav: we keep track of the center of the shape. This is most useful for shapes like starts and rotate around its center point

nzimmermann: for this, we now have transform-origin

Tav: this was invented before CSS came up with transform-origin

nzimmermann: refX and refY are independent of transformation.

nzimmermann: you would need a skew + scale to see the affect of it

nzimmermann: karlcow though that we could make it more generic and apply it to all shape kinds

yehonatan: For generic shapes it is common to define a place and shift from it

nzimmermann: then you would need to know the dimension of the shape.
… otherwise it would resolve to the viewport and not the shape

yehonatan: As the deveoper of the component, you know how the shape works and you want to align it for instance with text (baseline and so on)

nzimmerann: So it would make more sense to make it for symbols?

nzimmermann: At the end you don't want to alter the clipping and that is what refX and refY is good for.

Tav: it is always good for animations

Tav: refX and refY you want to be a specific point/anchor to place the object.

Tav: This is mostly coming from people doing maps.

nzimmermann: We still ned WPT coverage

<krit> s/nzimmerannn/nzimmermann/

karlcow: If you have tests, please add those to WPT

Tav: I have to search. They would need to get modified for WPT.

Tav: But I can create them

ACTION: Tav will check if he can contribute existing refX/refY tests to WPT

RESOLUTION: We keep refX/refY with keywords on symbol and marker in the spec. More implementations needed still

krit: what about the spec text that needs approvements?

karlcow: The IDL with SVGLength is not clear. Especially with animations and keywords.

krit: We could add a new value type for enumerations but this would still not allow animation from enum val to percentage for instance.

ACTION: nzimmermann and karlcow to look into refining the IDL spec text for refX and refY for keywords and SVGLength

Define how requiredExtensions values should be interpreted

w3c/svgwg#138

karlcow: the attribute can take links

karlcow: there are 2 hard coded values: namespace for HTML and XML

karlcow: there still is mathml for one implementation (gecko?)

karlcow: I wonder if InkScape has more namespaces than the 2/3 or if it is also limited to a set of namespaces

karlcow: if so, we can limit the namespaces to HTML and MathML

Tav: we don't have additional namespaces. I don't think we support requiredExtensions

nzimmermann: seems resonable to limit the support to HTML and MathML.

nzimmermann: it would be up to an implementation how to "rendeer" and XML tree. Gecko's support is nice but I don't see authors using it

nzimmermann: support limitation to HTML and MathML

nzimmermann: on the other hand: is there any case where it would resolve to false?

nzimmermann: browsers do support both after all

nzimmermann: or is it possible to turn of MathML in browsers?

nzimmermann: maybe Gecko does?

ydaniv: There might be security factors involved.

ydaniv: It does seem to be listed as an issue by sanitizer API

<karlcow> cure53/dompurify

ydaniv: that is why most people avoid it

caribou: It would be interesting to know if HTML is problematic but MathML isn't?

ydaniv: yeah then it could become useful

nzimmermann: I did not check dompurify but there are many features listed. Even preserveAspectRatio is listed.

ydaniv: some I added myself. requireExtensions I never had to use. So need to look it up

ydaniv: if the attribute is problematic, I wonder if it is worth the trouble.

ydaniv: I can look it up and get back on the issue

RESOLUTION: Limit namespaces for requiredExtensions to HTML and MathML

charter

<caribou> w3c/strategy#559

caribou: there is a new draft for an upcoming charter

caribou: trying to get the approval within the next 3 months and then bring it up to AC

karlcow: this is only for 3 months?

caribou: Idea is to get a follow-up charter that is good for 2 years.

caribou: I'd like to prepare a republication. I hope I get to it next week.

caribou: July 13 is the end of the publication moratorium

<caribou> charter expires on june 30th