Issue 512 - HTML5 Integration - haxe

[waneck]

[Google Issue #512 : http://code.google.com/haxe/issues/detail?id=512] by ncanna...@gmail.com, at 2011-09-22T20:31:34.000Z Check for possible inclusion of StdJs HTML5 into haXe standard library :

https://github.com/xirsys/stdjs/

[waneck]

[comment from ncanna...@gmail.com, published at 2012-04-17T10:28:04.000Z]

[waneck]

[comment from tong.disktree@gmail.com, published at 2012-04-17T11:40:33.000Z] https://github.com/tong/hx.html5 might help too

[waneck]

[comment from ncanna...@gmail.com, published at 2012-06-06T09:19:28.000Z] I guess some questions need to be answered :

• what kind of package structure do we want : 1) one single import-all .hx 2) imports with several types grouped by feature, ex : import js.Webgl) 3) a more complex package structure (one type per file : import js.webgl.*)
• ensure no modification of the prototypes (new policy)
• ensure that we have one maintainer for long term

[waneck]

[comment from ah.duros, published at 2012-06-06T21:11:25.000Z] I've been experimenting with (2) over at https://github.com/aduros/Browser.hx. It was originally (1) but was a huge amount of unused parsing and slowed down compiles noticeably (at least on this old laptop). I'm thinking about converting it over to (3) once wildcard imports are in.

I'm not sure if I'll be able to maintain Browser.hx long-term, I'd rather merge it with one of the existing haxelibs. I do strongly think parsing IDLs and automatically generating externs is the way to go.

[waneck]

[comment from ncanna...@gmail.com, published at 2012-07-28T09:46:49.000Z] It seems that xirsys_stdjs makes several changes in JS core objects prototypes. We used to so in Haxe as well, but we stopped starting from 2.10. We would like to include parts of the HTML5 API in Haxe/std for 3.0 but I think we would have to remove all these changes, especially since it seems to cause several issues with other libraries.

[waneck]

[comment from jason.on...@gmail.com, published at 2012-07-28T11:38:37.000Z] I think the changes that are injected into Object have been removed on git:

https://github.com/xirsys/stdjs/commit/a288e5577304fe507de463c8a62c2e0ccda7ccd2

Though this hasn't been updated for the haxelib yet. Other than that I think the library doesn't modify any standard JS objects. (Possibly XmlHTTPRequest? Will have to check again).

The weird behaviour with the "hasOwnProperty()" function in the Object extern seems to persist.

[waneck]

[comment from tophattedcoder, published at 2012-10-07T20:31:28.000Z] Will this include an ArrayBuffer/Uint8Array backend for haxe.io.Bytes on the JS target?

[waneck]

[comment from niel.dru...@googlemail.com, published at 2012-10-28T13:56:01.000Z] I think before going on, there are some issues that need to be solved in a conform way, otherwise you'll build technical debt and have future issues like 'why doesn't haxe work with browser XYZ', or 'I cant use webgl with canvas2D'.

Languages like Dart and TypeScript are either leaning towards Webkit or IE, it is easier for them to decide on contentious issues, and generate code as they need it. And so, haxe must decide how to deal with vastly differing browser implementations:

• e.g. mouse wheel events. Properties of W3C wheel event are currently not implemented on any browser. Firefox uses propriety types like DOMScrollEvent.
• or keyboard events, although the W3C keyboardEvent class is used, properties and results differ. Again Firefox uses propriety types.
• all the propriety CSS-Declarations.
• DOM, XML parsing & XPath API's differ.

Since a result type of Dynamic is still invariant as soon at it is used, we do not deal elegantly with:

• canvas.getContext.
• webgl API methods where the underlying API will return a specific type depending on the value of a parameter.

For the latter, this makes the webgl API difficult to use, because you can not use the API as it was designed to be used.

Does the new policy 'no function injection' exclude the use of wrapper methods to make the API easier to use? e.g. canvas.getContext2D, canvas.getContextWebGL ?

A useful additional feature that would solve this is to the extend the annotation @:overload to be able to check for constant identifiers.

Also, there's the issue of scope:

• DOM level 2 and level 3?
• specifications that are in W3C but not implemented everywhere: e.g. indexedDB, CSS3D, web workers, xmlHttpRequest2.
• specifications that are not yet in W3C but implemented almost everywhere: e.g. web sockets, session history, typed arrays.
• specifications that are neither in W3C nor implemented everywhere: webgl.

[waneck]

[comment from ncanna...@gmail.com, published at 2012-10-28T14:33:07.000Z] I agree with all the points you make Neil.

The idea of an HTML5 API is to provide something "low level", that does not perform any browser detection-and-fallback implementation. This is the job of actual libraries to provide a high level cross browser API.

It means we want to include all the latest things such as WebGL. It will be up to the developer to check which browser supports it and adapt its code based on this.

It is still possible to define inline methods in extern classes in order to provide utility functions or type-safety since these will not get generated into the runtime. However they should clearly be documented as Haxe additions.

[waneck]

[comment from ah.duros, published at 2012-12-10T07:01:17.000Z] Committed in r5652. Please test and report bugs!