dart:html compatible library

[jmesserly]

we should expose a library where interfaces are 100% dart:html compatible. It's fine if they throw unsupported, the important bit is to have full API compatibility. This allows code to be written that can work on either environment by simply swapping the import.

https://github.com/dart-lang/html/blob/master/lib/dom.dart isn't a bad start, but it has a ways to go.

Possibly quick idea to get started: reflect over dart:html using package:analyzer, and then dump the APIs. Use that as the starting point, then fill in the implementations where we can (everything related to parsing, DOM traversal, query selector, etc).

[jmesserly]

CC @kegluneq and @mprobst

[alan-knight]

It might be easier, and easier to keep up to date with rolls, to tweak the scripts that generate the dart:html and related libraries to generate with a name change and no implementation, or an implementation that throws. Then again, it might not, those scripts are fairly messy.

[mprobst]

Just making the VM automatically serve the right thing when importing dart:html on the server sounds good. Any idea what a timeline in that would be?

Alan Knight notifications@github.com schrieb am Mi., 6. Mai 2015 12:32:

It might be easier, and easier to keep up to date with rolls, to tweak the scripts that generate the dart:html and related libraries to generate with a name change and no implementation, or an implementation that throws. Then again, it might not, those scripts are fairly messy.

— Reply to this email directly or view it on GitHub https://github.com/dart-lang/tools/issues/1097.

[jmesserly]

It might be easier, and easier to keep up to date with rolls, to tweak the scripts that generate the dart:html and related libraries to generate with a name change and no implementation, or an implementation that throws. Then again, it might not, those scripts are fairly messy.

haha. Yes, that was exactly my original train of thought, but last time I tried it, that was the exact problem I hit, which prevented a solution. ;)

Given the changes in mission for Dartium, I think (hope?) we'll be in less of a "roll" mode. For example, I don't think package:html would be in the business of exposing every bleeding-edge experimental API added to Chrome. We'd be more interested in the cross-platform set of APIs.

[jmesserly]

Just making the VM automatically serve the right thing when importing dart:html on the server sounds good. Any idea what a timeline in that would be?

I suspect we'd have more luck fixing it the other way, by having browsers import something different when they see "package:html/html.dart". CC @dgrove too for thoughts.

[zoechi]

https://github.com/lrhn/dep-configured-imports

[jmesserly]

https://github.com/lrhn/dep-configured-imports

yup, that would work, but I'm not sure we need the fully configurable imports just for the package:html case, which we could just have the embedder know about

[dgrove]

A few thoughts:

• yes, we're less interested in exposing bleeding-edge API's via dart:html - those can be added via packages, per @alan-knight 's work.
• we can address this in the dart4web toolchain, I think. I don't see any need to change the VM for this.

[jmesserly]

Interestingly, with https://github.com/lrhn/dep-pkgspec we have another possible solution, via package spec file. Configure it to map:

package:html --> /path/to/package/html_browser

Basically, your "web" entry points and server entry points go to different "html" packages. All you would need is a different packages.cfg file next to the server/web entry points. e.g. you can just have a test/console/packages.cfg for running tests on VM and pass it manually. Or generate it on-the-fly via test runner.

This wasn't a practical solution back when we had "packages" symlinks all over the place, but maybe is now.