Question about Forms

HTML & CSS
21

yep, nitpicking :slight_smile:

<labels> are not compulsory. I don’t always use them with <input> and my markup still passes as xhtml strict.

Whether the code on that page passes the w3c validator will also depend on which doctype you use.

If using transitional, the only error the validator picked up in one of the sample codes is a missing “action” attribute in the <form> which in the context of the code being to demonstrate the <input> element, I can see why it was omitted.

Later on in that page where they talk about the submit button then the action attribute is included in the <form> as it should be according to the context of describing the submit button.

I’m not convinced the w3schools website is riddled with inaccurate information, as you put it, so I am comfortable continuing to recommend it to at least newbies in the future.

22

<labels> are not compulsory. I don’t always use them with <input> and my markup still passes as xhtml strict.

Neither are <h1>header text</h1> in place of
<p><strong><font size=20px>header text</font></strong></p>

BUT most of us would argue one is correct on a number of levels, while the other one is code that one should be so ashamed of that they should lock themselves up in the attic and remain there until all who know them have died off or moved away : )

Also, if you’re not using labels then you’re blocking content from users of some screen readers, because labels are form controls while plain text is not. This is why they are required in WCAG and why they were invented in the first place.

W3Cschools was incorrect about the clip property… I remember someone (Ryan Reese?) coming here confused why their code wasn’t working because instead of reading the W3C specs, they read W3schools site, which at the time said elements needed to be positioned or positioned relatively (though their code example is the same as now, with position: absolute) which they have since corrected.
This page explains more and better: http://www.w3.org/TR/CSS21/visufx.html#propdef-clip
however neither page mentions The Big IE Bug (I can understand W3C not mentioning it because they only state proscriptive, not descriptive, but W3schools should have mentioned it!): The commas make clip break entirely in IE6 and 7 (not sure about 8 or 9). Browsers remember the older, ambigious specs where commas were not mentioned and so accept it, BUT IE is the one who insists on no commas. There are a good hundred other sites who do explain this.

I would treat w3schools like wikipedia: if you need quick information that’s not necessarily accurate, you can go there, but if you need absolutely correct information, you go to the source (really, wikipedia’s real use is that there are sources, though I always get bummed to find the web sources being 404).

If using transitional, the only error the validator picked up in one of the sample codes is a missing “action” attribute in the <form> which in the context of the code being to demonstrate the <input> element, I can see why it was omitted.

If using Transitional, the font tag I used above also isn’t flagged. Transitional lets you put any type of garbage code you want on a web page… frankly I’m not sure there’s any real reason to bother validating stuff written for a Transitional doctype… maybe for mismatched tag nesting, little more.
If you’re using a Strict doctype, you cannot have inline elements directly in a form (I think HTML5 was changing this since all the HTML5 form examples I see don’t have a block child… BUT then many of the HTML4 examples also don’t have it and there they are incorrect), so either a div or a fieldset (or p’s as the old specs have it) are necessary.

After getting burned by information of a few elements on w3schools, I was shown the specs (and better sites like HTMLdog) and I haven’t gone back to w3schools… however I can’t comment on their Javascript accuracy.

23

It’s all well and good to have WCAG but at the end of the day they are guidelines and not enforceable onto everybody.

If a web page passes the w3c validator as xhtml strict, then my job is done.

24

It’s all well and good to have WCAG but at the end of the day they are guidelines and not enforceable onto everybody.

Same goes for strict validation. W3C are also but guidelines.

f a web page passes the w3c validator as xhtml strict, then my job is done.

A poor attitude for a web developer to have, but not uncommon. After all, it’s so easy to ignore a minority because, well, they’re a minority and therefore have no rights (a minority you and I will join as we age, and can join at any moment). To heck with them. To heck with usability, accessibility, or even the whole point of making the site in the first place. Which is why the unfortunate practice of “legislating accessibility” exists: people are resorting to lawsuits to make stuff work for them. Meh. Yugos do move forward, why make them any better? But hey, I get a paycheck. Let’s go fishing.

25

yes totally agree, but I choose to code in xhtml.

It’s not my attitude because it is totally up to the client, unless he/she is otherwise legally obliged, to decide how accessible they want their website to be.

