Re: [svgwg] Should we move more HTMLElement members to HTMLorSVGElement mixin?

The `GlobalEventHandlers` include could be moved to the mixin, since [`SVGElement`](https://svgwg.org/svg2-draft/types.html#InterfaceSVGElement) also implements it.

The [`DocumentAndElementEventHandlers`](https://html.spec.whatwg.org/multipage/webappapis.html#documentandelementeventhandlers) mixin is new, I think, and we don't currently mention it in SVG, but it should also be added to the mixin (and is proof of why the mixin is important, so new features get shared!). Chrome and Firefox implement these event handler attributes on SVG elements, Edge 16 does not.

At this point in time, I don't think we should add additional features that aren't supported in user agents. Let's focus on the existing SVG 2 features.

______________________

But...
For the future, I'd support adding `lang`, `click()`, and probably `innerText` without other spec changes. Some of the others could be added with matching global attributes if there was implementer support for extending the attribute's functionality to SVG.

Reasoning, going through the [HTMLElement interface](https://html.spec.whatwg.org/multipage/dom.html#htmlelement) in order:

- `title` would be complicated, since it would need to get/set the child title element. Which gets even more complicated with [multi-lingual titles](https://svgwg.org/svg2-draft/struct.html#DescriptionAndTitleElements). So probably no.

- `lang` would definitely be useful; it would reflect `lang` or `xml:lang`, according to [the precendence rules in SVG 2](https://svgwg.org/svg2-draft/struct.html#LangSpaceAttrs).

- `translate` would require the addition of a matching attribute.

- `dir` doesn't have a nicely matching attribute. SVG uses the `direction` presentation attribute for the CSS property, instead.

- `hidden` doesn't have a nicely matching attribute. SVG uses presentation attributes for `visibility` or `display`.

- `click()` seems like a harmless addition.

- `accessKey` and `accessKeyLabel` are could be added, if there is browser implementer support for adding the functionality. Since they are now global attributes in HTML rather than being tied to native input elements only, they could logically be extended to SVG widgets made with `tabindex` and ARIA.

- `draggable` could be added, along with a matching attribute, if there is browser implementer support for adding the functionality. But I don't know enough about the Drag & Drop API to know if there are any complications with extending to SVG which would need to be spec'd first.

- `spellcheck` could be useful, if added with a matching attribute.  I've never heard of `autocapitalize`, but it could come along for the ride. Both sound like something that should be part of the `ElementContentEditable` mixin. Or maybe HTML needs a more generic mixin, for content-editable-or-text-input elements?

- `innerText` could be _very_ useful, but only if we double-check that it's rules for collapsing whitespace and skipping over non-displayed elements match the rules that the SVG text layout uses for assigning layout positions to characters. (I *think* they do, and we should probably try to harmonize if they aren't, but... needs review.)

- I'd love to have `contenteditable` attribute & IDL added to SVG (see #332) although it really only makes sense on text elements, not on the general `SVGElement` interface. (Edge currently supports the attribute, but not the IDL properties. And it converts the attribute to mixed case form, like it does with `tabindex`. So not enough of an implementation to argue that we should make the spec change now to match.)



-- 
GitHub Notification of comment by AmeliaBR
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/395#issuecomment-375817781 using your GitHub account

Received on Friday, 23 March 2018 22:45:59 UTC