annevk

1. Let first1024Bytes be null.

2. In parallel:

   1. Let bytes be the empty byte sequence.

   2. Let transformStream be a new TransformStream.

   3. Let transformAlgorithm given a chunk be these steps:

annevk

A TransparentContainer node is an object intended to be used as a primitive in templating systems. It's effectively a DocumentFragment node that is not "unwrapped" upon insertion. TransparentContainer nodes can be arbitrarily nested.

Selector matching and rendering will act as if any TransparentContainer nodes in the node tree are replaced by their contents.

Hierarchy restrictions placed upon nodes will need to apply to the children of TransparentContainer nodes as if the TransparentContainer node was not there. We can simplify these requirements somewhat by only allowing TransparentContainer nodes as descendants of the root element.

[Constructor,
 Exposed=Window]
interface TransparentContainer : Node {

annevk

Due to unfortunate legacy reasons the HTML Standard had to define a rather complicated global setup. There's not just "the current global" (ECMAScript's current realm), but also entry and incumbent.

Which globals entry and incumbent are is not always well-defined:

• "Entry" concept is broken while executing enqueued jobs
• This is also true for Streams: bug 1384006 (No corresponding standard issue yet with clearer description.)

There's also a more general issue with which global to use for objects in IDL and which global to use for report the exception.

Solving these problems requires a bunch of investigative testing, recommendations for changes to browsers (and corresponding bugs being filed), and recommendations for changes to standa

annevk

The HTML Standard defines a navigate algorithm that is frought with interoperability issues. There are various endpoints that end up triggering it:

• <iframe>
• <a>
• <form>
• location.href
• window.open()
• ...

Although the algorithm is based on reverse engineering browsers, the browser landscape has changed and not all choices made were necessarily optimal for the current environment. Furthermore, browsers have not actively aligned with the standard and things have drifted. In order to do better we need to study the algorithm again and:

annevk

ECMAScript has a concept of agents. Browsers support multiple agents (see the HTML Standard):

• Similar-origin window agent
• Dedicated worker agent
• Shared worker agent
• Service worker agent
• Worklet agent (this might actually end up being several more, but is not really part of the scope for now as worklets haven't shipped yet)

TC39 maintains a test suite, but this is only run in a single browser agent I'm told, the similar-origin window agent. That means it's highly likely that SharedArrayBuffer objects are poorly tested. It also means that we don't know for sure that all features ECMAScript defines work in each agent. And while there's unlikely to be differences, it would be good to verify that assumption. Goals:

annevk

Use a column width of 100 characters.

Do not use newlines inside "inline" elements, even if that means exceeding the column width requirement.

<p>The
<dfn method for=DOMTokenList lt=remove(tokens)|remove()><code>remove(<var>tokens</var>&hellip;)</code></dfn>
method, when invoked, must run these steps:

is okay and

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"