The as attribute is defined as taking a https://fetch.spec.whatwg.org/#concept-potential-destination.*

https://html.spec.whatwg.org/#match-preload-type however returns false for a number of destinations.

We should probably make it clearer to web developers what they can preload.

cc @noamr

*Ouch. It seems that definition has the member/value type conflict going on.

@domenic I'm sorry about this, I followed on page 404. Sorry, won't happen again, I'll read it first another time

Link: http://dev.w3.org/html5/webdatabase/

I'm not sure why you're filing this issue here; we don't control the "Web SQL Database" document which you're talking about.

Link: http://dev.w3.org/html5/webdatabase/

Do not have members that are both optional and nullable.

Fixes #1204.

There's an example in §2.7 Dictionaries as follows:

dictionary PaintOptions {
  DOMString? fillPattern = "black";
  DOMString? strokePattern = null;
  Point position;
};

This example is giving bad design advice since both fillPattern and strokePattern are both nullable and optional. There's no need for them to be nullable.

• fillPattern has a default value, which means if omitted, it will be "black", but it can also be explicitly set to null. It's not clear why you would design something that can be set to null, but with a non-null default value.
• strokePattern is a little more reasonable, having a default value of null, but this is still unusual. It's best practice to have it simply be optional with no default, so if omitted it will simply be missing from the dictionary, rather than having a null value.

Therefore I think it should be rewritten to avoid the nullability:

dictionary PaintOptions {
  DOMString fillPattern = "black";
  DOMString strokePattern;
  Point position;
};

(At a higher level, this feels like a strange design for a drawRectangle method, taking the "position" — presumably the top-left corner — in an optional PaintOptions dict, but the width and height as direct arguments. I might also suggest making both the options argument and the position member required, which helps demonstrate when required is a good choice. But it's not clear whether that's the intention behind the design.)

We lock the stream in the "incremently read" algorithm which is called from "To transmit request’s body" algorithm. My concern is whether there's a window between that and checking the stream is not locked in the Request constructor during which someone else could lock the stream. For correctness, we need to ensure that we have the stream locked the whole time once we've taken ownership of it.

"incrementally read" has a note that getting a reader will not throw an exception but if JavaScript can run between creating the Request and calling "incrementally read" then that note would be incorrect.

In #8306 is being proposed to only use the empty string as an indicator that there are element associations.

If that's the final agreement, this case here won't be an issue as the final HTML would be:

<div id="target" aria-describedby="">target</div>
<div id="desc2">First description</div>
<div id="desc1">Second description</div>

And we'll only be able to check the association via ariaDescribedByElements as the content attribute is not going to be useful.

https://html.spec.whatwg.org/#create-link-options-from-element seems incorrect. /cc @noamr

I think for HTTP Link headers, the difference is not observable, since there will be no <base> elements at the time headers are processed, and about:srcdoc and about:blank documents cannot have Link headers. But, it might be good to update them for consistency.

Unfortunately this isn't workable for privacy reasons: https://hillbrad.github.io/sri-addressable-caching/sri-addressable-caching.html#history_leaks . (The document as a whole is about this idea you're proposing, so maybe it'd help to read it from the beginning.)

I'll close this, but happy to discuss more in the closed thread if necessary.

(Sorry of this should be a PR - first time in this repo.)

Since reliance on CDNs for e.g. external Javascript files is bad, I recommend that all tags that have a 'src' attribute should also have an optional 'hash' attribute.

The author of the HTML file could then specify the e.g. SHA256 hash of the file required. The browser can then check if any file in it's cache matches that hash, and use a local copy, if available.

If there's a cache hit, this would save one HTTP request and would also allow the browser to use a file downloaded from some other URI, even with another filename, as long as the contents match.

This would, in turn, essentially resemble a distributed CDN for many often-used files, like the popular Javascript files and webfonts, etc.

Hashes like this are already in use for Subresource Integrity (https://w3c.github.io/webappsec-subresource-integrity/), but in that context they don't replace the URL as the cache key, and the invalidation they provide happens separately from cache invalidation.

A problem with the idea of caching files by hash is that caches are partitioned per-site, and they're per-site for good reasons: script running on one site shouldn't be allowed to probe the cache for arbitrary files from another site, for the same reason that the :visited CSS style needs to be hidden from script.

It might still make sense for just certain files, selectively, to opt out from per-site caching? Those might even turn out to be the same files that https://github.com/whatwg/html/issues/8143 is about.

(Sorry of this should be a PR - first time in this repo.)

Since reliance on CDNs for e.g. external Javascript files is bad, I recommend that all tags that have a 'src' attribute should also have an optional 'hash' attribute.

The author of the HTML file could then specify the e.g. SHA256 hash of the file required. The browser can then check if any file in it's cache matches that hash, and use a local copy, if available.

If there's a cache hit, this would save one HTTP request and would also allow the browser to use a file downloaded from some other URI, even with another filename, as long as the contents match.

This would, in turn, essentially resemble a distributed CDN for many often-used files, like the popular Javascript files and webfonts, etc.

It is now!

This is part of the second bullet point of https://github.com/whatwg/html/issues/7996, and its first nested point.

• I deleted support for the hook from fetch a classic script, fetch an external module script graph, and fetch an import() module script graph, since they were never called with custom steps.

cc @domenic

Here is another short update: I have looked at the address form structures of real world websites in 23 countries: https://github.com/battre/autocomplete-attribute-explainer/blob/main/country_analysis.md

I found this very enlightening but plan to re-do some of the work to convert this into a more machine processable format. I need to wrap my mind more around the question whether we can build an all encompassing solution or whether we need to build country specific solutions.

One observation/confirmation is that the autocomplete attribute does not work well for many countries.

Another observation is that there are a lot of snowflakes. E.g. in Hungary many websites split the name of a street (e.g. "Amphitheatre") from the type of the street ("Parkway", "Avenue", ...) into separate fields. If this is what delivery services ask for, I can see why websites implement it. But in this case today's autocomplete won't work. I am also convinced that this is a feature that we don't want to offer users in all countries.

I am currently thinking of having a machine readable catalog of address structures in different countries that could be shared across browsers. This catalog could contain a list of fields that are commonly used in different countries (this allows browsers to render address forms that meet the structures of countries and are more fine grained than what libaddressinput offers). The catalog could also contain rules for combining fields (in some countries you write "${street name} ${house number}" and in others "${house number} ${street name}"). If browsers agree on a set of rules, we could tell website authors which combinations can be filled on their site and which ones cannot.

Anyways... I am not dead and still exploring....

@domenic I have rebased this on top of the asynchronous completions removal, fixed the referrer handling to restore the old behavior and properly fixed the "perform the fetch" steps propagation.

I plan to continue working on #7996 (which obviously has conflicts with this PR), but I would still love a review of this one in parallel.

I think it indeed tied back to @isonmad's original proposal of embracing the memory leak in order to not expose GC. I also realize now that the script wouldn't run in the agent being shutdown as presumably we'd only dispatch the close event on the other side, which helps. (Though what if both sides go down?)

I'm not sure what the model with Web Locks is and whether that can still change. It does seem like that would indeed end up exposing similar things.

(The discussion at TPAC was quite brief and I somewhat regret bringing it up now, but on the other hand I learned a few things due to your reply...)

This generally sounds good to me. Thank you for working on it! cc @cdumez

I filed an issue for the CSS WG for those questions: https://github.com/w3c/csswg-drafts/issues/7802

Is this tested @Ms2ger?

Sorry, missed this thread. I don't think I have a strong opinion here. The difference with the ES spec is unfortunate, but WebIDL is already different for operations anyway.