Type extension support in polyfill.

Basic functionality is working with JS native support and polyfill, still some issues with dart2js typechecking.

BUG=
R=jmesserly@google.com

Committed: https://code.google.com/p/dart/source/detail?r=26935

[Jennifer Messerly, 2013-08-29 20:57:29]

overall looks good, various minor comments/questions :)

https://codereview.chromium.org/23190026/diff/14001/tests/html/custom/documen...
File tests/html/custom/document_register_type_extensions_test.dart (right):

https://codereview.chromium.org/23190026/diff/14001/tests/html/custom/documen...
tests/html/custom/document_register_type_extensions_test.dart:11: static final
tag = 'x-foo';
trivial: these could be "static const"

https://codereview.chromium.org/23190026/diff/14001/tests/html/custom/documen...
tests/html/custom/document_register_type_extensions_test.dart:19: factory Bar()
=> new Element.tag('input', tag);
idea: add a test for incorrect impl of the factory?

for example:

// OOPS! This should fail somehow (at least in checked mode...)
// But maybe it fails somewhere else too?
class BarBad extends InputElement {
  static const tag = 'bar-bad'
  factory BarBad() => new Element.tag(tag);
}

// OOPS! This should fail too...
class FooBad extends HtmlElement {
  static const tag = 'foo-bad'
  factory Bar() => new Element.tag('input', tag);
}

