I feel your pain. :-)

I've got a CL to test out the latter form:

https://chromiumcodereview.appspot.com/10534131/

Whoa, did we just complete each other's sentences? :)

Our plan of record here is to use method cascades.
The advantage of method cascades is that this kind of 'configuration' comes by default, and unlike passing a map, it is nicely typed with editor support.

If there is a problem with relying on method cascades, it needs to be fixed.

The list of attributes to add as optional parameters is large. Each additional optional parameter has a code size and performance tax since each optional parameter must be tested. A general map would require metadata for each element type to allow the attributes to be validated, otherwise methods and prototype chains could be replaced.

We can do the above, I'm just pointing out where we end up - a lot of code that is not really used.

With method cascades,

var div = new DivElement(id: 'foo', disabled: true, classes: ['bar']);

Becomes:

var div = new DivElement()..id = 'foo' ..disabled = true ..classes = ['bar'];

(You can do this today in dart2js, and it could be made a priority for the VM.)

FWIW, the original proposal for method cascades looked a little different, it would have looked more like this:

var div = new DivElement().{id = 'foo'; disabled = true; classes = ['bar']};

If you think method cascades do not deliver in terms of expressiveness, please open an issue against the language.

cc @larsbak.

This comment was originally written by @seaneagan

Elements happen to be very mutable, but for final fields, method cascades as currently specified don't help with construction in this way. It would be nice if method cascades involving final fields were allowed to be attached to constructor calls. For example, with Date, the isUtc parameter is merely tacked on to the end of each constructor, which might make adding new constructor parameters akward in the future. If method cascades could be used then this would not be an issue:

new Date.now()..isUtc = true;

Not sure if any special syntax would be required. I think with the original cascade syntax, it might look like:

new Date.now(){isUtc = true};

Also, the parameters would probably need to be made available to factory constructors somehow.

This comment was originally written by @seaneagan

I guess type authors though may wish to restrict setting final parameters at all, so maybe a better solution would allowing defining parameters which can only be specified by name, not by position. I think Gilad mentioned on the list that he was working on a proposal to orthogonalize named and optional parameters.

Removed Area-DOM label.
Added Area-HTML label.

Added this to the Later milestone.

Added html-api label.

Removed html-api label.

Removed Area-HTML label.
Added Area-Library, Library-Html labels.

Removed this from the Later milestone.
Added Oldschool-Milestone-Later label.

Removed Oldschool-Milestone-Later label.