The WHATWG Blog

Please leave your sense of logic at the door, thanks!

Archive for the ‘Forms’ Category

The state of fieldset interoperability

Wednesday, September 19th, 2018

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.

Here is an example form grouped with a <legend> caption in a <fieldset> element:

Pronouns

And the corresponding markup for the above example.

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

The element is defined in the HTML standard, along with rendering rules in the Rendering section. Further developer documentation is available on MDN.

Usage

Based on a query of the HTTP Archive data set, containing the raw content of the top 1.3 million web pages, we find the relative usage of each HTML element. The fieldset element is used on 8.41% of the web pages, which is higher than other popular features, such as the video and canvas elements; however, the legend element is used on 2.46% of web pages, which is not ideal for assistive technologies. Meanwhile, the form element appears on 70.55% of pages, and we believe that if interoperability bugs were fixed, correct and semantic fieldset and legend use would increase, and have a positive impact on form accessibility for the web.

Fieldset standards history

In January 1997, HTML 3.2 introduces forms and some form controls, but does not include the fieldset or legend elements.

In July 1997, the first draft of HTML 4.0 introduces the fieldset and legend elements:

The FIELDSET element allows form designers to group thematically related controls together. Grouping controls makes it easier for users to understand their purpose while simultaneously facilitating tabbing navigation for visual user agents and speech navigation for speech-oriented user agents. The proper use of this element makes documents more accessible to people with disabilities.

The LEGEND element allows designers to assign a caption to a FIELDSET. The legend improves accessibility when the FIELDSET is rendered non-visually. When rendered visually, setting the align attribute on the LEGEND element aligns it with respect to the FIELDSET.

In December 1999, HTML 4.01 is published as a W3C Recommendation, without changing the definitions of the fieldset and legend elements.

In December 2003, Ian Hickson extends the fieldset element with the disabled and form attributes in the Proposed XHTML Module: XForms Basic, later renamed to Web Forms 2.0.

In September 2008, Ian Hickson adds the fieldset element to the HTML standard.

In February 2009, Ian Hickson specifies rendering rules for the fieldset element. The specification has since gone through some minor revisions, e.g., specifying that fieldset establishes a block formatting context in 2009 and adding min-width: min-content; in 2014.

In August 2018, I proposed a number of changes to the standard to better define how it should work, and resolve ambiguity between browser implementer interpretations.

Current state

As part of our work at Bocoup to improve the interoperability of the fieldset and legend child element, we talked to web developers and browser implementers, proposed changes to the standard, and wrote a lot of tests. At the time of this writing, 26 issues have been reported on the HTML specification for the fieldset element, and the tests that we wrote show a clear lack of interoperability among browser engines.

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.

Of the 26 issues filed against the specification, 17 are about rendering interoperability. These rendering issues affect use cases such as making a fieldset scrollable, which currently result in broken scroll-rendering in some browsers. These issues also affect consistent legend rendering which is causing web developers avoid using the fieldset element altogether. Since the fieldset element is intended to help people who use assistive technologies to navigate forms, the current situation is less than ideal.

HTML spec rendering issues

In April of this year, Mozilla developers filed a meta-issue on the HTML specification “Need to spec fieldset layout” to address the ambiguities which have been leading to interoperability issues between browser implementations. During the past few weeks of work on fieldset, we made initial proposed changes to the rendering section of the HTML standard to address these 17 issues. At the time of this writing, these changes are under review.

Proposal to extend -webkit-appearance

Web developers also struggle with changing the default behaviors of fieldset and legend and seek ways to turn off the “magic” to have the elements render as normal elements. To address this, we created a proposal to extend the -webkit-appearance CSS property with a new value called fieldset and a new property called legend that are together capable giving grouped rendering behavior to regular elements, as well as resetting fieldset/legend elements to behave like normal elements.

fieldset {
  -webkit-appearance: none;
  margin: 0;
  padding: 0;
  border: none;
  min-inline-size: 0;
}
legend {
  legend: none;
  padding: 0;
}

The general purpose proposed specification for an "unprefixed" CSS ‘appearance’ property, has been blocked by Mozilla's statement that it is not web-compatible as currently defined, meaning that implementing appearance would break the existing behavior of websites that are currently using CSS appearance in a different way.

We asked the W3C CSS working group for feedback 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.

We had also considered defining new display values for fieldset and legend, but care needs to be taken to preserve web compatibility. There are thousands of pages in HTTP Archive that set ‘display’ to something on fieldset or legend, but browsers typically behave as display: block was set. For example, specifying display: inline on the legend needs to render the same as it does by default.

In parallel, we authored an initial specification for the ‘-webkit-appearance’ property in Mike Taylor's WHATWG Compatibility standard (which reverse engineers web platform wonk into status quo specifications), along with accompanying tests. 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.

Accessibility Issues

We have started looking into testing accessibility explicitly, to ensure that the elements remain accessible even when they are styled in particular ways.

This work has uncovered ambiguities in the specification, which we have submitted a proposal to address. We have also identified interoperability issues in the accessiblity mapping in implementations, which we have reported.

Implementation fixes

Meta bugs have been reported for each browser engine (Gecko, Chromium, WebKit, EdgeHTML), which depend on more specific bugs.

As of September 18 2018, the following issues have been fixed in Gecko:

In Gecko, the bug Implement fieldset/legend in terms of '-webkit-appearance' currently has a work-in-progress patch.

The following issues have been fixes in Chromium:

The WebKit and Edge teams are aware of bugs, and we will follow up with them to track progress.

Conclusion

The fieldset and legend 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.