https://codereview.chromium.org/23190026/diff/14001/tests/html/custom/documen...
tests/html/custom/document_register_type_extensions_test.dart:175:
document.$dom_createElementNS("http://www.w3.org/1999/xhtml",
do we have a bug to remove this bad $dom method?

https://codereview.chromium.org/23190026/diff/14001/tests/html/custom/documen...
tests/html/custom/document_register_type_extensions_test.dart:199: var container
= new DivElement()..innerHtml = html;
does this still work with the new safe HTML shenanigans?

https://codereview.chromium.org/23190026/diff/14001/tests/html/html.status
File tests/html/html.status (right):

https://codereview.chromium.org/23190026/diff/14001/tests/html/html.status#ne...
tests/html/html.status:10:
custom/document_register_type_extensions_test/namespaces: Fail
curious why this works on dart2js+drt but not other browsers? Does it fail in
Chrome too?

https://codereview.chromium.org/23190026/diff/14001/tools/dom/src/dart2js_Cus...
File tools/dom/src/dart2js_CustomElementSupport.dart (right):

https://codereview.chromium.org/23190026/diff/14001/tools/dom/src/dart2js_Cus...
tools/dom/src/dart2js_CustomElementSupport.dart:60: 'HTMLModElement': 'del',
there are a few duplicate entries here. How do we disambiguate?

Maybe we should require the user to pass the tag name, like document.register
does?

[blois, 2013-08-29 21:38:41]

https://codereview.chromium.org/23190026/diff/14001/tests/html/custom/documen...
File tests/html/custom/document_register_type_extensions_test.dart (right):

https://codereview.chromium.org/23190026/diff/14001/tests/html/custom/documen...
tests/html/custom/document_register_type_extensions_test.dart:11: static final
tag = 'x-foo';
On 2013/08/29 20:57:29, John Messerly wrote:
> trivial: these could be "static const"

Done.

https://codereview.chromium.org/23190026/diff/14001/tests/html/custom/documen...
tests/html/custom/document_register_type_extensions_test.dart:19: factory Bar()
=> new Element.tag('input', tag);
On 2013/08/29 20:57:29, John Messerly wrote:
> idea: add a test for incorrect impl of the factory?
> 
> for example:
> 
> // OOPS! This should fail somehow (at least in checked mode...)
> // But maybe it fails somewhere else too?
> class BarBad extends InputElement {
>   static const tag = 'bar-bad'
>   factory BarBad() => new Element.tag(tag);
> }
> 
> // OOPS! This should fail too...
> class FooBad extends HtmlElement {
>   static const tag = 'foo-bad'
>   factory Bar() => new Element.tag('input', tag);
> }

These are in the createElement and 'createElement with type extension' tests. I
just expanded these out into more sub-tests which makes it more readable, I had
already done this for the polymer.js tests at
https://github.com/Polymer/CustomElements/pull/59/files

https://codereview.chromium.org/23190026/diff/14001/tests/html/custom/documen...
tests/html/custom/document_register_type_extensions_test.dart:175:
document.$dom_createElementNS("http://www.w3.org/1999/xhtml",
On 2013/08/29 20:57:29, John Messerly wrote:
> do we have a bug to remove this bad $dom method?

Yes, I have a CL for it, but wanted to get this one submitted first.

https://codereview.chromium.org/23190026/diff/14001/tests/html/custom/documen...
tests/html/custom/document_register_type_extensions_test.dart:199: var container
= new DivElement()..innerHtml = html;
On 2013/08/29 20:57:29, John Messerly wrote:
> does this still work with the new safe HTML shenanigans?

This was uploaded before the safe HTML changes went in, this was updated with
that CL and is passing.

https://codereview.chromium.org/23190026/diff/14001/tests/html/html.status
File tests/html/html.status (right):

https://codereview.chromium.org/23190026/diff/14001/tests/html/html.status#ne...
tests/html/html.status:10:
custom/document_register_type_extensions_test/namespaces: Fail
On 2013/08/29 20:57:29, John Messerly wrote:
> curious why this works on dart2js+drt but not other browsers? Does it fail in
> Chrome too?

drt is using the native implementation, the polyfill is not polyfilling
createElementNS. I can implement it in polymer.js but I'm not sure how
interested they are in it. I need to get some of my other polymer.js changes
through first.

https://codereview.chromium.org/23190026/diff/14001/tools/dom/src/dart2js_Cus...
File tools/dom/src/dart2js_CustomElementSupport.dart (right):

https://codereview.chromium.org/23190026/diff/14001/tools/dom/src/dart2js_Cus...
tools/dom/src/dart2js_CustomElementSupport.dart:60: 'HTMLModElement': 'del',
On 2013/08/29 20:57:29, John Messerly wrote:
> there are a few duplicate entries here. How do we disambiguate?
> 
> Maybe we should require the user to pass the tag name, like document.register
> does?

It's actually only the polyfill which needs this- the native versions do not.
I'm inclined to keep the list unless there are specific use-cases to
disambiguate- we can add an optional parameter to override the default detection
if necessary.

[Jennifer Messerly, 2013-08-29 22:44:27]

https://codereview.chromium.org/23190026/diff/14001/tools/dom/src/dart2js_Cus...
File tools/dom/src/dart2js_CustomElementSupport.dart (right):

https://codereview.chromium.org/23190026/diff/14001/tools/dom/src/dart2js_Cus...
tools/dom/src/dart2js_CustomElementSupport.dart:60: 'HTMLModElement': 'del',
On 2013/08/29 21:38:41, blois wrote:
> On 2013/08/29 20:57:29, John Messerly wrote:
> > there are a few duplicate entries here. How do we disambiguate?
> > 
> > Maybe we should require the user to pass the tag name, like
document.register
> > does?
> 
> It's actually only the polyfill which needs this- the native versions do not.
> I'm inclined to keep the list unless there are specific use-cases to
> disambiguate- we can add an optional parameter to override the default
detection
> if necessary.

okay, that makes sense, but surely we need that parameter for HTMLModElement,
HTMLQuoteElement, and HTMLTableSectionElement at the very least?

seems bad to have a const map with duplicate keys :)

[blois, 2013-08-30 17:11:25]

On 2013/08/29 22:44:27, John Messerly wrote:
>
https://codereview.chromium.org/23190026/diff/14001/tools/dom/src/dart2js_Cus...
> File tools/dom/src/dart2js_CustomElementSupport.dart (right):
> 
>
https://codereview.chromium.org/23190026/diff/14001/tools/dom/src/dart2js_Cus...
> tools/dom/src/dart2js_CustomElementSupport.dart:60: 'HTMLModElement': 'del',
> On 2013/08/29 21:38:41, blois wrote:
> > On 2013/08/29 20:57:29, John Messerly wrote:
> > > there are a few duplicate entries here. How do we disambiguate?
> > > 
> > > Maybe we should require the user to pass the tag name, like
> document.register
> > > does?
> > 
> > It's actually only the polyfill which needs this- the native versions do
not.
> > I'm inclined to keep the list unless there are specific use-cases to
> > disambiguate- we can add an optional parameter to override the default
> detection
> > if necessary.
> 
> okay, that makes sense, but surely we need that parameter for HTMLModElement,
> HTMLQuoteElement, and HTMLTableSectionElement at the very least?
> 
> seems bad to have a const map with duplicate keys :)

Added ability to specify the tag and cut down the list to only handle the more
common cases- so hopefully the basic native syntax works in most cases but users
can specify the base tag in places where we miss it.

[Jennifer Messerly, 2013-08-30 17:34:31]

LGTM!

[blois, 2013-08-30 19:08:27]

Committed patchset #3 manually as r26935 (presubmit successful).