dart2js generates code that references all DOM element types, even if Dart code doesn't use those types

[sethladd]

This code:

main() {
  query('#hello').text = 'Howdy!';
}

Generates JavaScript code that contains references to many (all?) of the DOM element types (such as SVG, WebGL, etc). The user code doesn't require or use SVG or WebGL classes, and shouldn't have to pay the tax.

This is especially important if a developer wishes to create a custom element with Dart and use that custom element on a page that has various other custom elements written in JavaScript. Ideally, the Dart custom element would be reasonable in size.

[sethladd]

One potential solution to this issue is to let the developer explicitly state which DOM types to pull into the dart2js output. If the developer can give dart2js more information (e.g. "I only expect to use DivElement"), then perhaps dart2js can generate code without all of the mentions to SVG, WebGL, etc.

The developer could use a metadata annotation on the import for dart:html to provide a list of DOM types the application requires.

[sethladd]

cc @kasperl.

[peter-ahe-google]

This would work with an HTML5 parser. Then the user could just tell dart2js which HTML files she plans to use.

[rakudrama]

Issue #9556 has some cleanup work. Once the cleanup is done, the empty elements like the following will vanish:

$$.CircleElement = {"": "StyledElement;"};
...
$.defineNativeMethods("SVGCircleElement", $.CircleElement);

All that will be left is the SVGCircleElement tag on the defineNativeMethods call for the superclass.

Best case scenario: all that is left of the SVG library is a list of ~70 SVG element tags, a little over 1k of string which will compress to a few hundred bytes.
Lets see if this happens in practice - small programs / components stand a good chance of having almost all empty SVG and HTML classes.

If the above reduction is working but the list of tags is too big, we can probably reduce it.
There is a mechanism which maps /^HTML.*Element$/ to HTMLElement to gracefully handle unexpected elements.
The compiler doesn't know it could rely on the mechanism be omitting matching tags if they are on HTMLElement.

In summary, lets see if we can make the general case work before complicating the programming model.

---

cc @karlklose.
Marked this as being blocked by #9556.

[kasperl]

Added this to the Later milestone.
Removed Priority-Unassigned label.
Added Priority-Medium label.

[kasperl]

Removed this from the Later milestone.
Added this to the M6 milestone.
Removed Priority-Medium label.
Added Priority-High label.

[rakudrama]

The empty classes are removed by r25067

---

Added Fixed label.

[sethladd]

Thanks for the update!