Re: [WSG] Fwd: using fieldsets and legends (outside a form) for adding structural markup

[David Dorward]

On 22 May 2008, at 05:15, Julián Landerreche wrote:

I wasn't convinced at first because:
- fieldset/legends are used in forms to group controls. This is  
common usage/practice, and even more, it's the usage recommended by  
the W3C, as some of you already remarked on this thread, .ç


Yes, that is what fieldset is designed for.


I wasn't convinced by counter arguments because:
- this isn't a CSS/JS issue. In fact, the idea is to have it as  
structural labels/markup, that will be probably invisible for  
sighted users. I'm not trying to achieve something fancy, although I  
have said that fieldset+legend looks fine, and more important,  
helpful for users when CSS is "disabled"  (browser default CSS)


Most of the arguments against it (at least those which haven't been  
shot down already) were about semantics, not CSS or JS.


And also, not convinced because of this other reasoning (hope it's  
not a fallacy):

- if it validates (true)


So do layout tables. DTDs can't describe the language in /that/ much  
detail.


Eye halve a spelling chequer
It came with my pea sea
It plainly marques four my revue
Miss steaks eye kin knot sea.


and
- if the W3C doesn't explicitly says anything about not using  
fieldset/legend outside forms (¿true?)


They don't say you shouldn't use  to indicate the start of a  
new paragraph either.


If the spec explicitly listed everything you shouldn't abuse markup  
for, it would be huge. Tables are an exception due to the widespread  
abuse they had when the spec was written.



then
-> it could be used to add semantics or meaning in a new way outside  
forms.


If that meaning is "These controls should be groups, and here is their  
caption".


Let me add other real-world examples of using/combining HTML  
elements/attributes to create new semantics, all well known by us:

- ul > li > a  = a navigation menu


The semantics there are no new. A navigation menu is a list of links.  
This is just using the right markup for it.




- div + abbr + span + predifined classes = microformats  (chunks of  
HTML with added meaning). As Jason stated above: "s are for  
separating components/sections of a page and can be semantically  
very strong, especially when given a meaningful class or id name"


Microformats take some markup that is *correct* for a given pattern of  
content, add some class names and then document the pattern.


Probably, at first, nobody though that by combining an unordered  
list of items with links could be "seen" as a navigation.


The table of contents on the HTML 4 spec uses lists. So the idea has  
been around for a long while.


In fact, before the Web Standards mindset change, not too many  
people were doing nav menus that way.


No, they were using tables because the liked the way they rendered in  
browsers.


And that's probably my point: trying to add new semantics and better  
accessibility with current HTML elements.


The closest you can come to adding new semantics is agreed sets of  
class names, which isn't a very good way, but was about the only  
option open during the days when HTML wasn't being developed.


What you are suggesting is taking old semantics and using them even  
though they don't fit. Fieldsets group controls and their labels. You  
can't just throw away all but the first two words of that.


--
David Dorward
http://dorward.me.uk/
http://blog.dorward.me.uk/




***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Fwd: using fieldsets and legends (outside a form) for adding structural markup

[Julián Landerreche]

Although since the beginning I wasn't convinced (that's why I started this
thread) about using fieldset/legend for adding structural labels to
non- content (particularly, "action" links or "site nav" links), I'm
still not convinced by exposed counter arguments against using it.

I wasn't convinced at first because:
- fieldset/legends are used in forms to group controls. This is common
usage/practice, and even more, it's the usage recommended by the W3C, as
some of you already remarked on this thread, .ç
- couldn't find any research nor articles in favor or against this practice,
particularly, when it concerns to possible issues on accessibility.

I wasn't convinced by counter arguments because:
- this isn't a CSS/JS issue. In fact, the idea is to have it as structural
labels/markup, that will be probably invisible for sighted users. I'm not
trying to achieve something fancy, although I have said that fieldset+legend
looks fine, and more important, *helpful* for users when CSS is "disabled"
(browser default CSS)

And also, not convinced because of this other reasoning (hope it's not a
fallacy):
- if it validates (true)
and
- if the W3C doesn't explicitly says anything about not using
fieldset/legend outside forms (¿true?)
then
-> it could be used to add semantics or meaning in a new way outside forms.

Let me add other real-world examples of using/combining HTML
elements/attributes to create new semantics, all well known by us:
- ul > li > a  = a navigation menu
- div + abbr + span + predifined classes = microformats  (chunks of HTML
with added meaning). As Jason stated above: "s are for separating
components/sections of a page and can be semantically very strong,
especially when given a meaningful class or id name"

Probably, at first, nobody though that by combining an unordered list of
items with links could be "seen" as a navigation. In fact, before the Web
Standards mindset change, not too many people were doing nav menus that way.

