Hi Julian, <strong> is for emphasis. I am on your side on that one. <div>s are for separating components/sections of a page and can be semantically very strong, especially when given a meaningful class or id name (e.g. header, footer, contacts, product, etc.) <fieldset> however is quite specifically defined in W3C documentation as being used for grouping '<form> elements', hence it is fairly conclusive in my mind that using <fieldset> elsewhere is an abuse of the standard, even though it passes validation.
As responsible and sensible developers I think we ought to leverage what has already been (pretty well) defined in the official documentation from W3C and utilise the tags we have available to us as best we can. We can work further on trying to come up with better mechanisms for handling some other matters for which we feel current HTML is insufficient. I am hoping that XHTML2.0/HTML5 will help with that, although at the moment it is not looking too promising. That's it for now from me. Your English is very good and your points are well made. Regards, Jason www.flexewebs.com On 5/20/08, Julián Landerreche <[EMAIL PROTECTED]> wrote: > > > @Jason and @Svip quoted: > > Svip wrote: > > I do disagree with Julián's approach. Also, if I may add, strong >> should only be used as an inline element (you cannot really compare hN >> with strong, headlines are block elements, while strong is inline) and >> only in a case where you have a "strong" point to make, and not a >> replacement for making bold text. > > > I'm *not* using it as a replacing for making bold text. > I use <strong> to make the text (the content of the structural markup) > strong (emphasized). > Have you take a look at NetRelations.se [1] source (or better, disable the > CSS to see the structural markup in action). > > In fact, in my example, this <strong> element is child of a block element > (<div>), so it's not only semantic (see below paragraph) but also valid [2] > (inline element validate as child of a block element and sibling of another > one). > > Back to the *semantics* of this: > <div><strong>main navigation</strong> //...</div> > > I repeat: that's semantic, for me: this text is strong, it's important, and > no, it's not a paragraph or a heading (we could disagree). > > Yes, it would not be the most perfect semantic out there, but "perfect" > semantics aren't achievable by current XHTML elements . Not everything out > there fits perfect on being a paragraph, or a heading, or an unordered list > or whatever (lets not talk about the semantics of div and span). > I agree, web pages are documents, web pages should look as documents and > should make sense with/without CSS enabled (dont' forget that CSS "disabled" > is, in fact, browser default CSS, and not a totally reseted CSS). > So, if reading a site with CSS "disabled" (default browser CSS), the > semantics are given to us (sighted people) by "visual" formatting of > elements (headings are bold, have bigger size, blockquotes are indented, > etc), and structural mark-up adds semantic help for people with are visual > impaired (but not blind), cognitive disabilities, or even, people using a > device with no support for CSS . > So, if reading a site with a screen reader, semantics are given by speech > (pronunciation and/or help speech), and in consequence, a text marked by > strong will be read with emphasis. Then, the structural markup (the > <strong>) on my example has its semantics, it's important to be read loud. > Again, no, it's not a heading (but could be), nor a paragraph (does every > chunck of text out there on the web "deserve" to be a paragraph, if it isn't > a heading nor a list)? > > Jason wrote: > > Needless to say that your application should progressively > enhance<http://en.wikipedia.org/wiki/Progressive_Enhancement>through the > presentation layers. >> the basic (X)HTML page should make total sense with everything (images, >> css, javascript and flash) switched off and nicely 'upgrade' as you add each >> new piece of technology to it. >> > > Adding structural markup is, in fact, progressive enhancement, as the > research [3] I linked on the first post. > The question here is: *how to markup the structural markup? which is the > best way?* > - using headings, as, for example, in 456bereastreet [4] ? > - using <strong>, as, for example, NetRelations.se [1] ? > - using the <fieldset>+<legend> approach as suggested in this thread? > > About the last one. Yes, the W3C tells about using <fieldset> and <legend> > for adding structure to forms. So, case closed? > It doesn't say anywhere (aparently) not to use them outside <form> and > this, combined with the fact that both tags validates being outside, *this > make it possible to rethink its semantics*. > > Of course, a research on accessibility/usability regarding using fieldsets > and legends for structural markup should be done before claiming it hurts > the user experience. > Do you have facts about this affecting visitors negatively? > > Progressive enhancement is not just for sighted people. Accessibility can > and should be enhanced if possible. Ideally, accessibility should be good > (if not perfect) since the moment you start building a site, and not as an > "layer of enhancement" added later, if there is time. > > Thanks for your replies (and excuse my english). > > > [1] http://www.netrelations.se > [2] http://www.mail-archive.com/wsg@webstandardsgroup.org/msg30004.html > [3] http://www.usability.com.au/resources/source-order.cfm > [4] http://www.456bereastreet.com > > >> > >> > On Tue, May 20, 2008 at 8:44 PM, Julián Landerreche >> > <[EMAIL PROTECTED]> wrote: >> >> >> >> A workmate come with this idea, which then I have searched on web and >> >> haven't found too much information about it, but this: [1] and [2]. >> >> >> >> The idea: using fieldset and legend for adding structural markup/labes >> >> [3]. >> >> It seems that using fieldsets _outside_ forms doesn't make the code to >> >> invalidate. Also, in HTML 4.01, legend is required, but optional in >> XHTML. >> >> >> >> Currently, I like the approach of adding structural markup using a >> heading >> >> (<hn class="structural">) even just a simple <strong >> class="structural">, >> >> and if necessary, hide them by CSS >> >> I borrowed the idea from NetRelations.se and 456bereastreet.com. >> >> >> >> Example: >> >> >> >> <div id="main-nav"> >> >> <strong class="structural">Main navigation</strong> <!-- or <hn>Main >> >> navigation</hn> --> >> >> <ul> >> >> <li><a>Section 1</a></li> >> >> <li><a>Section 2</a></li> >> >> <li><a>Section 3</a></li> >> >> </ul> >> >> </div> >> >> >> >> So, applying fieldset and legend this could be rewritten like this: >> >> >> >> <fieldset id="main-nav"> >> >> <legend class="structural">Main navigation</legend> >> >> <ul> >> >> <li><a>Section 1</a></li> >> >> <li><a>Section 2</a></li> >> >> <li><a>Section 3</a></li> >> >> </ul> >> >> </fieldset> >> >> >> >> Another example: a list of actions (that are in fact, simple links, so, >> >> it's just another navigation) where it could make even more sense. >> >> >> >> <fieldset id="actions"> >> >> <legend class="structural">You can do the following</legend> >> >> <ul> >> >> <li><a>Create</a></li> >> >> <li><a>Delete</a></li> >> >> <li><a>Edit</a></li> >> >> </ul> >> >> </fieldset> >> >> >> >> Putting aside anything related to CSS styling (legends could be >> difficult >> >> to style, but aren't really difficult to hide using display:none; >> although >> >> using position: absolute; left:-9999px could be better for >> accesibility, but >> >> that positioning method on legends has inconsistencies across >> browsers): >> >> >> >> 1. Could there be accessibility issues using fieldset/legend outside a >> >> form? >> >> 2. Or could this method enhance the accessibility (in fact, structural >> >> labels enhance accessibility)? >> >> 3. Is there any other research/resource that can add some light on >> this? >> >> >> >> Thanks. >> >> Julián. >> >> >> >> [1] http://www.opendesigns.org/forum/discussion/2047/ >> >> [2] http://drupal.org/node/233928 >> >> [3] http://www.usability.com.au/resources/source-order.cfm >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ******************************************************************* >> >> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm >> >> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm >> >> Help: [EMAIL PROTECTED] >> >> ******************************************************************* >> > >> > ******************************************************************* >> > List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm >> > Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm >> > Help: [EMAIL PROTECTED] >> > ******************************************************************* >> >> ******************************************************************* >> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm >> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm >> Help: [EMAIL PROTECTED] >> ******************************************************************* >> > > > > > ******************************************************************* > List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm > Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm > Help: [EMAIL PROTECTED] > ******************************************************************* > ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *******************************************************************
