In end-user (public, non-authorized user) themed output, groups of Children nodes and Link Operations are wrapped in FIELDSETs with LEGENDs. However, the content within these containers are not form elements -- it's text and HTML output.

This is a completely inappropriate use of these containers that significantly complicates styling via CSS (particularly in the case of LEGEND). It also violates the HTML 4 and XHTML specifications, which require that FIELDSET and LEGEND be contained within a FORM and be solely used "to group thematically related [form] controls and labels".

This inappropriate use of FIELDSET and LABEL also poses accessibility issues that could easily confuse users of assistive technologies.

This default themed behavior should be removed altogether. It should not even be an option. Instead, DIVs should be used.

Behavior present in versions 5.x-2.2 and 5.x-2.x-dev.

(To be clear: this applies only to end-user themed output. Use of FIELDSETs and LEGENDs *is* appropriate within the admin tools.)


bangpound’s picture

That's just not true. The HTML 4 and XHTML specs do not require fieldset and legend to be contained within form elements. FIELDSET can even be the child of the BODY element. It's valid syntax to put fieldsets outside forms.

If it creates semantic problems for your documents, you can override the theme functions. The fieldset is output in a theme function, and the default functions allow you to turn off the fieldset by passing FALSE as the second parameter to theme_relativity_show_parents, theme_relativity_show_children, theme_relativity_show_ancestors.

I don't know how it would present accessibility problems if the fieldset. Did you test it with other devices?

spencersundell’s picture

Hi bangpound --

Thanks very much for the information on how to disable fieldset output. It's greatly appreciated and I'll give it a try. So far, I'm finding that I can eliminate the fieldset containing the various child nodes, but theme_relativity_show_children still wraps each child in a fieldset regardless of the parameter passed.

All the same, and with all respect, one should not be forced to go to extra lengths to eliminate unnecessary and even counterproductive markup. Clean output should always be the default, no?

By the same token, what exactly is gained by using gratuitous fieldsets and legends by default?

The display complications caused by use of fieldset and legend are non-trivial. How they are displayed is completely inconsistent across the myriad browsers out there. Firefox in particular is extremely limited in how CSS can be used in relation to legend, which can't even be hidden unless it's wrapped in another gratuitous container like a div or span. This latter issue is an especially big problem in this context. In a professional web dev context, all of this is needlessly problematic.

Re: the HTML specs...

After some confirming testing with the W3C validator, I stand humbly corrected and you are quite right on the letter of "the law" (so to speak). Nevertheless, the spirit and intent is crystal clear: the W3C HTML 4 spec discusses FIELDSET and LABEL solely in the section devoted to forms (in section 17 of the HTML4 spec), and nowhere else. Indeed, that sub-section is entitled "Adding structure to forms: the FIELDSET and LEGEND elements." Note that it refers explicitly to forms content and not to non-form content.

Further, the spec states:

"The FIELDSET element allows authors to group thematically related controls and labels. 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 term "controls," of course, refers specifically to form input elements, as explained at the outset of the form section of the specification: "Users interact with forms through named controls."

No other use for FIELDSET or LEGEND is ever mentioned anywhere else in the HTML spec, including the section devoted to structuring page text.

The HTML 4 Transitional DTD states fieldset is a "form control group". The XHTML 1.0 DTDs state "The fieldset element is used to group form fields."

So okay, ya got me: technically it's valid because it is not specifically forbidden -- which surely must be an oversight, but so be it. But it's clearly an inappropriate use of the elements contrary to their explicitly defined purpose. There ain't one single form element to be grouped anywhere in the end-user output.

Re: accessibility...

Accessibility concerns are multivalent and complex (as always). In the case of screen readers, various programs will respond differently when encountering a form, or thinking they're encountering a form. But most basically, a fieldset announces in effect that "Hey user, here comes a set of form fields you will interact with so watch out." Except in this case there is no form, no fields, no interaction (at least of that kind). This is misleading to the unsighted user. In the context of a larger site, if/when such users actually do encounter a form, they've now been conditioned to disbelieve the road signs. This helps no one.

But accessibility is not just about screen readers: for example, the cognitively challenged must also be accounted for. This includes those with developmental disabilities, but it also includes the elderly and others. I'll concede that the visual display may not lead such users astray, if they also happen to also be using a screen reader things could become very confusing indeed.

Respectully yours...

darius’s picture

Hi everyone,

I appreciate the discussion, and I do agree in principle with spencersundell that fieldsets should be eliminated in the display themes. However, I am busy with other relativity issues, so for now the easiest solution is to overwrite the theme_relativity_ functions with your own custom theme functions.

BTW, proposals of how to achieve the same type of display without using fieldsets are welcome. The change should be transparent to users who already rely on the current default look.

bangpound’s picture

It never bothered me because I don't rely on those theme functions, but they should output better code.

I don't know why a screen reader would think it's encountering a form when it hasn't encountered a FORM element. That's why I asked if you have any actual evidence that there's an actual usability or accessibility problem?

There's no great reason to use a fieldset/legend pair. I suspect it's because Drupal has a fieldset theme function that allows you to pass a title and content to it. But so does theme_item_list, and for our purpose, that might be the better way to go.

spencersundell’s picture

Hi darius --

BTW, proposals of how to achieve the same type of display without using fieldsets are welcome. The change should be transparent to users who already rely on the current default look.

My suggestion in that case would be to generate divs with some appropriate CSS class names attached in lieu of the fieldset and legend tags.

