whatwg
Repos
44

HTML Standard

6066
1865

Streams Standard

1235
133

Fetch Standard

1909
258

DOM Standard

1364
230

URL Standard

420
108

Encoding Standard

235
59

Events

opened issue
<link rel=preload> as attribute supports less than potential destination

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.

Created at 51 seconds ago
issue comment
Broken link to Latest Editor's Draft

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

Created at 15 minutes ago
closed issue
Broken link to Latest Editor's Draft

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

Peek 2022-09-29 14-08

Created at 20 minutes ago
issue comment
Broken link to Latest Editor's Draft

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.

Created at 20 minutes ago
opened issue
Broken link to Latest Editor's Draft

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

Peek 2022-09-29 14-08

Created at 24 minutes ago
pull request opened
Make PaintOptions example a better role model.

Do not have members that are both optional and nullable.

Fixes #1204.

Created at 39 minutes ago
opened issue
PaintOptions example should not have nullable optional fields

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

Created at 55 minutes ago
issue comment
aborting locked request body

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.

Created at 1 hour ago
issue comment
IDREF attributes reflection get out of sync

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.

Created at 2 hours ago
opened issue
<link> base URL should use document's base URL, not document's URL

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.

Created at 4 hours ago
issue comment
Add 'hash' attribute to elements that have a 'src' attribute in order to allow for URI independant cacheing

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.

Created at 5 hours ago
closed issue
Add 'hash' attribute to elements that have a 'src' attribute in order to allow for URI independant cacheing

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

Created at 5 hours ago
started
Created at 6 hours ago
issue comment
Add 'hash' attribute to elements that have a 'src' attribute in order to allow for URI independant cacheing

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.

Created at 6 hours ago
opened issue
Add 'hash' attribute to elements that have a 'src' attribute in order to allow for URI independant cacheing

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

Created at 11 hours ago
started
Created at 13 hours ago
started
Created at 16 hours ago
issue comment
Expose DOMException everywhere.

It is now!

Created at 16 hours ago
pull request opened
Explicitly pass around the "perform the fetch" hook

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

Created at 18 hours ago
issue comment
autocomplete attribute for street-address details

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

Created at 19 hours ago
issue comment
[ECMA-262 layering] Refactor import-related host hooks

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

Created at 20 hours ago
issue comment
Add onclose event to MessagePort

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

Created at 22 hours ago
issue comment
Iframes should inherit the base URL of the parent document in some cases

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

Created at 22 hours ago
issue comment
-webkit-background-size has behavioural differences to background-size

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

Created at 22 hours ago
issue comment
Expose DOMException everywhere.

Is this tested @Ms2ger?

Created at 23 hours ago
issue comment
Inconsistent enumerability on keys/values/entries and friends

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.

Created at 1 day ago