![[Valid RSS]](images/valid-rss-rogers.png "Valid RSS")
This is a valid RSS feed.
This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.
<input type=text name=pronouns-other placeholder=… />
<p><a href="https://wpt.fyi/interop/html/rendering/non-replaced-elements/the ...
<p><a href="https://wpt.fyi/interop/html/rendering/non-replaced-elements/the ...
... t path forward for the community.</p>]]></content:encoded>
^
<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" > <channel> <title>The WHATWG Blog</title> <atom:link href="https://blog.whatwg.org/feed" rel="self" type="application/rss+xml" /> <link>https://blog.whatwg.org</link> <description>Please leave your sense of logic at the door, thanks!</description> <lastBuildDate>Wed, 25 Oct 2023 05:30:02 +0000</lastBuildDate> <language>en-US</language> <sy:updatePeriod> hourly </sy:updatePeriod> <sy:updateFrequency> 1 </sy:updateFrequency> <generator>https://wordpress.org/?v=6.4.4</generator> <item> <title>The URL Pattern Standard</title> <link>https://blog.whatwg.org/url-pattern-standard</link> <comments>https://blog.whatwg.org/url-pattern-standard#comments</comments> <dc:creator><![CDATA[Domenic Denicola]]></dc:creator> <pubDate>Wed, 25 Oct 2023 05:30:02 +0000</pubDate> <category><![CDATA[What's Next]]></category> <category><![CDATA[WHATWG]]></category> <guid isPermaLink="false">https://blog.whatwg.org/?p=13100</guid> <description><![CDATA[Welcome to the newest standard maintained by the WHATWG: the URL Pattern Standard! The URL Pattern Standard gives a generic pattern syntax for matching URLs, and extracting the parts from them. It is inspired by the path-to-regexp library, although it extends beyond paths to encompass all the parts of a URL. You can read more […]]]></description> <content:encoded><![CDATA[<p>Welcome to the newest standard maintained by the WHATWG: the <a href="https://urlpattern.spec.whatwg.org/">URL Pattern Standard</a>! The URL Pattern Standard gives a generic pattern syntax for matching URLs, and extracting the parts from them. It is inspired by the <a href="https://github.com/pillarjs/path-to-regexp">path-to-regexp</a> library, although it extends beyond paths to encompass all the parts of a URL. You can read more about the API <a href="https://developer.mozilla.org/en-US/docs/Web/API/URL_Pattern_API">on MDN</a>.</p> <p>The URL Pattern Standard joins us as a graduation from the <a href="https://wicg.io/">WICG</a>, where it was authored by Ben Kelly. As part of the move to becoming a Living Standard, Jeremy Roman and Shunya Shishido are joining Ben as editors to help maintain and evolve the standard.</p> <p>We see the URL Pattern Standard being adopted in many upcoming proposals, including <a href="https://github.com/WICG/nav-speculation/blob/main/triggers.md#document-rules">speculation rules</a>, <a href="https://github.com/WICG/compression-dictionary-transport#dictionary-options-header">compression dictionary transport</a>, and <a href="https://github.com/WICG/service-worker-static-routing-api#a-proposal">service worker static routing</a>. It has also seen adoption with implementations beyond web browsers, such as in <a href="https://deno.land/api@v1.37.2?s=URLPattern">Deno</a>, <a href="https://developers.cloudflare.com/workers/runtime-apis/web-standards/#urlpattern-api">Cloudflare Workers</a>, <a href="https://nextjs.org/docs/pages/api-reference/edge">Next.js Edge Runtime</a>, and <a href="https://www.netlify.com/blog/introducing-netlify-functions-2-0/">Netlify Functions</a>. We are excited to provide a home for this primitive going forward.</p>]]></content:encoded> <wfw:commentRss>https://blog.whatwg.org/url-pattern-standard/feed</wfw:commentRss> <slash:comments>1</slash:comments> </item> <item> <title>Retro-specifying fetch/performance</title> <link>https://blog.whatwg.org/retro-specifying-fetch-performance</link> <dc:creator><![CDATA[Noam Rosenthal]]></dc:creator> <pubDate>Thu, 17 Mar 2022 16:07:01 +0000</pubDate> <category><![CDATA[Processing Model]]></category> <guid isPermaLink="false">https://blog.whatwg.org/?p=13086</guid> <description><![CDATA[In the last year or so, my main task was to tackle some of the "specification technical debt" that had been accumulating over a few years, specifically at the crossroads of Fetch, performance APIs, and the HTML Standard. Monkey patching and hand waving When starting this work, the behaviors of some of the features relating […]]]></description> <content:encoded><![CDATA[<p>In the last year or so, my main task was to tackle some of the "specification technical debt" that had been accumulating over a few years, specifically at the crossroads of <cite><a href="https://fetch.spec.whatwg.org/">Fetch</a></cite>, <a href="https://github.com/w3c/web-performance">performance APIs</a>, and the <a href="https://html.spec.whatwg.org/multipage/">HTML Standard</a>.</p> <h3 class="wp-block-heading">Monkey patching and hand waving</h3> <p>When starting this work, the behaviors of some of the features relating to web performance were specified in the form of "monkey patching" — describing how another spec needs to be modified rather than modifying it; or "hand waving" — describing the expected behavior of a feature in general or vague terms.</p> <p>These ways of specifying have an advantage at early stages of specification, and allow moving fast without requiring consensus prematurely.</p> <p>However, as the specs mature and become widely used, these practices accumulate and come with a few costs.</p> <h3 class="wp-block-heading">Interoperability</h3> <p>Some details and flows may be too vaguely defined in the hand-waved description or monkey-patch. This, in turn, creates interoperability issues — one browser vendor may interpret a loosely defined phrase in some way, and another vendor in a different way.</p> <p>Example: <cite><a href="https://w3c.github.io/resource-timing/">Resource Timing</a></cite> specified that loading images should result in a resource timing entry. However, it was not specified (or tested) whether those entries should be added before or after the image's <code>load</code> event.</p> <h3 class="wp-block-heading">Bugs and security flaws</h3> <p>When having to spell out all the details of a previously loose spec, sometimes bugs and security/privacy flaws emerge. This has happened as part of this work more than once, for example in <a href="https://github.com/w3c/resource-timing/issues/260">w3c/resource-timing#260</a>: <cite>Resource Timing</cite> was exposing some of its properties for cross-origin resources, and by specifying it more rigorously we found that some properties that were exposed should actually be hidden.</p> <h3 class="wp-block-heading">The role of web platform tests</h3> <p>Of course, writing a few words into a standard doesn't fix interoperability issues or security flaws — it requires the two other pillars, tests and implementations. A big part of this debt-paying work involves adding missing coverage to web platform tests, and posting implementation bugs.</p> <h3 class="wp-block-heading">Work done so far</h3> <ul><li>The processing model of <cite><a href="https://w3c.github.io/resource-timing/">Resource Timing</a></cite> has been <a href="https://github.com/whatwg/fetch/pull/1185">incorporated into <cite>Fetch</cite></a>, including many edge cases relating to service workers and network errors.</li><li>The processing model of <cite><a href="https://w3c.github.io/navigation-timing/">Navigation Timing</a></cite> has been <a href="https://github.com/whatwg/html/pull/6536">incorporated into <cite>HTML</cite></a>.</li><li><cite><a href="https://w3c.github.io/page-visibility/">Page Visibility</a></cite> has been <a href="https://github.com/whatwg/html/pull/7238">folded into <cite>HTML</cite></a>.</li><li>The behavior of <code><link rel=preload></code> and how preloads are cached is now <a href="https://github.com/whatwg/html/pull/7260">rigorously defined</a>.</li><li><a href="https://github.com/whatwg/html/pull/7339"><code>timeOrigin</code> computation</a> is defined in the <cite>HTML</cite> and <cite><a href="https://github.com/w3c/ServiceWorker/pull/1621">Service Workers</a></cite> specs.</li><li>The <a href="https://github.com/whatwg/html/pull/7166">deadline mechanism</a> of <a href="https://w3c.github.io/requestidlecallback/"><code>requestIdleCallback</code></a> is now clearly defined.</li><li>Patched <a href="https://github.com/w3c/csswg-drafts/pull/6715">multiple CSS specs</a> to define how they fetch resources and report timing.</li><li>Process <a href="https://github.com/whatwg/html/pull/7622"><code>Link</code> headers</a>.</li></ul> <h3 class="wp-block-heading">Work in progress</h3> <ul><li>Additional work on <a href="https://github.com/whatwg/html/pull/7691"><code>Link</code> headers</a>.</li><li><a href="https://github.com/whatwg/html/pull/7693">Clearly defining <code><link rel=prefetch></code></a> — this is a bit tricky as browsers treat prefetch in different ways.</li><li>Rigorous specification for <a href="https://github.com/w3c/server-timing/pull/87"><cite>Server Timing</cite></a>.</li><li>Define <a href="https://github.com/whatwg/fetch/pull/1411">CSP interaction with preload</a>.</li><li>Specifying fetching <a href="https://github.com/whatwg/html/pull/7655">range requests</a> (for media).</li><li>Finish the <a href="https://github.com/whatwg/html/issues/6542">HTML integration for resource timing</a>, which requires that all reporters of resource timing do so at the appropriate time.</li><li>Specify <a href="https://github.com/whatwg/html/pull/7675">early hint</a> headers.</li><li>Attempt to define the <a href="https://github.com/whatwg/html/issues/6110">memory cache</a>.</li></ul> <h3 class="wp-block-heading">Retroactive consensus</h3> <p>Some of the features in question are already shipped, and vendors took liberties to interpret them in different ways. This raises a challenge of achieving <em>retroactive consensus</em>. Vendors might have good reasons to do things differently, but the differences make it difficult for web developers to write interoperable code. In the area of performance APIs, interoperability issues mean that performance measurements or hints might create different results across browsers.</p> <p>Because the feature is already shipped, achieving consensus retroactively means that browser vendors would have to go back to their implementations and change things, which apart from the work involved could potentially make things suboptimal for some existing cases. Is interoperability worth it? That's a good question and the answer is dynamic.</p> <p>A current example of this is the attempts to specify <a href="https://github.com/w3c/resource-hints/issues/86">prefetch</a>. It is a relatively old feature that is implemented differently across browsers and those two facts make it difficult to spec after the fact. Another bigger example is the <a href="https://github.com/w3c/navigation-timing/issues/160">discussion about navigation start time being the zero point</a>, which is a cross-origin information leak, but where fixing it would have big implications.</p> <h3 class="wp-block-heading">What's next</h3> <p>The technical debt in the fetch/HTML/performance crossroads is a little smaller than before, but still far from being paid. Apart from the in-progress pull requests, some of the remaining debt is tracked <a href="https://github.com/w3c/web-performance/issues/38">here</a>.</p> <h3 class="wp-block-heading">How you could help</h3> <p>Apart from the retroactive consensus challenge, an additional challenge is involving more people in the conversation. You can help by reading the issues in progress, forming opinions, finding flaws, posting what you find, proactively becoming involved. If you're not part of the conversation already and are curious, follow the links in this post, read, ask questions, and make suggestions. We'd love to hear from you!</p> <p></p>]]></content:encoded> </item> <item> <title>New Living Standards</title> <link>https://blog.whatwg.org/new-living-standards-2021</link> <dc:creator><![CDATA[Domenic Denicola]]></dc:creator> <pubDate>Wed, 01 Dec 2021 19:25:15 +0000</pubDate> <category><![CDATA[What's Next]]></category> <category><![CDATA[WHATWG]]></category> <guid isPermaLink="false">https://blog.whatwg.org/?p=13071</guid> <description><![CDATA[The last time we introduced a new Living Standard was Infra, in 2016. This year has seen a flurry of activity, with four new standards joining the WHATWG! The Web IDL Standard defines the interface language and JavaScript mapping for all web platform APIs. It migrated to the WHATWG from its old location, on the […]]]></description> <content:encoded><![CDATA[<p>The last time we introduced a new Living Standard was <a href="https://blog.whatwg.org/infra">Infra, in 2016</a>. This year has seen a flurry of activity, with four new standards joining the WHATWG!</p> <p>The <strong><a href="https://webidl.spec.whatwg.org/">Web IDL Standard</a></strong> defines the interface language and JavaScript mapping for all web platform APIs. It migrated to the WHATWG from its old location, on the personal GitHub page of its original editor Cameron McCormack. Thanks to Cameron for his many years of stewardship, and thanks to the current editors Edgar Chen and Tiancheng "Timothy" Gu for their help in the move!</p> <p>The <strong><a href="https://testutils.spec.whatwg.org/">Test Utils Standard</a></strong> defines APIs that are not exposed on the open web by default, but are specifically useful in testing web browser functionality. So far it defines the <code>testUtils.gc()</code> method, allowing us to test garbage collection-dependent APIs. James Graham is the editor.</p> <p>The <strong><a href="https://websockets.spec.whatwg.org/">WebSockets Standard</a></strong> consolidates content that was formerly spread across the <a href="https://html.spec.whatwg.org/multipage/">HTML Standard</a> and the <a href="https://fetch.spec.whatwg.org/">Fetch Standard</a>. This new home will provide a natural place for standardizing the <a href="https://github.com/ricea/websocketstream-explainer"><code>WebSocketStream</code></a> API, which integrates WebSockets with <a href="https://streams.spec.whatwg.org/">streams</a>. Adam Rice is the editor.</p> <p>Finally, the <strong><a href="https://github.com/whatwg/sg/issues/176">File System Standard</a></strong> will specify an API for an origin-private filesystem, drawn from <a href="https://wicg.github.io/file-system-access/#sandboxed-filesystem">part of the existing File System Access specification</a> as well as the <a href="https://github.com/WICG/file-system-access/blob/main/AccessHandle.md">AccessHandle proposal</a>. (The portions of the File System API specification for <a href="https://wicg.github.io/file-system-access/#local-filesystem">accessing the local file system</a> will remain in incubation, until they gather multi-implementer interest.) Marijn Kruisselbrink will be the editor.</p> <p>We're happy to see such excitement about working in the WHATWG, and will strive to continue to provide a welcoming community where new features can be developed or existing incubations can graduate. We hope you enjoy these new Living Standards. As always, feel free to join us on GitHub to discuss improvements and additions. And if there are more specifications that would like to become WHATWG Living Standards, please <a href="https://whatwg.org/chat">get in touch</a>!</p>]]></content:encoded> </item> <item> <title>Newline normalizations in form submission</title> <link>https://blog.whatwg.org/newline-normalizations-in-form-submission</link> <dc:creator><![CDATA[Andreu Botella]]></dc:creator> <pubDate>Thu, 27 May 2021 15:05:15 +0000</pubDate> <category><![CDATA[Browsers]]></category> <category><![CDATA[Forms]]></category> <category><![CDATA[WHATWG]]></category> <guid isPermaLink="false">https://blog.whatwg.org/?p=13027</guid> <description><![CDATA[In form submissions, form values containing newlines get normalized to CRLF. But that newline normalization runs deeper than might be thought. Here is a deep dive on the recent spec changes on that area.]]></description> <content:encoded><![CDATA[<p>If you work with form submissions, you might have noticed that form values containing newlines are normalized to CRLF, no matter whether the DOM value had LF or CR instead:</p> <pre class="wp-block-code"><code><form action="./post" method="post" enctype="application/x-www-form-urlencoded"> <input type="hidden" name="hidden" value="a&#x0D;b&#x0A;c&#x0D;&#x0A;d" /> <input type="submit" /></form> <script> // Checking that the DOM has the correct newlines and the normalization // happens during the form submission. const hiddenInput = document.querySelector("input[type=hidden]"); console.log("%s", JSON.stringify(hiddenInput.value)); // "a\rb\nc\r\nd"</script></code></pre> <pre class="wp-block-code"><code>hidden=a%0D%0Ab%0D%0Ac%0D%0Ad</code></pre> <p>But although it might seem simple on the surface, newline normalization in form submissions is a topic that runs deeper than I thought, with bugs in the spec and differences across browsers. This post goes through what the spec used to do, what browsers (used to) implement, and how we went about fixing it.</p> <h3 class="wp-block-heading" id="form-submission-basics">First, some background on form submission</h3> <p>The data to submit from a form is modeled as an <a href="https://xhr.spec.whatwg.org/#concept-formdata-entry-list">entry list</a> – entries being pairs of names (strings) and values (either strings or <a href="https://w3c.github.io/FileAPI/#file-section"><code>File</code></a> objects). This is a list rather than a map because a form can have multiple values for each name – which is is how <code><input type="file" multiple></code> and <code><select multiple></code> work – and their relative order with the rest of form entries matters.</p> <p>The algorithm that does the job of going through every submittable element associated with a particular form and collecting their corresponding form entries is the <a href="https://html.spec.whatwg.org/commit-snapshots/4cfb2b76873e23e8a8ac762f5ddaa0a6630b3e6e/#constructing-form-data-set">"construct the entry list"</a> algorithm. This algorithm does what you'd expect – discard disabled controls and buttons not pressed, and then for each control it calls the <a href="https://html.spec.whatwg.org/commit-snapshots/4cfb2b76873e23e8a8ac762f5ddaa0a6630b3e6e/#append-an-entry">"append an entry"</a> algorithm, which used to replace any newlines in the entry name and value (if that value is a string) with CRLF before appending the entry.</p> <p>"Construct the entry list" is called early into the form submission algorithm, and the resulting entry list is then passed to the encoding algorithm for the corresponding enctype. Since only the <code>multipart/form-data</code> enctype supports uploading files, the algorithms for both <code>application/x-www-form-urlencoded</code> and <code>text/plain</code> encode the value's filename instead.</p> <h3 class="wp-block-heading" id="first-signs-of-trouble">First signs of trouble</h3> <p>My first foray into the encoding of form payloads was in defining precisely how entry names (and filenames of file entry values) had to be escaped in <code>multipart/form-data</code> payloads, and since LF and CR have to be percent escaped, newlines came up during testing.</p> <p>One thing I noticed is that, if you have newlines inside a filename – yes, that is something you can do – they're normalized differently than for an entry name or a string value.</p> <pre class="wp-block-code"><code><form id="form" action="./post" method="post" enctype="multipart/form-data"> <input type="hidden" name="hidden a&#x0D;b" value="a&#x0D;b" /> <input id="fileControl" type="file" name="file a&#x0D;b" /></form> <script> // A file with filename "a\rb", empty contents, and "application/octet-stream" // MIME type. const file = new File([], "a\rb"); const dataTransfer = new DataTransfer(); dataTransfer.items.add(file); document.getElementById("fileControl").files = dataTransfer.files; document.getElementById("form").submit();</script></code></pre> <p>Here is the resulting <code>multipart/form-data</code> payload in Chrome and Safari (newlines are always CRLF):</p> <pre class="wp-block-code"><code>------WebKitFormBoundaryjlUA0jn3NUYxIh2AContent-Disposition: form-data; name="hidden a%0D%0Ab" ab------WebKitFormBoundaryjlUA0jn3NUYxIh2AContent-Disposition: form-data; name="file a%0D%0Ab"; filename="a%0Db"Content-Type: application/octet-stream ------WebKitFormBoundaryjlUA0jn3NUYxIh2A--</code></pre> <p>And this is in Firefox 88 (the current stable version as of this writing):</p> <pre class="wp-block-code"><code>-----------------------------26303884030012461673680556885Content-Disposition: form-data; name="hidden a b" ab-----------------------------26303884030012461673680556885Content-Disposition: form-data; name="file a b"; filename="a b"Content-Type: application/octet-stream -----------------------------26303884030012461673680556885--</code></pre> <p>As you can see, Firefox substitutes a space for any newlines (CR, LF or CRLF) in the <code>multipart/form-data</code> encoding of entry names and filenames, rather than percent-encoding them as do Chrome and Safari. This behavior was made illegal in the spec in pull request <a href="https://github.com/whatwg/html/pull/6282">#6282</a>, but it couldn't be fixed in Firefox until the spec decided on a normalization behavior. In the case of values, Firefox normalizes to CRLF as the other browsers do.</p> <p>As for Chrome and Safari, here we see that newlines in entry names and string values are normalized to CRLF, but filenames are not normalized. From the entry list construction algorithm as described above, this makes sense because entry values are only normalized to CRLF <em>when they are strings</em> – files are unchanged, and so are their filenames.</p> <p>Except that, if you change the form's enctype in the above example to <code>application/x-www-form-urlencoded</code>, you get this in every browser:</p> <pre class="wp-block-code"><code>hidden+a%0D%0Ab=a%0D%0Ab&file+a%0D%0Ab=a%0D%0Ab</code></pre> <p>Since <code>multipart/form-data</code> is the only enctype that allows file uploads, other enctypes use their filenames instead. But here it seems like every browser is CRLF-normalizing the filenames, even though in the spec that substitution happens long after constructing the entry list.</p> <h3 class="wp-block-heading" id="formdata-and-fetch">Normalizations with <code>FormData</code> and <code>fetch</code></h3> <p>The <a href="https://xhr.spec.whatwg.org/#interface-formdata"><code>FormData</code></a> class started out as a way to send <code>multipart/form-data</code> form payloads through the <code>XMLHttpRequest</code> and <code>fetch</code> APIs without having to generate that payload in JavaScript. As such, <code>FormData</code> instances are basically a JS-accessible wrapper over an entry list.</p> <p>So let's try the same with <code>FormData</code>:</p> <pre class="wp-block-code"><code>const formData = new FormData();formData.append("hidden a\rb", "a\rb");formData.append("file a\rb", new File([], "a\rb")); // FormData objects in fetch will always be serialized as multipart/form-data.await fetch("./post", { method: "POST", body: formData });</code></pre> <p>Safari sends the same form payload as above, with names and values normalized to CRLF, and so does Firefox 88 with values normalized to CRLF (and names and values having their newlines escaped as spaces). But Chrome keeps names, filenames and values unnormalized (here the <span style="font-weight: bold">?</span> character stands for CR):</p> <pre class="wp-block-code"><code>------WebKitFormBoundarySMGkMfD8mVOnmGDPContent-Disposition: form-data; name="hidden a%0Db" a<span style="font-weight: bold">?</span>b------WebKitFormBoundarySMGkMfD8mVOnmGDPContent-Disposition: form-data; name="file a%0Db"; filename="a%0Db"Content-Type: application/octet-stream ------WebKitFormBoundarySMGkMfD8mVOnmGDP--</code></pre> <p>Since <code>FormData</code> is just a wrapper over an entry list, and <code>fetch</code> simply calls the <code>multipart/form-data</code> encoding algorithm, no normalizations should take place. So it looks like Chrome was following the spec here, while Firefox and Safari were apparently doing some newline normalization (for Firefox, on string values only) at the time of serializing as <code>multipart/form-data</code>.</p> <p>With <code>FormData</code> you can also investigate what the "construct the entry list" algorithm does, since if you pass a <code><form></code> element to the <code>FormData</code> constructor, it will call that algorithm outside of a form submission context, and let you inspect the resulting entry list.</p> <pre class="wp-block-code"><code><form id="form"> <input type="hidden" name="a&#x0D;b" value="a&#x0D;b" /></form> <script> const formData = new FormData(document.getElementById("form")); for (const [name, value] of formData.entries()) { console.log("%s %s", JSON.stringify(name), JSON.stringify(value)); } // Firefox and Safari print: "a\rb" "a\rb" // Chrome prints: "a\r\nb" "a\r\nb" // These results don't depend on the form's enctype.</script></code></pre> <p>So it seems like Firefox and Safari are not normalizing as they construct the entry list, and instead normalize names and values at the time that they encode the form into an enctype. In particular, since the <code>application/x-www-form-urlencoded</code> and <code>text/plain</code> enctypes don't allow file uploads, file entry values are substituted with their filenames <em>before</em> the normalization. Entry lists that aren't created from the "construct an entry list" algorithm get normalized all the same.</p> <p>Chrome instead follows the specification (as it used to be) in normalizing in "construct an entry list" and not normalizing later, even for entry lists created through other means. But that doesn't explain why filenames in the <code>application/x-www-form-urlencoded</code> and <code>text/plain</code> enctypes are normalized. Does Chrome also have an additional normalization layer?</p> <h3 class="wp-block-heading" id="formdata-event">Investigating late normalization with the <code>formdata</code> event</h3> <p>It would be great to investigate in more detail what Chrome and other browsers do <em>after</em> constructing the entry list. Since the entry list construction already normalizes entries, any further normalizations that might happen further down the line are obscured in the common case.</p> <p>In the case of <code>multipart/form-data</code>, we can test this because using a <code>FormData</code> object with <code>fetch</code> doesn't invoke "construct an entry list", and so can see what happens to unnormalized entries. For other enctypes there is no way to create an entry list that doesn't go through "construct an entry list", but as it turns out, the "construct an entry list" algorithm itself offers two ways to end up with unnormalized entries: <a href="https://html.spec.whatwg.org/multipage/custom-elements.html#form-associated-custom-elements">form-associated custom elements</a> (only implemented in Chrome so far) and the <a href="https://html.spec.whatwg.org/multipage/indices.html#event-formdata"><code>formdata</code> event</a> (implemented in Chrome and Firefox). Here we'll only be covering the latter, since their results are equivalent.</p> <p>One thing I skipped when I covered the "construct an entry list" algorithm above is that, at the end of the algorithm, after all entries corresponding to controls have been added to the entry list, a <code>formdata</code> event is fired on the relevant <code><form></code> element. This event has a <code>formData</code> attribute which allows you not only to inspect the entry list at that point, but to modify it.</p> <pre class="wp-block-code"><code><form id="form" action="./post" method="post" enctype="application/x-www-form-urlencoded"> <!-- Empty --></form> <script> const form = document.getElementById("form"); form.addEventListener("formdata", (evt) => { evt.formData.append("string a\rb", "a\rb"); evt.formData.append("file a\rb", new File([], "a\rb")); }); form.submit();</script></code></pre> <p>For both Chrome and Firefox (not Safari because it doesn't support the <code>formdata</code> event), trying this with the <code>application/x-www-form-urlencoded</code> enctype gets you a normalized result:</p> <pre class="wp-block-code"><code>string+a%0D%0Ab=a%0D%0Ab&file+a%0D%0Ab=a%0D%0Ab</code></pre> <p>Firefox shows the same normalizations for the <code>text/plain</code> enctype; Chrome instead normalizes only filenames, not names and values. And with <code>multipart/form-data</code> we get the same result as with <code>fetch</code> and <code>FormData</code> above: Chrome doesn't normalize anything, Firefox normalizes string values (with names and filenames being replaced with spaces).</p> <p>So in short:</p> <ul><li>For <code>application/x-www-form-urlencoded</code>, all browsers perform an additional newline normalization at the moment of serializing the form payload, whether or not they normalize when constructing the entry list. Note that newline normalizations are idempotent, so normalizing an already normalized string doesn't change it.</li><li>For <code>text/plain</code>, Firefox and Safari seem to act just like for <code>application/x-www-form-urlencoded</code>. Chrome instead only normalizes filenames, probably at the same time as files are being substituted with their filenames.</li><li>For <code>multipart/form-data</code>, Chrome doesn't normalize anything. Safari instead normalizes names and string values, but not filenames. Firefox does the same as Safari for values, but replaces any newlines in names and filenames with a space.</li></ul> <p>Remember that these differences across browsers don't really affect the encoding of normal forms, they only matter if you're using <code>FormData</code> with <code>fetch</code>, the <code>formdata</code> event, or form-associated custom elements.</p> <h3 class="wp-block-heading" id="spec-fixes"><a href="https://gist.github.com/andreubotella/bb62bfe0489baa5fe9a1155e0b37f92d#fixing-the-spec"></a>Fixing the spec</h3> <p>So which behavior do we choose? Firefox replacing newlines in <code>multipart/form-data</code> names and values with a space is illegal as per <a href="https://github.com/whatwg/html/pull/6282">PR #6282</a>, but anything else is fair game.</p> <p>For <code>text/plain</code>, we have Firefox and Safari behaving in the same way, and Chrome disagreeing. Since <code>text/plain</code> cannot represent inputs unambiguously, is little used in any case, and you would need either form-associated custom elements or to use the <code>formdata</code> event to see a difference, it seems extremely unlikely that there is web content that depends on either case. So it makes more sense to treat <code>text/plain</code> just like <code>application/x-www-form-urlencoded</code> and normalize names, filenames and values.</p> <p>For <code>multipart/form-data</code>, there is the added compatibility risk that you can observe this case by using <code>FormData</code> and <code>fetch</code>, so it's more likely to cause webcompat issues, no matter whether we went with Safari's or Chrome's behavior. In the end we choose to go with Safari's, in order to be consistent at normalizing all enctypes – although the <code>multipart/form-data</code> has to be different in not normalizing filenames, of course.</p> <p>So in pull request <a href="https://github.com/whatwg/html/pull/6287">#6287</a> we fixed this by:</p> <ol><li>Adding <a href="https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#converting-an-entry-list-to-a-list-of-name-value-pairs">a new algorithm</a> that runs before the <code>application/x-www-form-urlencoded</code> and <code>text/plain</code> serializers. This algorithm first extracts a filename from the entry value, if it's a file, and then CRLF-normalizes both the name and value.</li><li>We changed the <a href="https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#multipart-form-data"><code>multipart/form-data</code> encoding algorithm</a> to have a first step that CRLF-normalizes names and string values, leaving file values intact.</li></ol> <h3 class="wp-block-heading" id="revisiting-early-normalization"><a href="https://gist.github.com/andreubotella/bb62bfe0489baa5fe9a1155e0b37f92d#do-we-need-the-early-normalization-though"></a>Do we need the early normalization though?</h3> <p>At the time that we decided the above changes to the spec, I still thought that the spec's (and Chrome's) behavior of normalizing in "construct the entry list" was correct. But later on I realized that, once we have the late normalizations mentioned above, the early normalization in "construct the entry list" doesn't matter for form submission, since the late normalizations do everything the early one can do and more. The only way you could observe whether that early normalization is present or not is through the <code>FormData</code> constructor. So it would make sense to remove that early normalization and standardize on Firefox and Safari's behavior here, as we did in pull request <a href="https://github.com/whatwg/html/pull/6624">#6624</a>.</p> <p>One kink remained, though: <code><textarea></code> elements support the <a href="https://html.spec.whatwg.org/#attr-textarea-wrap"><code>wrap="hard"</code></a> attribute, which adds linebreaks into the submitted value corresponding to how the text is linewrapped in the UI. In the spec, this is done through the <a href="https://html.spec.whatwg.org/commit-snapshots/4cfb2b76873e23e8a8ac762f5ddaa0a6630b3e6e/#textarea-wrapping-transformation">"textarea wrapping transformation"</a>, which takes the textarea's <a href="https://html.spec.whatwg.org/#concept-textarea-raw-value">"raw value"</a>, normalizes it to CRLF, and when <code>wrap="hard"</code>, adds CRLF newlines to wrap the contents. But if you test this on Safari, all newlines (both normalized and added) are LF – and Firefox currently doesn't implement <code>wrap="hard"</code>, but it does normalize newlines to LF. So should this be changed?</p> <p>I thought it was better to align on Firefox's and Safari's behavior, especially since this could simplify the mess that is the difference between "raw value", "API value" and "value" for <code><textarea></code> in the spec. Chrome disagreed at first – <a href="https://github.com/whatwg/html/issues/6647#issuecomment-834168065">but as it turns out</a>, Chrome's implementation of the textarea wrapping transformation normalizes to LF, and it's only the normalization in "construct an entry list" that normalizes those newlines to CRLF. So Chrome would align with Firefox and Safari in that area by just removing the early normalization.</p> <p>Pull request <a href="https://github.com/whatwg/html/pull/6697">#6697</a> fixes this issue with <code><textarea></code> in the spec, and the follow-up issue <a href="https://github.com/whatwg/html/issues/6662">#6662</a> will take care of simplifying the textarea wrapping transformation in the spec, as well as ensure that it matches implementations.</p> <h3 class="wp-block-heading" id="implementation-fixes"><a href="https://gist.github.com/andreubotella/bb62bfe0489baa5fe9a1155e0b37f92d#implementation-fixes"></a>Implementation fixes</h3> <p>After those three pull requests, the current spec mandates that no normalization happen in "construct the entry list", and that the entry lists to be encoded with some enctype go through a transformation that depends on the enctype:</p> <ul><li>For <code>application/x-www-form-urlencoded</code> and <code>text/plain</code>, this transformation first replaces file values with their filenames, and then CRLF-normalizes names and values.</li><li>For <code>multipart/form-data</code>, this transformation CRLF-normalizes names and string values, but not filenames.</li></ul> <p>Safari implements the current spec behavior, and so doesn't need any fixes as a result of these spec changes. However, when working on them I noticed that Safari had a preexisting bug in that it wasn't converting entry names and string values <a href="https://infra.spec.whatwg.org/#javascript-string-convert">into scalar value strings</a> in the "construct an entry list" algorithm, which could lead to <code>FormData</code> objects containing <code>DOMString</code> values despite the WebIDL declaration. What's more, those lone surrogates would remain there until the time of serializing the form, and might show up in the form payload as <a href="https://simonsapin.github.io/wtf-8">WTF-8</a> surrogate byte sequences. This is <a href="https://bugs.webkit.org/show_bug.cgi?id=225299">bug 225299</a>.</p> <p>Firefox acts much like Safari, except in that it escapes newlines in <code>multipart/form-data</code> names and filenames as spaces rather than CRLF-normalizing in the case of names and then percent-encoding. With the normalization now defined in the spec, this could now be changed. This is <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1686765">bug 1686765</a>. I additionally also found the same bug as Safari with not converting strings into scalar value strings, except in this case the normalization did take place when encoding (<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1709066">bug 1709066</a>). Both issues are now fixed in Firefox Nightly and will ship on Firefox 90.</p> <p>Finally, Chrome would need to remove the normalization it performs in "construct an entry list", update the normalization it performs on the <code>text/plain</code> enctype to cover not only filenames but also names and values, and add an additional normalization for <code>multipart/form-data</code> names and values. This is covered in <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=1167095">issue 1167095</a>. Since Chrome is the browser that needs the most changes as a result of these spec changes, and they are understandably concerned with backwards compatibility, these fixes are expected to ship behind a flag so they can be quickly rolled back in case of trouble.</p> <h3 class="wp-block-heading" id="conclusion">Conclusion</h3> <p>Although form submission is not necessarily seen as an easy topic, newline normalization in that context might not seem like such a big deal from the outside. But in a platform like the web, where spec and implementation decisions can easily snowball into compatibility concerns, even things that might look simple might have a history that makes standardizing on one behavior hard.</p>]]></content:encoded> </item> <item> <title>Update from the Steering Group</title> <link>https://blog.whatwg.org/update-from-the-steering-group</link> <dc:creator><![CDATA[Anne van Kesteren]]></dc:creator> <pubDate>Thu, 29 Apr 2021 06:41:19 +0000</pubDate> <category><![CDATA[WHATWG]]></category> <guid isPermaLink="false">https://blog.whatwg.org/?p=13019</guid> <description><![CDATA[A couple things the Steering Group has been working on recently reached a new milestone and seemed noteworthy enough to highlight to the wider WHATWG community. As you may know the WHATWG formally collaborates with W3C on the DOM and HTML standards. In practice there is also a significant overlap in membership and sharing of […]]]></description> <content:encoded><![CDATA[<p>A couple things the Steering Group has been working on recently reached a new milestone and seemed noteworthy enough to highlight to the wider WHATWG community.</p> <p>As you may know the WHATWG formally collaborates with W3C on the DOM and HTML standards. In practice there is also a significant overlap in membership and sharing of ideas. We recently reached a new milestone in this endeavor as <a href="https://www.w3.org/blog/2021/01/whatwg-review-drafts-of-html-and-dom-endorsed-as-w3c-recommendations/">W3C has marked Review Drafts of the DOM and HTML standards as W3C Recommendations</a>. We’d like to take this opportunity to thank the W3C community for their cooperation on these important web standards.</p> <p>In response to community feedback we clarified “work in the field of web technologies” in the <a href="https://participate.whatwg.org/agreement">Contributor and Workstream Participant Agreement</a>. And while for the most part Individuals and Entities alike have had no trouble signing up and contributing en masse to the WHATWG, we added the possibility for individuals to be invited. This has some similarities to W3C’s Invited Expert program and will be used for a select few cases where this might be worthwhile.</p> <p>Finally, to make it easier to embed code from our standards into software, the <a href="https://opensource.org/licenses/BSD-3-Clause">BSD 3-Clause license</a> can now be used for that purpose as stipulated in the <a href="https://whatwg.org/ipr-policy">IPR Policy</a>.</p> <p>Thanks to everyone for their continued feedback on these matters over the years!</p>]]></content:encoded> </item> <item> <title>Considering accessibility</title> <link>https://blog.whatwg.org/considering-accessibility</link> <dc:creator><![CDATA[Carolyn MacLeod]]></dc:creator> <pubDate>Tue, 21 Jan 2020 21:00:00 +0000</pubDate> <category><![CDATA[Elements]]></category> <category><![CDATA[accessibility]]></category> <category><![CDATA[aria]]></category> <guid isPermaLink="false">https://blog.whatwg.org/?p=12994</guid> <description><![CDATA[Sometimes, new authors need a gentle reminder to think about accessibility when designing and writing web pages and apps. Experienced authors need a quick way to look up the allowed ARIA roles, states and properties for each HTML element. Browser and Assistive Technology (AT) implementers need quick access from an HTML element to its platform […]]]></description> <content:encoded><![CDATA[<p>Sometimes, new authors need a gentle reminder to think about accessibility when designing and writing web pages and apps. Experienced authors need a quick way to look up the <a href="https://w3c.github.io/html-aria/#allowed-aria-roles-states-and-properties">allowed ARIA roles, states and properties</a> for each HTML element. Browser and Assistive Technology (AT) implementers need quick access from an HTML element to its <a href="https://w3c.github.io/html-aam/#dfn-accessibility-api">platform accessibility API</a>.</p> <p>For a look at how these needs translated into the new <a href="https://html.spec.whatwg.org/multipage/dom.html#concept-element-accessibility-considerations">Accessibility considerations</a> section for each element, please see "<a href="https://www.24a11y.com/2019/pouring-aria-into-the-html-element-specs/">POURing ARIA into the HTML element specs</a>" over at <a href="https://www.24a11y.com/">24 Accessibility</a>.</p>]]></content:encoded> </item> <item> <title>Focusing on focus</title> <link>https://blog.whatwg.org/focusing-on-focus</link> <comments>https://blog.whatwg.org/focusing-on-focus#comments</comments> <dc:creator><![CDATA[Rakina Zata Amni]]></dc:creator> <pubDate>Wed, 16 Oct 2019 08:09:26 +0000</pubDate> <category><![CDATA[Browser API]]></category> <category><![CDATA[DOM]]></category> <category><![CDATA[Forms]]></category> <category><![CDATA[Processing Model]]></category> <guid isPermaLink="false">https://blog.whatwg.org/?p=12969</guid> <description><![CDATA[Focus behavior in HTML had been under-specified for the past few years, and it was also quite confusing due to a variety of subtle differences between focusing methods, UA-specific behaviors, relation to the tabindex attribute, relations to shadow DOM, etc. A few months ago Domenic filed a meta-bug that contains a list of things to […]]]></description> <content:encoded><![CDATA[<p>Focus behavior in HTML had been under-specified for the past few years, and it was also quite confusing due to a variety of subtle differences between focusing methods, UA-specific behaviors, relation to the <code>tabindex</code> attribute, relations to shadow DOM, etc.</p> <p>A few months ago Domenic filed a <a href="https://github.com/whatwg/html/issues/4607">meta-bug</a> that contains a list of things to fix so that we would have a good foundation for further additions to focus-related stuff, and to hopefully make focus in HTML make sense to browser engineers and web authors!</p> <h3>Types of focus</h3> <p>You may know that you can focus on stuff by clicking on them, tabbing, or calling <code>focus()</code> on it — but did you know that things might be focusable with one method but not with others? Domenic and Mu-An made <a href="https://boom-bath.glitch.me/tabindex.html">a giant interactive list of HTML elements</a> to showcase how they react to different methods of focusing, and can be tested from various browsers to show the difference between them.</p> <p>To reflect the varying behaviors of focus in various UAs in the spec, we classified focusability into three types: “programmatically focusable”, “click focusable”, and “sequentially focusable”.</p> <p>If an element is <strong><a href="https://html.spec.whatwg.org/multipage/interaction.html#focusable">programmatically focusable</a></strong>, it will get focused when calling the <code>focus()</code> method on it or when putting an <code>autofocus</code> attribute on the element. In all platforms, all elements that are either click focusable or sequentially focusable are also programmatically focusable, so “programmatically focusable” is interchangeable with “focusable”.</p> <p>If an element is <strong><a href="https://html.spec.whatwg.org/multipage/interaction.html#click-focusable">click focusable</a></strong>, the element will get focused when it’s clicked. This has the same set of elements as “programmatically focusable” in most UAs/platforms. A notable exception is Safari where non-editable form controls (checkboxes, etc.) are not click focusable by default.</p> <p>If an element is <strong><a href="https://html.spec.whatwg.org/multipage/interaction.html#sequentially-focusable">sequentially focusable</a></strong>, the element can be focused through “tabbing” — in most UAs this means pressing <kbd>Tab</kbd>/<kbd>Shift+Tab</kbd> (and in Safari, <kbd>Option+Tab</kbd> too!).</p> <p>Previously the spec didn’t clearly differentiate “programmatically focusable” and “sequentially focusable”, didn’t even mention “click focusable”, and used the “tabindex focus flag” concept which was slightly confusing due to its relations with the tabindex attribute. So we updated it in <a href="https://github.com/whatwg/html/pull/4768">this PR</a>.</p> <h3><code>tabindex</code></h3> <p>As you may know already, built-in elements like <code><button></code>, <code><input></code>, <code><a></code>, etc. all have a “default” focus behavior — they are focusable (or not) by default. When the <a href="https://html.spec.whatwg.org/multipage/interaction.html#dom-tabindex"><code>tabIndex</code> property getter</a> is run on an element whose <code>tabindex</code> attribute is not explicitly set already, it will return 0 sometimes and -1 other times. Previously, the spec said to return 0 if the element is “focusable” by default (which type of focusable?), and -1 otherwise. But <a href="https://github.com/whatwg/html/issues/1786">this wasn’t implemented anywhere</a>, because of possible differences in which elements are focusable by default in various UAs. So now the spec actually checks if the tag name is one of the tag names included in a pre-defined list. This is quite awkward, but at least it’s interoperable! (PR is <a href="https://github.com/whatwg/html/pull/4754">here</a>.)</p> <p>Now, what is the use of <code><a href="https://html.spec.whatwg.org/multipage/interaction.html#attr-tabindex">tabindex</a></code> exactly? You can make an element focusable by setting its <code>tabindex</code> attribute to an integer. This will set the <a href="https://html.spec.whatwg.org/multipage/interaction.html#tabindex-value">tabindex value</a>, and thus impact the focusability of the element. If the integer is non-negative, the element is also sequentially focusable. You can’t, however, make an element not focusable at all through this attribute — there is no value you can set the tabindex attribute to on a <code><button></code> that will stop it from being focusable.</p> <p>You can also modify the order of elements traversed with sequential navigation/tabbing — elements with a positive tabindex value will be traversed first, in ascending order (and in tree order in case of a tie), and then elements with a tabindex value of zero (or unspecified but the element is sequentially focusable by default), in tree order.</p> <h3><code>autofocus</code></h3> <p>The <code>autofocus</code> content attribute is useful if you want to set focus on a form control element on page load. However, it had some issues such as:</p> <ul> <li>The <code>autofocus</code> attribute was available only for some form control elements, and unavailable for other focusable elements like <code><summary></code>, <code><div contenteditable="true"></code>, and <code><span tabindex="0"></code>.</li> <li>The behavior with an autofocused element in a page accessed with a fragment identifier (e.g. https://example.com/#foo) was not interoperable.</li> <li>What should happen if there are multiple autofocused elements, and one of them is not focusable?</li></ul> <p>The HTML specification and the SVG specification were updated to resolve these issues by changes <a href="https://github.com/whatwg/html/pull/4763">1</a>, <a href="https://github.com/whatwg/html/pull/4830">2</a>, and <a href="https://github.com/w3c/svgwg/pull/728">3</a>. Now the <code>autofocus</code> content attribute and the <code>autofocus</code> IDL attribute are available on all HTML and SVG elements. The <code>autofocus</code> content attribute is not processed if its document has a fragment identifier, or has a focused element. If an autofocus element is not focusable, the element is skipped and another autofocus element is handled.</p> <h3>Shadow DOM and <code>delegatesFocus</code></h3> <p>All of the previously mentioned concepts were already specced in the HTML spec in some way, albeit a bit unclear, not reflecting the actual behavior, etc. Focus behavior with shadow DOM, though, <a href="https://github.com/whatwg/html/issues/2013">had not been upstreamed</a> from the old <a href="https://w3c.github.io/webcomponents/spec/shadow/#focus">Shadow DOM spec</a> at all, so this part of the effort took the most time overall. Since some parts of the Shadow DOM spec on focus were unclear and needed more explanation, we also took a look at how it’s implemented in Blink to get the exact behavior down, and discussed with other browser vendors and web developers on whether we want to keep the implemented behavior or not in some cases.</p> <p>Sequential focus navigation got some significant additions (<a href="https://github.com/web-platform-tests/wpt/pull/17523">PR</a>) with Shadow DOM. We now have a concept of <a href="https://html.spec.whatwg.org/multipage/interaction.html#tabindex-ordered-focus-navigation-scope">“tabindex-ordered focus navigation scope”</a>, <a href="https://html.spec.whatwg.org/multipage/interaction.html#focus-navigation-scope-owner">“focus navigation scope owners”</a>, etc. Essentially, elements are put in different <a href="https://html.spec.whatwg.org/multipage/interaction.html#focus-navigation-scope">focus navigation scopes</a>, where those that belong to the same shadow tree/root, or are slotted to the same slot, are put in the same focus navigation scope. The tabindex order explained earlier now only applies to elements in the same scope, and then finally we <a href="https://html.spec.whatwg.org/multipage/interaction.html#flattened-tabindex-ordered-focus-navigation-scope">flatten</a> all of the scopes to get the final <a href="https://html.spec.whatwg.org/multipage/interaction.html#sequential-focus-navigation-order">sequential focus navigation order</a>.</p> <p>A new concept added (PR <a href="https://github.com/whatwg/html/pull/4796">1</a>, <a href="https://github.com/whatwg/dom/pull/768">2</a>) by Shadow DOM is <a href="https://dom.spec.whatwg.org/#shadowroot-delegates-focus">“delegates focus”</a>, which is used when you want attempts to focus on a shadow host to not focus on the host itself, and instead <a href="https://html.spec.whatwg.org/#focusing-steps">delegate the focus</a> to within the shadow tree (like <code><input type="date"></code>!). In Blink, this delegation uses the sequential focus navigation order, but we think it is a bit weird and started a <a href="https://github.com/w3c/webcomponents/issues/830">discussion</a> on how this should actually work — finally <a href="https://github.com/whatwg/html/pull/4796">changing</a> the delegation to respect the protocol of whatever the focusing method is originally used. (That is, use sequential order if we used tabbing, otherwise use flat-tree order and respect click focusability if needed.)</p> <p>We also added the <a href="https://html.spec.whatwg.org/multipage/interaction.html#dom-documentorshadowroot-activeelement"><code>DocumentOrShadowRoot</code>’s <code>activeElement</code> property</a> (<a href="https://github.com/whatwg/html/pull/4837">PR</a>). And we updated the <a href="https://html.spec.whatwg.org/#selector-focus"><code>:focus</code> selector</a> (<a href="https://github.com/whatwg/html/pull/4731">PR</a>), which will now match on shadow hosts if the focused element is a shadow-including inclusive descendant of it. (This is actually different than the behavior in Blink, and is a result of <a href="https://www.w3.org/2019/09/17-components-minutes.html#item02">discussion in TPAC</a> — where we also discussed “delegates focus”.)</p> <h3>The future, and outro</h3> <p>Now that we have a good-enough spec for focus, we have a good foundation for future additions to focus. One new relevant proposal is <a href="https://github.com/w3c/webcomponents/blob/gh-pages/proposals/custom-element-default-focus.md">“custom element default focusability”</a>. As we’ve mentioned, built-in elements have a “default” focus behavior — even though they don’t have a tabindex value explicitly, they are still focusable (or not). When you’re making custom elements, though, currently there is no way to make them focusable by default, without setting the tabindex attribute. The proposal listed various ways this might be solved, and it was <a href="https://www.w3.org/2019/09/17-components-minutes.html#item07">talked about in TPAC</a> with a relatively positive response from various parties. Do check it out if you’re interested!</p> <p>In summary, focus was and is still quite complex to understand. But, at least now there’s a clear source of truth for it, and the browser vendors are working to make it interoperable — implementing new changes to the spec as soon as they can. There are still <a href="https://github.com/whatwg/html/issues?q=is%3Aopen+is%3Aissue+label%3A%22topic%3A+focus%22">lots of focus-related things that need to be specced</a> (we’ve heard people mention <code>focusin</code>/<code>focusout</code>, more CSS selectors, etc.), so if you’re intrigued by this post, know that you can also contribute to fix more things like these!</p> <p>Having an old and mostly confusing focus spec, different types of focus, and multiple uses for <code>tabindex</code> made things quite complicated when starting out. However, one of the trickiest parts of focus, in my opinion, is the fact that what is focusable/click focusable/sequentially focusable might differ in different UAs, and it might be dynamic as well! (E.g. in Safari what’s sequentially focusable changes if you hold down the <kbd>Option</kbd> key!) This means we need to make sure the spec is written to allow for differences, but is still, um, specific enough to make things not too ambiguous.</p> <p>Overall, we’re happy with the result of this effort. We’d like to thank all the parties involved that participated in various ways: experimenting, reviewing spec PRs, implementing the changes, commenting/participating in discussions, etc. Special thanks to <a href="https://github.com/tkent-google">Kent Tamura</a> (who wrote some parts of this post and did the <code>autofocus</code> specs) and <a href="https://github.com/domenic">Domenic Denicola</a> (who kickstarted this whole effort, reviewed all the PRs, and suggested + reviewed this post).</p> <p>Now we can focus on other parts of HTML Standard...</p>]]></content:encoded> <wfw:commentRss>https://blog.whatwg.org/focusing-on-focus/feed</wfw:commentRss> <slash:comments>2</slash:comments> </item> <item> <title>The state of fieldset interoperability</title> <link>https://blog.whatwg.org/the-state-of-fieldset-interoperability</link> <comments>https://blog.whatwg.org/the-state-of-fieldset-interoperability#comments</comments> <dc:creator><![CDATA[Simon Pieters]]></dc:creator> <pubDate>Wed, 19 Sep 2018 14:00:36 +0000</pubDate> <category><![CDATA[Browsers]]></category> <category><![CDATA[Forms]]></category> <category><![CDATA[WHATWG]]></category> <guid isPermaLink="false">https://blog.whatwg.org/?p=12947</guid> <description><![CDATA[As part of my work at Bocoup, I recently started working with browser implementers to improve the state of fieldset, the 21 year old feature in HTML, that provides form accessibility benefits to assistive technologies like screen readers. It suffers from a number of interoperability bugs that make it difficult for web developers to use. […]]]></description> <content:encoded><![CDATA[<p>As part of my work at <a href="https://bocoup.com/">Bocoup</a>, I recently started <a href="https://bocoup.com/work/fieldset-interoperability">working with browser implementers to improve the state of <code>fieldset</code></a>, the 21 year old feature in HTML, that provides form accessibility benefits to assistive technologies like screen readers. It suffers from a number of interoperability bugs that make it difficult for web developers to use.</p> <p>Here is an example form grouped with a <code><legend></code> caption in a <code><fieldset></code> element:</p> <fieldset style="margin-bottom: 1em"> <legend>Pronouns</legend> <label><input type=radio name=pronouns value=he /> He/him</label> <label><input type=radio name=pronouns value=she /> She/her</label> <label><input type=radio name=pronouns value=they /> They/them</label> <label><input type=radio name=pronouns value=other /> Write your own</label> <input type=text name=pronouns-other placeholder=… /></fieldset> <p>And the <a href="http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6183">corresponding markup</a> for the above example.</p> <pre><code><fieldset> <legend>Pronouns</legend> <label><input type=radio name=pronouns value=he> He/him</label> <label><input type=radio name=pronouns value=she> She/her</label> <label><input type=radio name=pronouns value=they> They/them</label> <label><input type=radio name=pronouns value=other> Write your own</label> <input type=text name=pronouns-other placeholder=&hellip;></fieldset></code></pre> <p>The element is defined <a href="https://html.spec.whatwg.org/multipage/form-elements.html#the-fieldset-element">in the HTML standard</a>, along with <a href="https://html.spec.whatwg.org/multipage/rendering.html#the-fieldset-and-legend-elements">rendering rules in the Rendering section</a>. Further developer documentation is available on <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/fieldset">MDN</a>.</p> <h3>Usage</h3> <p>Based on a query of the <a href="https://httparchive.org/">HTTP Archive</a> data set, containing the raw content of the top 1.3 million web pages, we find <a href="https://discuss.httparchive.org/t/use-of-html-elements/1438">the relative usage of each HTML element</a>. The <code>fieldset</code> element is used on 8.41% of the web pages, which is higher than other popular features, such as the <code>video</code> and <code>canvas</code> elements; however, the <code>legend</code> element is used on 2.46% of web pages, which is not ideal for assistive technologies. Meanwhile, the <code>form</code> element appears on 70.55% of pages, and we believe that if interoperability bugs were fixed, correct and semantic <code>fieldset</code> and <code>legend</code> use would increase, and have a positive impact on form accessibility for the web.</p> <h3>Fieldset standards history</h3> <p>In January 1997, HTML 3.2 introduces forms and some form controls, but does not include the <code>fieldset</code> or <code>legend</code> elements.</p> <p>In July 1997, the first draft of <a href="https://www.w3.org/TR/WD-html40-970708/interact/forms.html#h-9.1.2.6">HTML 4.0 introduces the <code>fieldset</code> and <code>legend</code> elements</a>:</p> <blockquote><p>The FIELDSET element allows form designers to group thematicallyrelated controls together. Grouping controls makes it easier for usersto understand their purpose while simultaneously facilitating tabbingnavigation for visual user agents and speech navigation forspeech-oriented user agents. The proper use of this element makesdocuments more accessible to people with disabilities.</p> <p>The LEGEND element allows designers to assign a caption to a FIELDSET.The legend improves accessibility when the FIELDSET is renderednon-visually. When rendered visually, setting the align attribute onthe LEGEND element aligns it with respect to the FIELDSET.</p></blockquote> <p>In December 1999, HTML 4.01 is published as a W3C Recommendation, without changing the definitions of the <code>fieldset</code> and <code>legend</code> elements.</p> <p>In December 2003, Ian Hickson extends the <code>fieldset</code> element with the <code>disabled</code> and <code>form</code> attributes in the <a href="http://www.hixie.ch/specs/html/forms/xforms-basic-1">Proposed XHTML Module: XForms Basic</a>, later renamed to <a href="https://whatwg.org/specs/web-forms/current-work/">Web Forms 2.0</a>.</p> <p>In September 2008, <a href="https://github.com/whatwg/html/commit/62a6f3ee9bf8b6b5ecccb97b60fa949d482174e1">Ian Hickson adds the <code>fieldset</code> element to the HTML standard</a>.</p> <p>In February 2009, Ian Hickson specifies <a href="https://github.com/whatwg/html/commit/a72aed9e5e86eaed0cc5565934ec3c2ad4ff45ef">rendering rules for the <code>fieldset</code> element</a>. The specification has since gone through some minor revisions, e.g., specifying that <a href="https://github.com/whatwg/html/commit/a7ca0499684fea1bbd3d969fd3577d7142da9a49"><code>fieldset</code> establishes a block formatting context</a> in 2009 and <a href="https://github.com/whatwg/html/commit/997399b86db6abfe98918ab9bb134ffd4f28ff56">adding <code>min-width: min-content;</code></a> in 2014.</p> <p>In August 2018, I <a href="https://github.com/whatwg/html/pulls?utf8=%E2%9C%93&q=is%3Apr+label%3A%22topic%3A+fieldset%22+author%3Azcorpan">proposed a number of changes</a> to the standard to better define how it should work, and resolve ambiguity between browser implementer interpretations.</p> <h3>Current state</h3> <p>As part of our work at Bocoup to improve the interoperability of the <code>fieldset</code> and <code>legend</code> child element, we talked to web developers and browser implementers, proposed changes to the standard, and <a href="https://github.com/web-platform-tests/wpt/pulls?utf8=%E2%9C%93&q=is%3Apr+label%3Ahtml-fieldset">wrote a lot of tests</a>. At the time of this writing, <a href="https://github.com/whatwg/html/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3A%22topic%3A+fieldset%22">26 issues</a> have been reported on the HTML specification for the <code>fieldset</code> element, and the <a href="https://wpt.fyi/interop/html/rendering/non-replaced-elements/the-fieldset-and-legend-elements">tests that we wrote show a clear lack of interoperability</a> among browser engines.</p> <p><a href="https://wpt.fyi/interop/html/rendering/non-replaced-elements/the-fieldset-and-legend-elements"><img decoding="async" style="max-width:100%" alt="The results for fieldset and legend tests show some tests failing in all browsers, some tests passing in all browsers, and some passing and failing in different browsers." src="https://user-images.githubusercontent.com/244772/45701083-45e70500-bb3c-11e8-8859-7f55adfa27a1.png" srcset="https://user-images.githubusercontent.com/244772/45701083-45e70500-bb3c-11e8-8859-7f55adfa27a1.png 2x"/></a></p> <p>Of the 26 issues filed against the specification, <a href="https://github.com/whatwg/html/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3A%22topic%3A+fieldset%22+label%3A%22topic%3A+rendering%22">17 are about rendering interoperability</a>. These rendering issues affect use cases such as <a href="http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6164">making a <code>fieldset</code> scrollable</a>, which currently result in broken scroll-rendering in some browsers. These issues also affect consistent <code>legend</code> rendering which is causing web developers <a href="https://twitter.com/fvsch/status/1022371862674911232">avoid using the <code>fieldset</code> element</a> altogether. Since the <code>fieldset</code> element is intended to help people who use assistive technologies to navigate forms, the current situation is less than ideal.</p> <h4>HTML spec rendering issues</h4> <p>In April of this year, Mozilla developers filed a meta-issue on the HTML specification “<a href="https://github.com/whatwg/html/issues/3660">Need to spec fieldset layout</a>” to address the ambiguities which have been leading to interoperability issues between browser implementations. During the past few weeks of work on <code>fieldset</code>, we made initial <a href="https://github.com/whatwg/html/pull/3934">proposed changes</a> to the rendering section of the HTML standard to address these 17 issues. At the time of this writing, these changes are under review.</p> <h4>Proposal to extend -webkit-appearance</h4> <p>Web developers also struggle with changing the default behaviors of <code>fieldset</code> and <code>legend</code> and seek ways to <a href="https://twitter.com/etportis/status/1022250278685356032">turn off the “magic”</a> to have the elements render as normal elements. To address this, we created a <a href="https://github.com/whatwg/html/pull/4035">proposal</a> to extend the <code>-webkit-appearance</code> CSS property with a new value called <code>fieldset</code> and a new property called <code>legend</code> that are together capable giving grouped rendering behavior to regular elements, as well as resetting <code>fieldset</code>/<code>legend</code> elements to behave like normal elements.</p> <pre><code>fieldset { -webkit-appearance: none; margin: 0; padding: 0; border: none; min-inline-size: 0;}legend { legend: none; padding: 0;}</code></pre> <p>The general purpose proposed specification for an "unprefixed" <a href="https://www.w3.org/TR/2017/WD-css-ui-4-20171222/#appearance-switching">CSS ‘appearance’ property</a>, has been blocked by <a href="https://groups.google.com/forum/#!msg/mozilla.dev.platform/Fq6OH5SWeRo/lxHDXFnwCQAJ">Mozilla's statement</a> that it is not web-compatible as currently defined, meaning that implementing <code>appearance</code> would break the existing behavior of websites that are currently using CSS <code>appearance</code> in a different way.</p> <p>We <a href="https://github.com/w3c/csswg-drafts/issues/3094">asked the W3C CSS working group for feedback</a> on the above approach, and they had some reservations and will develop an alternative proposal. When there is consensus for how it should work, we will update the specification and tests accordingly.</p> <p>We had also considered defining new <code>display</code> values for <code>fieldset</code> and <code>legend</code>, but care needs to be taken to preserve web compatibility. There are thousands of pages in HTTP Archive that set ‘display’ to something on <a href="https://gist.github.com/zcorpan/711d7f7c199db74a0994f55da7935660"><code>fieldset</code></a> or <a href="https://gist.github.com/zcorpan/2f590536cf64c1aaabbc70f63dbfe2b5"><code>legend</code></a>, but browsers typically <a href="https://github.com/whatwg/html/issues/3915">behave as <code>display: block</code></a> was set. For example, specifying <code>display: inline</code> on the legend needs to render the same as it does by default.</p> <p>In parallel, we authored an <a href="https://github.com/whatwg/compat/pull/104">initial specification for the ‘-webkit-appearance’ property</a> in <a href="https://miketaylr.com/">Mike Taylor</a>'s WHATWG Compatibility standard (which reverse engineers web platform wonk into status quo specifications), along with <a href="https://github.com/web-platform-tests/wpt/pull/12700">accompanying tests</a>. More work needs to be done for the ‘-webkit-appearance’ (or unprefixed ‘appearance’) to define what the values mean and to reach interoperability on the supported values.</p> <h4>Accessibility Issues</h4> <p>We have started looking into <a href="https://github.com/web-platform-tests/wpt/pull/12691">testing accessibility</a> explicitly, to ensure that the elements remain accessible even when they are styled in particular ways.</p> <p>This work has uncovered <a href="https://github.com/w3c/html-aam/issues/145">ambiguities in the specification</a>, which we have submitted a <a href="https://github.com/w3c/html-aam/pull/146">proposal</a> to address. We have also identified interoperability issues in the accessiblity mapping in implementations, which we <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1488042">have</a> <a href="https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/18874640/">reported</a>.</p> <h3>Implementation fixes</h3> <p>Meta bugs have been reported for each browser engine (<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1483781">Gecko</a>, <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=874753">Chromium</a>, <a href="https://bugs.webkit.org/show_bug.cgi?id=188643">WebKit</a>, <a href="https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/18693151/">EdgeHTML</a>), which depend on more specific bugs.</p> <p>As of September 18 2018, the following issues have been fixed in Gecko:</p> <ul><li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1483527">Change <code>fieldset</code>’s default padding to match other browsers</a></li><li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1483499"><code><legend></code> not child of <code><fieldset></code> should have 2px padding</a></li><li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1279185">interaction in between border-image, <code>fieldset</code> and <code>legend</code></a></li><li><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1488301"><code><legend></code> auto inline margins doesn't work correctly</a></li></ul> <p>In Gecko, the bug <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1483787">Implement <code>fieldset</code>/<code>legend</code> in terms of '-webkit-appearance'</a> currently has a work-in-progress patch.</p> <p>The following issues have been fixes in Chromium:</p> <ul><li><a href="https://bugs.chromium.org/p/chromium/issues/detail?id=874053"><code>fieldset</code> should have min-inline-size instead of min-width in UA stylesheet</a></li><li><a href="https://bugs.chromium.org/p/chromium/issues/detail?id=476234">The field set border is broken with <code><legend></code> in vertical layout</a></li></ul> <p>The WebKit and Edge teams are aware of bugs, and we will follow up with them to track progress.</p> <h3>Conclusion</h3> <p>The <code>fieldset</code> and <code>legend</code> elements are useful to group related form controls, in particular to aid people who use assistive technologies. They are currently not interoperable and are difficult for web developers to style. With our work and proposal, we aim to resolve the problems so that they can be used without restrictions and behave the same in all browser engines, which will benefit browser implementers, web developers, and end users.</p> <p>(This post is cross-posted on <a href="https://bocoup.com/blog/the-state-of-fieldset-interoperability">Bocoup's blog</a>.)</p>]]></content:encoded> <wfw:commentRss>https://blog.whatwg.org/the-state-of-fieldset-interoperability/feed</wfw:commentRss> <slash:comments>1</slash:comments> </item> <item> <title>First set of Review Drafts published</title> <link>https://blog.whatwg.org/first-review-drafts</link> <dc:creator><![CDATA[Domenic Denicola]]></dc:creator> <pubDate>Thu, 21 Jun 2018 16:59:32 +0000</pubDate> <category><![CDATA[WHATWG]]></category> <guid isPermaLink="false">https://blog.whatwg.org/?p=12943</guid> <description><![CDATA[(If you’re interested in the IPR status of WHATWG standards this post is for you; otherwise, feel free to skip.) One aspect of last year's working mode changes is the periodic publication of a Review Draft for each WHATWG Living Standard, as per the IPR Policy. The WHATWG published an initial five of these just […]]]></description> <content:encoded><![CDATA[<p>(If you’re interested in the IPR status of WHATWG standards this post is for you; otherwise, feel free to skip.)</p> <p>One aspect of last year's <a href="https://blog.whatwg.org/working-mode-changes">working mode changes</a> is the periodic publication of a Review Draft for each WHATWG Living Standard, as per the <a href="https://whatwg.org/ipr-policy">IPR Policy</a>. The WHATWG published an initial five of these just now:</p> <ul> <li><a href="https://compat.spec.whatwg.org/review-drafts/2018-06/">Compatibility</a></li> <li><a href="https://console.spec.whatwg.org/review-drafts/2018-06/">Console</a></li> <li><a href="https://dom.spec.whatwg.org/review-drafts/2018-06/">DOM</a></li> <li><a href="https://encoding.spec.whatwg.org/review-drafts/2018-06/">Encoding</a></li> <li><a href="https://fetch.spec.whatwg.org/review-drafts/2018-06/">Fetch</a></li></ul> <p>To get notified of future Review Draft publications you need to <a href="https://help.github.com/articles/watching-and-unwatching-repositories/">watch</a> the Living Standard’s corresponding GitHub repository. You’ll find these repositories linked from the top of the standard.</p> <p>Then you can filter the emails generated by watching this repository by looking for the subject-line prefix “Review Draft Publication:” which the WHATWG will consistently use <a href="https://github.com/whatwg/meta/blob/master/MAINTAINERS.md#review-drafts">as per the Maintainer Guidelines</a>.</p> <p>Watching the repository is the only way to get notified going forward. This blog post serves as an initial announcement and as a way to make everyone familiar with the process going forward.</p> <p>Thanks for reading through three non-technical posts in a row. It will get technical again soon!</p>]]></content:encoded> </item> <item> <title>Changing the copyright license for Living Standards</title> <link>https://blog.whatwg.org/copyright-license-change</link> <dc:creator><![CDATA[Anne van Kesteren]]></dc:creator> <pubDate>Wed, 13 Dec 2017 17:00:29 +0000</pubDate> <category><![CDATA[WHATWG]]></category> <guid isPermaLink="false">https://blog.whatwg.org/?p=12918</guid> <description><![CDATA[The recent changes to the WHATWG are designed to help the web-standards development community work together across the broadest possible spectrum of developers, implementers, and end-users. As part of this change, we decided to move our standards from being licensed under the CC0 public domain dedication to the CC BY license. This decision was not […]]]></description> <content:encoded><![CDATA[<p>The <a href="/working-mode-changes">recent changes to the WHATWG</a> are designed to help the web-standards development community work together across the broadest possible spectrum of developers, implementers, and end-users. As part of this change, we decided to move our standards from being licensed under the <a href="https://creativecommons.org/publicdomain/zero/1.0/">CC0</a> public domain dedication to the <a href="https://creativecommons.org/licenses/by/4.0/">CC BY</a> license.</p> <p>This decision was not made lightly. We valued the alignment of CC0 with <a href="https://www.w3.org/Policy.html">the original public domain dedication of the WWW project</a>; the ease with which it allows remixing and refactoring of standards; and the way in which it allows copying of snippets or examples into software that implements or uses the standards.</p> <p>While CC0 is beneficial in some ways, it also has some disadvantages. The lack of an attribution requirement may seem convenient, but it can also cause confusion in the standards community. For example, there are derivative specifications ("forks") that are not prominently identified as copies of WHATWG standards. Such unattributed forks create confusion both about the origin of the standard and about any applicable intellectual property rights (IPR) commitments. Use of the CC BY license makes it easier for implementers to trace what they are implementing back to the original source and its accompanying IPR commitments.</p> <p>Additionally, CC0 <a href="https://opensource.org/faq#cc-zero">is not approved by the Open Source Initiative</a>. Although their reasoning is not very applicable in the context of the WHATWG, which has its own system for patent grants, this lack of approval from a prominent organization involved in defining "open source" can discourage participation.</p> <p>Moving to CC BY addresses these disadvantages and also allows for a reduction in license proliferation. We were able to replace the custom license of the HTML Standard, which was a source of some confusion, with CC BY. CC BY still allows modification and redistribution, but adds on the relatively modest burden of attribution. We believe that, on balance, this change is the best path forward for the community.</p>]]></content:encoded> </item> </channel></rss> If you would like to create a banner that links to this page (i.e. this validation result), do the following:
Download the "valid RSS" banner.
Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)
Add this HTML to your page (change the image src attribute if necessary):
If you would like to create a text link instead, here is the URL you can use:
http://www.feedvalidator.org/check.cgi?url=http%3A//blog.whatwg.org/feed/
