Publish the web-sys crate

[fitzgen]

As discussed in today's WG meeting, we are aiming for publishing an initial release of the web-sys crate for the Rust 2018 Release Candidate milestone. That's 6 weeks from now: 2018-09-13.

What needs to be done before we ship an initial release of web-sys?

Goals

• Namespaces support: Support WebIDL namespaces #253
• Remove all typedefs: WebIDL: Remove all typedefs in early passes #623
• Headless testing in Chrome: web-sys: Add Chrome headless testing to CI #622
• Support HTMLConstructor attribute: WebIDL: Support the HTMLConstructor attribute #621
• Enable bindings generation for all the interfaces that need Option<scalar>: WebIDL: enable bindings that take Option<scalar> #624
• Enable bindings generation for all the interfaces that use funky-named enum variants: WebIDL: Enable bindings that have unusual enum names #625
• Implement inheritance and upcasting from RFC #2
• Support WebIDL getters/setters: Support WebIDL getters and setters #248
• Generate bindings for document.createElement: Generate bindings for document.createElement #658
• Expose a getter for the global window: Expose a getter for the global window #659
• Support WebIDL dictionaries: Support creating bindings for WebIDL dictionaries #241
• Support WebIDL callbacks: Support WebIDL callback functions #257
• Feature gate individual interfaces to get faster compile times: Gate web-sys APIs on activated features #790
• Do a final audit of unsupported warnings and determine if any of them are blocking critical web APIs (eg the body for fetch thing in web-sys: Unable to add body to a Request #817)
• Do an audit for moz-prefixed APIs that shouldn't be included in web-sys
• Figure out how to expose global window APIs: web-sys's API around Window seems to be wrong #834
• Have announcement blog post ready to publish at the same time that we push to crates.io

Stretch

• RFC and implementation for traits to expose a derived type's inherited methods
• Add an example of working with the DOM via web-sys: Add a DOM manipulation with web-sys example to examples/ and the guide #446

---

What else should we make sure is done for an initial release? For reference, here are all the "frontend:webidl" issues and here are all the "web-sys" issues

+cc @ohanar @alexcrichton @twilco @Dodj @jonathanKingston

[ohanar]

Namespaces and inheritance have been on the top of my todo list when I get a moment. Inheritance is needed for many useful bindings (my plan for the moment was to basically treat them like mixins until we decide on how we want to expose the hierarchy).

[fitzgen]

@ohanar good call! Added an item about implementing inheritance from the RFC.

I think we should hold off on mixins or traits for base methods until we have another accepted RFC, since we definitely don't want to ship something as big as that until we are fairly sure it will be stable and not undergo a bunch of churn. That means that if we want to include something like that for the initial web-sys release, we should be starting design work / writing a draft of that RFC now.

[alexcrichton]

Another checklist item (which I don't think we have a tracking issue for yet) is a lack of constructors, for example HtmlDivElement doesn't have any constructor methods generated, but the WebIDL lists the HTMLConstructor custom attribute, which I believe we're not currently processing.

[alexcrichton]

One last thing I think we'll want to do is to set up headless testing for Chrome as well on CI to ensure that we don't get things that are too Firefox-specific

[ohanar]

@fitzgen I would definitely say the inheritance RFC needs to happen then. The most popular proposal of using traits (like stdweb), doesn't match the current API, since all methods would be on traits rather than directly on the types, so implementing such a proposal would require comparable churn.

[ohanar]

One last thing that I just thought of, is that typedefs should be removed. The spec makes it clear that these should not be exposed in language bindings. With the first pass in the webidl frontend, it should be quite straightforward to process them there.

[twilco]

Do we want to specifically call out #248 as a checklist item? It is blocking generation of methods for certain structs - e.g., the Storage struct, which has a getter and setter defined in the WebIDL.

[alexcrichton]

I've updated the OP and filed dedicated issues for the items mentioned here!

[fitzgen]

@ohanar

The most popular proposal of using traits (like stdweb), doesn't match the current API, since all methods would be on traits rather than directly on the types, so implementing such a proposal would require comparable churn.

Couple things:

1. We definitely need a more fleshed out design than "using traits like stdweb" ;) If you want to start a draft/WIP RFC that we can collaborate on and discuss, that would be super helpful in pushing this forward!

2. I could see a potential universe where we shipped without any base-traits inheritance method stuff, only shipped with normal methods, and then as a non-breaking bump added the traits as additional things. That said, I would still prefer to ship with the nicer traits-based thing.

[ohanar]

@fitzgen

I would be happy to write up a draft RFC, although I'm super swamped at the moment and likely won't have much time to do anything real for at least a week.

The main complaint that I have with a non-breaking traits based thing is that it feels super weird to me for instance for a MouseEvent to have have a related_target property (in the form of a getter), but not have a target property unless a trait is imported. I worry that the asymmetry would be confusing to newcomers. (I also worry that a whole trait-based approach would be unwelcoming for people coming from the javascript world where nothing extra has to be done to access base class methods/properties.)