44
Events
Define eligibility for autofill
Introduces a necessary condition for a user-agent to autofill a collection of form controls:
A form control C is eligible for autofill if C's node document D is fully active and one of the following is true:
- Some element is focused and its node document's origin is the same origin as D's origin.
- The policy-controlled feature shared-autofill is enabled in document for D's origin.
- [ ] At least two implementers are interested (and none opposed):
- Chrome
- …
- [ ] Tests are written and can be reviewed and commented upon at:
- No Web Platform Tests were written because there is no JavaScript API for triggering Autofill. In particular, there is no API for storing or accessing data to be filled (e.g., a credit card).
- Chromium's integration tests are available.
- [ ] Implementation bugs are filed:
- As far as I know, all implementors do satisfy the aforementioned necessary condition, mostly trivially because they only fill controls that have the same node document. Chromium implements support for autofilling across frames in line with the necessary condition.
- Chromium: crbug.com/1187842, crbug.com/1201849
- Gecko: …
- WebKit: …
- Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): …
- Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): …
- [ ] MDN issue is filed: …
(See WHATWG Working Mode: Changes for more details.)
Rich Card Previews Metadata
If you add the following in the <head> of your HTML you will improve the resource(s). For example, the developers edition located at https://html.spec.whatwg.org/dev/ would use the below markup. NOTE: You may need to publish a 1200x1200 px .jpg of your logo for the image to display on social media rich card previews. The SVG may work - I've never tried an SVG.
<meta property="og:title" content="HTML: The Living Standard Edition for Web Developers"/>
<meta property="og:site_name" content="HTML: The Living Standard Edition for Web Developers">
<meta property="og:url" content="https://html.spec.whatwg.org/dev/" />
<meta property="og:image" content="https://resources.whatwg.org/logo.svg" />
<meta property="twitter:image:src" content="https://resources.whatwg.org/logo.svg">
<meta name="description" content="The focus of this specification is readability and ease of access. Unlike the full HTML Standard, this developer's edition removes information that only browser vendors need know. It is automatically produced from the full specification by our build tooling, and thus always in sync with the latest developments in HTML.">
<meta property="og:description" content="The focus of this specification is readability and ease of access. Unlike the full HTML Standard, this developer's edition removes information that only browser vendors need know. It is automatically produced from the full specification by our build tooling, and thus always in sync with the latest developments in HTML." />
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="1200">
<meta name="author" content="whatwg.org">
<meta name="twitter:card" content="summary">
<meta name="twitter:site" content="@WHATWG">
<meta name="twitter:creator" content="@WHATWG">
<meta property="og:type" content="website">
Images should refetch upon insertion, if the document's base URL has changed
I actually don't quite think it is. Perhaps this is kinda a subset of https://github.com/whatwg/dom/issues/61, but the main question here seems to be: should an image element internally store a snapshot of the base URL that it encountered upon first invocation of #update-the-image-data, to compare with the document's live base URL when the next relevant mutation is experienced?
Chrome and Firefox do this, but the spec and Safari do not. Spec & Safari's behavior (no base URL snapshot) is the simplest, and I'm leaning towards making Chrome do the same in https://chromium-review.googlesource.com/c/chromium/src/+/3311225, which I'd like to land with a WPT. @emilio what do you think about this? If I can land that CL in Chromium, I'll close this issue, but in the meantime it would be good to hear from FF.
Validation error at line 27 in html,6:
Validation error at line 27 in html,6: void showPopover(); ^
Validation error at line 27 in html,6:
Dupe of #8792
Validation error at line 27 in html,6:
Validation error at line 27 in html,6: void showPopover(); ^
Allow encoding of null values in `application/x-www-form-urlencoded`.
While I understand order of elements has semantic meaning, the degenerate case of && seems unimportant to me, and my question was what if any frameworks depend on those semantics.
Allow encoding of null values in `application/x-www-form-urlencoded`.
Do what? Interpret a plain & as (key: "", value: null)?
Not that I know of - that's why I said it would be a significant departure, but it is also a logical consequence of saying that a missing key-value delimiter means a null value.
Allow encoding of null values in `application/x-www-form-urlencoded`.
Does any framework in existence actually do that?
Allow encoding of null values in `application/x-www-form-urlencoded`.
If we treated pairs with no key-value delimiter as having a null value, I think we would also have to accept that in the URL http://example/foo&&&baz&&another, the key-value pairs are:
key: "foo", value: null
key: "", value: null
key: "", value: null
key: "baz", value: null
key: "", value: null
key: "another", value: null
In other words, we would not be able to skip strings of empty pair delimiters (&&&&). AFAICT, that skipping is widely agreed upon by other URL/querystring libraries, so this would be a significant departure.
To illustrate why we would need to do that:
I have an API which allows identifying each key-value pair by its position (i.e. an index) and supports index-based operations such as inserting pairs at a particular location, replacing a region of pairs, removing a particular pair, or changing the key/value of a particular pair.
Now consider the URL http://example/?foo&baz&another#frag. The API allows replacing the key component of the first pair:
url.queryParams.replaceKey(at: 0, with: "new_key")
// result: http://example/?new_key&baz&another#frag
// ^^^^^^^
But if you replace the key with the empty string, something interesting happens:
url.queryParams.replaceKey(at: 0, with: "")
// result: http://example/?=&baz&another#frag
// ^
Since empty strings of delimiters are usually skipped entirely, we must insert an = sign in order to preserve the fact that the first pair exists and its key is the empty string.
Currently this is fine, because the presence or not of the = sign does not change the value component. If we started to started to say that the presence of that delimiter is meaningful, then inserting this = would also change the pair's value. The only way around it would be allow the following result:
url.queryParams.replaceKey(at: 0, with: "")
// result: http://example/?&baz&another#frag
// ^
And to say that this initial & is actually a pair with (key: "", value: null).
Download API
- Option to prompt the user for a download location
Why? Not following the browser behavior is surprising.
A web developer might want to implement a "save as" button. But IMO it would be acceptable for a browser to prompt the user regardless of whether this parameter is specified.
What errors? Should it really care whether it's canceled by user or by browser (which is "error" but that should also cancel the stream)
We talked about this before. Multiple things could cause a download to fail. Lack of storage space, anti virus deleting a downloading file, the user deleting a downloading file, hardware I/O errors.
While I agree, downloads can already be initiated without interaction AFAIK. Has the situation changed?
I know, this limitation might cause problems for web developers and I'd rather not have it, but Mozilla tends to be finicky about standards so I want to stay on the safe side. Ideally we could discuss this with Mozilla devs and get approval though. Perhaps it's best to have it be a setting just like the autoplay setting.
I wonder this also applies to existing auto-initiated download mechanism. (A bit out of scope in that case)
I actually don't know. I might test this.
Download API
How would you add monitoring of progress to the API if the download function call returns a promise that doesn't resolve until download completion?
Sorry, I wasn't clear. I mean maybe resolve it if the browser shows the dialog. (But maybe that's not needed at, it's not like there's a long delay.)
What could also happen is that implementers implement the initial spec, but then delay implementing later additions (cough cough). It's better to do it right from the start.
Exactly why I want to start small. Implementers can have different opinions and doing everything at once can delay every process. No one wants such situation.
- Downloading of both fixed-length data and ReadableStreams
- Settable file name
Fair.
- Option to prompt the user for a download location
Why? Not following the browser behavior is surprising.
- Error reporting
What errors? Should it really care whether it's canceled by user or by browser (which is "error" but that should also cancel the stream)
- Progress reporting (including completion)
- Cancellation (more relevant to fixed-length downloads)
If you really need these, getting a proxy ReadableStream should work for non-stream data too.
- Downloads must be initiated by user interaction (like with playing media)
While I agree, downloads can already be initiated without interaction AFAIK. Has the situation changed?
- Repeated downloads can be blocked by the user agent (like with window.prompt and window.alert)
I wonder this also applies to existing auto-initiated download mechanism. (A bit out of scope in that case)