I don’t provide additional accessibility for free and I am not going to bump up my fees to cater for the additional time it would take to code additional accessibility and hence force it upon my client while at the same time make his/her website more expensive if they didn’t want full accessibilty.

If a client stipulates they want full accessibility in our agreement then I am happy to provide it at the additional cost.

If the client does not stipulate full accessibility then I don’t force it on them resulting in an additional cost to them.

26

I could go along with that, if accessibility actually cost more.

It sometimes costs me some testing time, but not much. It doesn’t cost extra time coding at all (it might if I were bolting-on, but not if I’m in at the start and doing Built-in).

It sometimes costs me time researching (learning), but since that increases my value I’m not unhappy with that. The more I know, the better sites I can build.

And, this may be a matter of opinion, but I don’t see the point in building sites that are broken for some. I don’t consider it an extra thing the client has to ask for (accessibility, usability) any more than I pay extra for my car to have brakes. They should just come with brakes. And lights. And a horn. And paint on the outside. And seats inside.

Accessibility/usability isn’t the same as, say, custom leopard striping leather seat covers. That would be… goofy Javascript effects that don’t do anything helpful for users but make clients drool with happiness : )

Edit:

did I just say “leopard striping”? Good thing I’m not a zoologist

27

For me, it takes me longer to build a website that must be fully accessible and functional without javascript.

If a potential client needs full accessibility and is willing to pay for it then I am happy to spend the extra time and provide it.

Otherwise the client has the option to go to another developer who is prepared to do it for less. Either way if the client needs full accessibility, they will get full accessibility either from me or another developer.

I just don’t see why I need to provide services for free when the client has other options.

28

Typically the site should function without JavaScript first then you should charge extra to make it function with JavaScript.

Though I can understand ‘generically’ by what you mean that clients can be completely ignorant. Most clients would usually rather go for cheaper services over quality so long as it “looks nice”, and “seems to work”, etc.

29

Most clients would usually rather go for cheaper services over quality so long as it “looks nice”, and “seems to work”, etc.

add “in Internet Explorer 7 on Windows XP with scripts on and Flash installed”.

which is better than “in Internet Explorer 6” by a hair : )

30

Maybe its because my office is required by law for all web pages to be accessible, but I’m so used to building accessible pages that I don’t consider it extra work. In fact I consider it a best practice.

31

In an ideal world, yep totally agree :agree:.

But my main aim is to keep the cost to the client down to a minimum and since I can build a website faster and cheaper with javascript, then that is what I do by default unless the client specifies he/she requires functionality/accessibility without javascript which I charge extra for due to the extra work for me.

32

Lovely conversation, but one that has nothing to do with my original question…

TomTees

33

It’s not uncommon in threads where the original question has been answered for the topic to spin off on a tangent.

34

And that it has! :wink:

TomTees

35

yep, it was pretty well answered back in post 14 :nod:

36

In a Utopian world yes, in the practical world no. Generally using JavaScript to achieve certain functionality breaks the natural flow of non-persistence. Take linked select drop downs for example. The only way to support that in a none persistent environment is to have the user know to hit the submit button each time. Supporting certain types of functional requirements in a persistent and non-persistent environment many times requires two very separate forms of logic, thus time, thus money. I do what I can, but with JavaScript becoming such a large piece of enhancing user experience through a persistent environment many times is more trouble than what it is worth. I guess you really don’t have to deal with the issue that much if your not working directly with user input that is were most the issues come into play. Trying to make a form that is AJAX heavy non-persistent normally results in a convoluted mess, unless you redesign the entire flow for a non-persistent web experience maintaining two separate versions of the same thing. I think most users would agree that they rather have a persistent experience than one with constant refreshes and that is were JavaScript becomes a significant and many times functional requirements that just can’t really be replicated in the non-persistent environment unless the logic is entirely changed. With most major sites such as; Facebook relying on JavaScript to achieve functional requirements I think its less of a problem than it us to be. You can only go so far with graceful degradation before it becomes wasted expenses based on the target market. Otherwise, your just flushing money and time down the toilet, for a few small minority of people who may never even view the site or use the application.

37

totally agree :agree: