Should we move more HTMLElement members to HTMLorSVGElement mixin?

[dstorey]

@annevk made the good point when making the change to include a HTMLorSVGElement mixin that there are other members on HTMLElement that would probably make sense to include in SVGElement via the mixin. click() is one example.

I'd like us to discuss on the call if we want to adopt any of these for SVG. For reference:

• newly defined HTMLOrSVGElement mixin
  
• The other members currently on HTMLElement

[AmeliaBR]

The GlobalEventHandlers include could be moved to the mixin, since SVGElement also implements it.

The 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 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. So probably no.

• lang would definitely be useful; it would reflect lang or xml:lang, according to the precendence rules in SVG 2.

• 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 Add contenteditable attribute for SVG text elements #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.)

[dstorey]

Yeah, GlobalEventHandlers just uses the old syntax which should be fixed with Dirk's PR.

In general in Edge most things on HTMLElement are fairly trivial to implement on SVGElement as our implementation shares the same base class, unless the behavior is expected to differ in SVG. I'd have to look at what we do for Boolean content attributes like hidden to see if they would work correctly when ported over. hidden just basically sets the equivalent of display: none;

If Edge supports the content attribute for contenteditable"correctly" in SVG then it is really trivial for me to add the IDL attribute . IF it is just that it sets it to contentEditable then that is a general reflect/attribute DOM bug in Edge that will get fixed anyway with work we're doing for an upcoming version.

[dstorey]

Re DocumentAndElementEventHandlers, good catch! Edge does it per spec. Firefox does per spec but additionally adds to SVGElement via the mixin. Safari uses the mixin but includes it directly on Element. Chrome just adds directly to the Element interface (same net effect just not as clean IDL files).

I'm going to make a PR to add this mixin to SVGElement in Edge to match Firefox and what the spec probably should be. The other option would be to match Chrome/Safari and include the mixin on Element, but I'd personally prefer to match GlobalEventHandlers here. The net result in how devs will use the feature will be the same (unless some other mythical markup language comes along that inherits from Element and suppose to be interactive).

[dstorey]

re: contentEditable in Edge: I've tested it and it does work, but it isn't particularly SVG aware so adds <br/> and <div> which isn`t ideal.

[css-meeting-bot]

The Working Group just discussed Should we move more HTMLElement members to HTMLorSVGElement mixin?.

The full IRC log of that discussion

<BogdanBrinza> topic: Should we move more HTMLElement members to HTMLorSVGElement mixin?
<BogdanBrinza> GitHub: https://github.com//issues/395
<BogdanBrinza> dstorey: Basic proposal - there are number of methods in HTML that might make sense to add to SVG
<BogdanBrinza> dstorey: click is one example, AmeliaBR added GlobalEventHandlers as potential one to add
<BogdanBrinza> dstorey: that all browsers but Edge support - so could be easy to add
<BogdanBrinza> AmeliaBR: regardless of the syntax would be useful to add to SVG anyway somehow
<BogdanBrinza> liam: Might be a good one to consider when we have tests
<BogdanBrinza> BogdanBrinza: given that 2+ browsers support this today - seems like capturing the truth, not a functional change
<BogdanBrinza> AmeliaBR: for additional features might want to be careful and make sure we have tests that verify no new major features are added as part of the effort
<BogdanBrinza> liam: Given that might affect ability to ship SVG 2.0 would like to defer to future
<liam> [Liam opposed to adding support for "lang" without i18n review]
<AmeliaBR> Proposed Resolution: Add DocumentAndElementEventHandlers mixin to SVGElment or HTMLOrSVGElement mixin if and only if at least two implementations pass tests; defer discussion of rest of the issue
<BogdanBrinza> Resolution: Add DocumentAndElementEventHandlers mixin to SVGElment or HTMLOrSVGElement mixin if and only if at least two implementations pass tests; defer discussion of rest of the issue
<BogdanBrinza> action: DStorey to add tests as discussed on the meeting just now
<trackbot> Created ACTION-3867 - Add tests as discussed on the meeting just now [on David Storey - due 2018-04-02].
<liam> [i can go and ask but pretty sure the answer is no, we should link to w3c html not to whatwg w3c. one reason is we need to link to a specirfic dated version in normative docs]

[tabatkins]

[i can go and ask but pretty sure the answer is no, we should link to w3c html not to whatwg w3c. one reason is we need to link to a specirfic dated version in normative docs]

Don't link to the W3C version. If for some reason you think you need a dated version, you can get specific commits of the WHATWG HTML spec; however, that's never actually been a requirement.

Note that Bikeshed very intentionally references [HTML] as the WHATWG version; if you need a specific W3C version you can linkify it manually.

[AmeliaBR]

@tabatkins Thanks, that's what we eventually decided, as recorded in the next topic, #60 (comment)