Sadly, there is no 100-percent bulletproof way to reliably and portably do a pixel-perfect imitation of a fieldset/legend pair using CSS. Even a close second would generally require (modest) custom intervention by the site builder. This is because:

  • The legend generally overlays and obscures fieldset's border while allowing the parent container's background color to show through. This is simply not possible in CSS in any browser, and retaining BG transparency for legend makes it difficult to read because the underlying border runs intersects the text. Specifying a background color does the trick viz. legibility, but any default chosen may not match a site or theme's given color scheme.
  • Each browser renders fieldsets/legends slightly (sometimes drastically) differently (see this page for some styled and semi-unstyled examples). Realistically, the ability to target specific browsers via CSS is essentially non-existent for all intents and purposes. (For example, JS browser detection is highly unreliable, and CSS hacks must never be used because they are not future-proof and can/will wreak havoc later.) For IE, conditional comments can be used.
  • Even worse, IE actually uses rounded corners for fieldset...which means conversion will change the appearance in the most common browser. (Yep, rounded corners are quite possible in CSS, but not without div bloat, BG images, etc. Some targeted DOM scripting could do the trick if preserving the design is critical to the client.)

That last one is the real bummer since it truly fubars a plug-and-play universal fix. :-('s an as-close-as-possible divs-and-CSS approximation (your mileage may vary, void where prohibited, do not use while driving). I've included a header tag for semantic purposes -- I opted for an H3, but it could be an H2 or whatever suits.

Fieldset approach (obviously)


  <legend>Wibble Wobble</legend>

  <p>Foop boing pow!</p>


Semantically-correct CSS version

The CSS:

  /* simulate a fieldset */
  div.relativity-item-container {
    border: 2px groove;
    padding: 0 0.25em;

    Simulate a legend: NOTE BACKGROUND COLOR! 
    Customize that as needed for theme. (Sorry!)
  div.relativity-item-legend {
    background: #fff;
    display: inline;
    width: auto;
    position: relative;
    top: -0.6em;
    left: 0.4em;
    padding: 0 0.1em;

  /* De-"headerize" the semantic-friendly h3 */
  div.relativity-item-legend h3 {
    display: inline;
    font-weight: normal !important;
    font-size: 1em;
    margin: 0;
    padding: 0;

The markup:

  <div class="relativity-item-container">

    <div class="relativity-item-legend">
      <h3>Wibble Wobble</h3>

    <p>Foop boing pow!</p>


I hope this is helpful. Thanks for listening.

bangpound’s picture

new1.73 KB

I gave it a go as well, and it can be done even more simply for A-grade browsers. I tested in Safari, Firefox on Mac and IE 6.

I don't think it's possible to guarantee that we can reproduce fieldset appearances across browsers and platforms, because they all have slight variations. For example, IE adds some extra margin to the legend. If people aren't using some kind of reset CSS, I don't see how it's possible.

My example is attached. It has a TXT file extension because doesn't want HTML files attached.

spencersundell’s picture

Hi bangpound --

My only concerns about your markup example is it (apparently) has a third-party dependency, namely the YUI resets, and -- more importantly -- appears to rely on a star hack variant for a couple things.

CSS hacks must be avoided at all costs because, like all hacks, they rely on errant behavior that will change in future and thus produce unpredictable display. The impact of the release of IE7 is a major case in point.


bangpound’s picture

The star hack was applied to legend and fieldset elements — those elements we're not going to be using — so I don't understand your objection. If I remove all linked stylesheets, the examples still look identical.

bangpound’s picture

Status:Active» Needs review
new5.78 KB

Here's a patch to get us started. All fieldsets are replaced by themed boxes.

I also removed some \n and <br /> that were making relativity's lists difficult to theme. And I made the children list into an actual HTML list.

If you want to keep the fieldsets, you can simply put this in your theme's box.tpl.php file.

<?php if ($region == 'relativity'): ?>
<?php if ($title): ?>
<legend><?php print $title ?></legend>
<?php endif; ?>
<?php print $content ?>
<?php else: ?>
<?php if ($title): ?>
<h2><?php print $title ?></h2>
<?php endif; ?>
<?php print $content ?>
<?php endif; ?>

If you have something else going on in your box.tpl.php file, obviously you should make sure you don't destroy your customizations. I couldn't find another unintrusive way to do this, because relativity currently doesn't load a stylesheet and I don't see why we should start...

gmknowles’s picture

Title:Inappropriate use of FIELDSET and LEGEND in themed output.» Fatal error: Call to undefined function views_load_cache() relativity.module on line 1684
Version:5.x-2.x-dev» 6.x-1.x-dev

This error is thrown when setting up display options

This was probably posted in the wrong place as this should be a new issue.

When uninstalling I get these errors:

* user warning: Table 'drupal.view_view' doesn't exist query: relativity_display_settings /* : relativity_display_settings */ SELECT name FROM pcf_view_view ORDER BY name in / on line 1680.
* user warning: Table 'drupal.pcf_view_view' doesn't exist query: relativity_display_settings /* : relativity_display_settings */ SELECT name FROM pcf_view_view ORDER BY name in / on line 1680.

bangpound’s picture

Title:Fatal error: Call to undefined function views_load_cache() relativity.module on line 1684» Inappropriate use of FIELDSET and LEGEND in themed output.
Version:6.x-1.x-dev» 5.x-2.x-dev

The last comment should be a new issue. I'm reverting to the original title and version of this issue.

OliverColeman’s picture

new725 bytes

I slightly modified relativity.module to wrap the list of child nodes in a div instead of a fieldset, see attached patch for 5.x-2.3.

mgifford’s picture

Issue tags:+accessibility

adding accessibility tag. Could also be discuss this here

mgifford’s picture

Issue summary:View changes
Status:Needs review» Closed (won't fix)

Changing this to won't fix.