(This post is cross-posted on Bocoup's blog.)

Posted in Browsers, Forms, WHATWG | No Comments »

Google Tech Talk: HTML5 demos

Friday, September 26th, 2008

I gave a talk at Google on Monday demonstrating the various features of HTML5 that are implemented in browsers today. The video is now on YouTube, so now you too can watch and laugh at my lame presentation skills!

The segments of this talk are as follows. Some of the demos are available online for you to play with and are linked to from the following list:

  1. Introduction
  2. <video> (00:35)
  3. postMessage() (05:40)
  4. localStorage (15:20)
  5. sessionStorage (21:00)
  6. Drag and Drop API (29:05)
  7. onhashchange (37:30)
  8. Form Controls (40:50)
  9. <canvas> (56:55)
  10. Validation (1:07:20)
  11. Questions and Answers (1:09:35)

If you're very interested in watching my typos, the high quality version of the video on the YouTube site is clear enough to see the text being typed. More details about the demos can be found on the corresponding demo page.

Posted in Browser API, Browsers, Conformance Checking, DOM, Elements, Events, Forms, Multimedia, Syntax, WHATWG | 7 Comments »

Web Forms 2.0 Cross-Browser Implementation

Monday, August 20th, 2007

A cross-browser implementation of Web Forms 2.0 has been released. The W3C HTML Working Group is now reviewing the Web Forms 2.0 specification to serve as a basis for the next version HTML (as everyone knows). Some discussion on the HTML WG mailing list regarding the WF2 specification has been at times ignorant of the content of the specification and what it actually enables authors to do. Hopefully by using this implementation and examining its associated test suite, the meaning of the specification will be clarified, and members of the HTML WG will be more educated so as to more constructively review it.

I started work on this project with an standalone implementation of the repetition model, but I have since expanded it to include other WF2 features as well. I developed this library on the job for incorporation into the various development projects I was working on; I have found the functionality provided by WF2, especially the repetition model and the form validation model, to greatly ease development. Try using it in your own projects and see for yourself, and then drop a line to WHATWG and the HTML WG with your feedback on what works well and what needs to be improved.

This implementation works in Firefox 1+, MSIE 6+, and Safari 2+ (Opera, of course, has a native implementation). For more information on the implemented features, see the implementation details. This implementation will follow the HTML 5 specification that evolves from the work done by the HTML Working Group.

Posted in Forms | 1 Comment »

fieldsets need legends

Thursday, March 8th, 2007

this post refers to the "Write" interface from WordPress utilized to post comments to WHATWG blogs.

there is well-intentioned, but mis-implemented markup in the edit form; namely, improper implemetation of the FIELDSET.

for a proper FIELDSET, one needs to do 4 things:

  1. open the FIELDSET (which this form does)
  2. define a LEGEND for the FIELDSET (which this form does NOT); the natural candidates for LEGEND are the level 3 headers (H3) classed dbx-handle so instead of repeatedly hearing "click to open this box", i would also get the pseudo-box (which i would call sub-forms) LEGEND as an indicator of what i am about to open or close. i would also make the alt text device independent - instead of "click here to open this box", i would propose "show sub-form" and "hide sub-form"
  3. bind individual FORM controls to their textual labels by use of the LABEL element and the for/id mechanism that ties the form control (which takes the "id") to a LABEL (which takes the "for") or multiple labels; the LABEL should contain the actual, textual label, and NOT the FORM control, as in this form; this form has the attribute set set correctly to bind the LABEL to the FORM control, but since the LABEL element is opened PRIOR to the INPUT element, no labeling is available to the user - in my case (i use a screen-reader) the sub-forms that appear when one opens a FIELDSET to reveal a FORM appear unlabeled to my screenreader, because of invalid markup.
  4. close the FIELDSET (which this form does)

Posted in Forms, WHATWG | 10 Comments »

Proposing URI Templates for WebForms 2.0

Thursday, January 11th, 2007

I recently had an off-list email conversation with Ian Hickson about the possibility of adding URI Template support to the FORM element in WebForms 2.0. I've documented our conversation and my response to his suggestion to use server-side direct or Javascript instead over at the Well Designed URL Initiative blog. However, I've provided some examples of what I'm proposing below:

<form 
  action="http://foo.com/model"
  template="http://foo.com/{make}/{model}/"
  method="get">
  <input type="text" name="make" />
  <input type="text" name="mode" />
  <input type="submit" />
</form>
<form
  action="http://www.myblog.com/topic"
  template="http://www.myblog.com/{topic}/"
  method="post">
  <select name="topic">
    <option value="first">My 1st Post</option>
    <option value="second">My 2nd Post</option>
    <option value="third">My 3d Post</option>
  </select>
  <input type="text" name="comment">
  <input type="submit">
</form>
<form 
  action="http://blog.whatwg.org/topic"
  template="http://blog.whatwg.org/{topic}"
  method="post">
  <select name="topic">
    <option value="feed-autodiscovery">
       Feed Autodiscovery
    </option>
    <option
value="text-content-checking">
        textContent Checking
    </option>
    <option value="checker-bug-fixes">
        Bug Fixes
    </option>
    <option
        value="significant-inline-checking">
        Significant Inline Checking
    </option>
    <option value="charmod-norm-checking">
        Charmod Norm Checking
    </option>
    <option
value="proposing-features">
        Proposing features
    </option>
  </select>
  <input type="submit">
</form>

One point I made on the WDUI blog that I also I want to make here is that is seems from my time on the REST-discuss list that many of the REST experts tend toward using (what I call well-designed URLs, i.e. URLs where the resource is identified by path instead of query string. With WebForm 2.0's pending support of PUT and DELETE, it would be just short of a crime not to include support for posting to clean URLs in WebForms 2.0.

So I really hope that Ian and the WHATWG can see their way clear to consider adding this feature to WebForms 2.0. And if the main issue with it is needing to have it written up for inclusion in the spec, I'm more than happy to help.

Posted in Forms | 9 Comments »