Add Enumerators for all html and svg tags

[DartBot]

This issue was originally filed by @Emasoft

---

Enumerators have been added to Dart for a while now, but they are still not used by the framework. One of the main needs for enumerators in Dart is their use for providing the correct html and svg tags. Currently there are two way to access html or svg tags:

1 - by method or named constructor: divElement.style.marginLeft = "11px"; var pagetitle = Element.aside();

2 -by typing manually the name of the tag as a string parameter: element.style.setProperty("margin-left", "11px"); var pagetitle = new Element.tag('aside');

While the most safe and efficient method is the former, very often the code require to pass the attribute or tags names as a parameter to a general function, forcing the user to use mostly the latter and less safe method.

To avoid typing errors and to allow discoverability/autocompletition of html and svg tags the best way is to use enumerators.

Dart should provide in his standard html and svg libraries enumerators for all tags, maybe divided by categories, to allow a much safer syntax, like the following:

element.style.setProperty(HtmlFormatting.Margin-left, "11px"); var pagetitle = new Element.tag('HtmlElements.Aside'); etc.

Of course all the methods accepting the tags as string parameters should be refactored to also accept the various categories of enumerators. This would also improve the type safety of the code where only specific categories of attributes or tags can be accepted by a method.

[DartBot]

This comment was originally written by regardin...@gmail.com

---

I don't think this is a great idea, mainly because it wont give any advantage in the presence of custom elements. On tp of that we actually have the constructors.

As of the styling / formatting - no one really uses it that way because it is not an error to put a custom / non-existing property there - restricting this to an enum basically means that when a new property is added the enum should be updated before it can be used.

[DartBot]

This comment was originally written by @Emasoft

---

@regardin...: It IS useful. Your two worries are easily solved:

1 - custom elements : in case of custom elements the author of the component should provide the relative enumerator, with all custom tags and attributes. This will also make easier to discover custom elements and a new component attributes. In a big project, with tons of custom libraries and elements with custom tags, it would be an essential help being able to quickly browse and autocomplete those tags via enums. Lots of typing errors and bugs would be prevented.

2 - Restricting parameters to enums : I never said that passing the parameter as an enum should be the only way. It is perfectly fine to have two different method signatures ( I would say a method overload, but dart doesn't support method overloading yet): one accepting tags as string, with no check, and another one accepting tag as enumerators, providing type checking. The choice would be to the user. A C# coder like me, used to pass only enumerators, would choose the latter, while a javascript user could still prefer the unsafe and dirty method of typing all tags manually as strings. But the choice must be there.

This the most anticipated benefit of introducing enumerators in Dart.

[DartBot]

This comment was originally written by @Emasoft

---

I will add, in response to a question in the Dartisans g+ group, that should be better for those enums to be mantained by the dart team in a unique and standard library.

Leaving this to the community would create confusion between different libraries with different implementations and then those enums would not be interoperable between different libraries.

The only way to be sure that those enums will be interoperable is to make those part of the standard library of the dart framework.

Also this would allow eventually the dart team to refactor all dart methods accepting tags as input to add type checking on the enum parameters, to ensure that the correct enum is being passed.

[floitschG]

Added Area-Library, Library-Html, Triaged labels.