And that's probably my point: trying to add new semantics and better
accessibility with current HTML elements. Of course, if the fieldset/legend
*really* hurts accessibility, print this thread, delete it and burn the
printed copy to ashes.



@Ted wrote:

Go for the header and div. it's semantic and the header gives screen readers
> (and Opera) something to navigate with.


Probably this is the most common way of doing it. But we all know the
problems that arise when using headings: it's pretty hard to establish with
level of heading should go for different navigational/secondary content on a
page.
If we think and rethink a webpage as a document, I really doubt that a
navigation menu, or a "skip to" menu, or even the footer deserve a heading.
Haven't you ever think that you were mis-using or wasting headings for the
sake of semantics?

If we take a look to manual/scientific books (a kind of document, probably
the "parent" of a web pages), there are sometimes notes or boxes with little
complementary content on the margins of the page. Although most of the
times, they are marked up as a heading and a little paragraph, I've seen
also some of this side notes as fieldset+legend+content.
I'm not trying to say that fieldset/legends could be used to mark side
notations of an article on webpages.
Again, the primary use I can think is about adding structural labels.

Hope someone could do further research regarding usability/accessibility,
which is what should decide the benefits or cons of this proposed practice
and what could lead us to have better common practices with current set of
HTML elements.

Thanks.

On Wed, May 21, 2008 at 7:53 PM, Jason Grant <[EMAIL PROTECTED]> wrote:

> Hi Julian,
>
> One more subtle point here (after taking this discussion into the office
> with guys that work with me) a point was made today that within DOM
>  is part of the  hence you cannot reference a 
> through DOM unless it is inside a , so it is definitely a wrong
> approach to use it in that way, especially if you want to do fancy
> JavaScript stuff with it all.
>
> Hope this helps.
>
> Regards,
>
> Jason
> www.flexewebs.com
>
> On 5/21/08, Thierry Koblentz <[EMAIL PROTECTED]> wrote:
>>
>> > So, there were a number of sites that began using fieldsets and legends
>> outside of forms.
>> > You may still find documentation talking about how nice it is to work
>> with. Unfortunately,
>> > fieldsets and legends are only for forms and you shouldn't use them
>> otherwise. I've actually
>> > been dealing with this recently in the zemanta firefox plugin. This
>> inserts a fieldset with
>> > a list of links for adding related content to blog posts. I logged a bug
>> and they'll fix it
>> > in a future release. But it just goes to show this is a commonly misused
>> pattern.
>>
>>
>> People were also using fieldsets simply because they contain floats
>>
>>
>>
>> --
>> Regards,
>> Thierry | http://www.TJKDesign.com
>>
>>
>>
>>
>>
>>
>>
>> ***
>

Re: [WSG] NoScript Help Please!

[Jeffrey Lowder]

Hi IceKat

If javascript is required for the link - then write/append it to the  
page using javascript - then if javascript is being used - no link


Cheers
Jeff


On 22/05/2008, at 1:31 PM, IceKat wrote:


Hi,

Thanks to those who have replied so far. I'm still a bit lost  
because this has gotten a bit more complicated so I'll explain a bit.


I have a page which lists records in a mysql database. They each  
have varying options including delete. They are printed with a php  
loop. The table of records is in a form and the delete button has in  
fact become a input type=image which posts some data back to the  
page with a javascript return confirm. The posted data is then  
excecuted. The php and mysql is fine but the javascript is doing the  
confirming which means that if it's turned off then there is no  
confirmation of the delete. This is the reason why I am trying to  
put in a regular image with a link to another page which only  
appears if javascript is disabled.


I know this isn't a JavaScript help page but I'm hoping that someone  
will understand my babbling because I'm having trouble getting this  
to do what I need and validate my page at the same time. The first  
solution posted by Michael seemed good until I realised it was  
actually an input type=image that I needed (sorry about that). The  
solution below seems to do what I need but the complexity of the  
javascript makes me feel cold.


Can anyone either mail me directly to save clogging up this mailing  
list or point me to a place where I can learn what I need? Does  
anyone know a good javascript forum?


Many Thanks,
IceKat

David Dorward wrote:


Three issues:

1: A start tag starts an element, an end tag ends an element, and  
elements must be contained entirely within other elements.


2: noscript is a very poor means of handling the 'no js case', it  
doesn't cope with 'JavaScript supported, but not the functions you  
are calling'


3: Links make GET requests, and GET requests shouldn't do anything  
significant to the server (like deleting files). People have run  
into problems with precaching proxy servers following all the links  
to get the content available for users and deleting lots of files  
as they go. For changes to the server, use POST.


I would do something like this:


 
   
 


And then:

http://yui.yahooapis.com/2.5.1/build/yahoo-dom-event/yahoo-dom-event.js 
">


 function deleteFiles(e, obj) {