annevk

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.

annevk

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 });

annevk

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 {

annevk

<sole_> so essentially - unless you're paid to read email (e.g. as anne is) email lists are super time consuming and very few people can spend the time on doing that
<sole_> can/want
<sole_> so yeah email can be very exclusionary :)
<jgraham> My experience is that putting the same volume of discussion on a forum or bugtracker doesn't magically reduce the amount of work you have to do to pay attention to the bits you care about
<annevk> sole_: I think it's about being paid to work on this stuff in general
<annevk> sole_: standards is actually a lot of work, so expecting people to work on it in their free time is like expecting people to work on open source in their free time
<sole_> yes!
<annevk> sole_: it's not really about communication medium, although some people like to invoke that distraction
<annevk> (I mean, I do think that GitHub over W3C Bugzilla is more new-folks-friendly, but it's peanuts compared to the overall cost.)
<annevk> sole_: I'd be interested in learning how you folks communicate though a

annevk

Drastic simplification of the browser networking model.

API (<img>, <script>, XMLHttpRequest, fetch(), etc.)
  Creates a request with various settings
  Invokes Fetch with that request
  Uses the returned response in various ways.

Fetch (takes a request, returns a response)
  If scheme is not http/https, follow scheme-specific rules to create a response.
  If there's a service worker (and this invocation of Fetch did not come from a service worker), invoke Service worker.

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

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

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

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

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: