annevk

Not really in any particular order. Some are more logical than others.

• TextDecoder / TextEncoder
• URL
• fetch() (unclear yet how we are going to namespace this, CORS behavior also does not make much sense outside browser context)
• Worker / SharedWorker (and all the port business, structured cloning is on its way already; would require events to be ported too)
• window.btoa() / window.atob()
• window.setTimeout(), …
• ImageBitmap
• EventSource

annevk

I just wanted to clarify something with regards to the review note at the end of http://www.unicode.org/reports/tr46/proposed.html#Implementation_Notes

What I'd really like to see is a syntax description. E.g. a domain consists of domain labels separated from each other by domain label separators, optionally with a trailing domain label separator. A domain label is a sequence of one or more code points which are one of X, Y, and Z. A domain label separator is one of X, Y, and Z. Alternatively you could express this using ABNF or some kind of grammar.

That is the kind of thing people writing validators or authoring tools are often looking for. And often web developers as well. They don't want to have to put some input they made up through a series of functions before they know whether the input is valid. I guess another way of saying this would be having a declarative description of a domain.

(This is an open issue https://www.w3.org/Bugs/Public/show_bug.cgi?id=25334 for the URL Standard.)

annevk

• IO streams. (Domenic is leading an effort on GitHub. This is high priority, like promises was last year.)
• Asynchronous iteration (event streams?). (Database cursor, going through a directory, going through entries in storage, scanning TV channels.)
• A plan around distinct Error types and detection (e.g. for APIs that can fail in multiple ways where you might want to recover from certain class of errors; think network APIs, databases)
• A better way to define ES APIs than WebIDL. (Part of the problem here is lack of maintenance. So maybe it's as "simple" as finding someone.)

annevk

I have annevk@annevk.nl which forwards to annevankesteren@gmail.com. I can email as annevk@annevk.nl but this sometimes causes issues and it is clear Gmail is spoofing the From header.

annevankesteren@gmail.com is my Hangouts and Google+ account ID. I do not want to lose my friends and history there.

I want annevk@annevk.nl to be my actual email address and either delete annevankesteren@gmail.com or make it Gmail-only and forward the email to annevk@annevk.nl. I also want annevk@annevk.nl to replace annevankesteren@gmail.com as my Hangouts and Google+ account ID, not losing any of the friends and history associated with it.

As far as I can tell there is no way I can get this. 😟

annevk

To be crystal clear, this is an idea, not a proposal.

The motivation is solving the custom element upgrade step through JavaScript, while also allowing other syntaxes to be mixed with HTML if so desired. The macro element generates a sequence of tokens that can be processed by JavaScript.

document.getMacro().then(function(macro) {
  // This should probably be asynchronous so large macros can be done incrementally
  for(let token of macro.tokens) {
    // Let's build a tree, or reparse tokens Markdown-style...
    ...

}

annevk

The Jonas proposal is to have a normal JavaScript subclass:

class MyElement extends HTMLElement {
  constructor(htmlElementConstructorOptions, ...extraArgs) {
    super(htmlElementConstructorOptions);
    // initialization code here, potentially using extraArgs for non-parser cases
  }
}

The catch is that while parsing you need to do bookkeeping when you encounter custom elements (those with a dash) and then construct and insert them at a later point. This does not quite explain the platform:

annevk

A Request object is needed to fetch. A Response object is the result. fetch() starts the process. How do we control it?

1. fetch(req); req.abort()
2. var f = fetch(req); f.abort() (subclassing promises seems to clash with upcoming async/await syntax)
3. fetch(req, handle(a) { a() })
4. fetch(req, { control:true }).then(con) { con.abort() } (fetch() would resolve immediately; control object would also have con.response or some such returning a promise)
5. var c = req.send(); c.abort() } (get the control object synchronously)
6. fetchRegistry.last.abort() (have some kind of global registry for all fetches made within the environment)

annevk

After Ryosuke, Travis, Wilson, William, and I discussed the problem for an hour over a burrito, William came up with this approach. All hail William.

annevk

{
  "BOOKS": {
    "authors": ["Håkon Wium Lie"],
    "href": "https://books.spec.whatwg.org/",
    "title": "CSS Books"
  },
  "DIFFERENCES": {
    "authors": ["Simon Pieters"],
    "href": "https://html-differences.whatwg.org/",
    "title": "Differences from HTML4"

annevk

# a set of tests designed by zcorpan for relative URLs
i sc:sd
i sc:sd/sd
i sc:/pa/pa s:sc p:/pa/i
i sc://ho/pa s:sc h:ho p:/i
i sc:///pa/pa s:sc h: p:/pa/i
../i sc:sd
../i sc:sd/sd
../i sc:/pa/pa s:sc p:/i
../i sc://ho/pa s:sc h:ho p:/i