Anne van Kesteren annevk

Overview

There's an idea floating around of introducing a zip URL for resources. The general structure would be:

zip:{URL-to-zip}!{relative-URL-inside-zip}

Lack of ! is a parsing failure.

The zip URL works by (URL) parsing everything between zip: and ! against a base URL (if any).

Overview

This is a revision of https://gist.github.com/annevk/6174119 focusing on putting the semantics in the fragment identifier instead. The fragment identifier would follow http://www.w3.org/TR/media-frags/ (media-frags) and we'd introduce a new keyword http://www.w3.org/TR/media-frags/#processing-name-value-lists "path":

The general structure would be:

{URL-to-zip}#{media-frags}

http://fetch.spec.whatwg.org/ would be modified to support sub-responses for zip resources. First the resource would be fetched and then if it's a zip resource (signature sniffing) the fragment identifier would be processed per media-frags. The "path" keyword would be used to locate the sub-resource.

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

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.)

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.)

	callback EventCallback = void (Event event);
	dictionary EventOptions {
	DOMString filter; // selector (only useful if target is an element)
	boolean capture = false; // (!capture && !bubble) target
	boolean bubble; // (capture && !bubble) capture + target
	// (capture && bubble) capture + target + bubble
	boolean ignoreBubbles = true; // ignore bubbles attribute
	}

	partial interface EventTarget {

	Using some experimental JS IDL syntax:

	augment EventTarget {
	EventTarget on(String type, EventListener callback,
	{boolean ignoreBubbles?,
	String? filter = null,
	enum("capturing", "target", "bubbling") phase = "bubbling",
	String? marker = null});
	EventTarget off(String type, EventListener callback);
	EventTarget off({ String? type = null, String? marker = null });

	[12:47] <annevk> bz: So now I've got http://fetch.spec.whatwg.org/#requests as architecture for fetching, mostly based on Hixie's work in HTML and my work in CORS. However, I've gotten the impression that browsers have a slightly different architecture. One that involves at least a global object of sorts.
	[12:48] <annevk> bz: I'm wondering if I should attempt to reconcile the two. E.g. once a global object dies (removal of an <iframe>) we might want to kill all associated fetches as happens now.
	[12:52] <annevk> The global object (or browsing context or whatever we use) can also be used to find out some information, such as the origin, CSP policy, and maybe referrer?
	[13:45] <bz> annevk: good morning
	[13:45] * bz reads up
	[13:45] <annevk> bz: good afternoon ;)
	[13:48] <bz> hmm
	[13:48] <bz> So I can describe the setup in Gecko if you want
	[13:48] <bz> Note that I'm not sure it's a great setup
	[13:48] <bz> In fact, it has some crappy bits. ;)

	class Stream {
	Promise<StreamItem> read();
	}

	class StreamItem {
	any attribute value;
	boolean attribute done;
	}

	class ByteStreamItem extends StreamItem {

	Header set Strict-Transport-Security "max-age=31415926; includeSubDomains" env=HTTPS
	RewriteEngine On
	RewriteCond %{HTTPS} off
	RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]