Inappropriate use of FIELDSET and LEGEND in themed output.

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

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

But...here'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)

<fieldset>

  <legend>Wibble Wobble</legend>
	
  <p>Foop boing pow!</p>

</fieldset>

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>
    </div>
	
    <p>Foop boing pow!</p>

  </div>

I hope this is helpful. Thanks for listening.

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.

Regards...