Big Red Tin » xhtml

Forms are forms, not lists

Peter Wilson — Thu, 02 Dec 2010 00:00:04 +0000

Respecting someone or their publication does not prevent one from disagreeing with them. In fact, I think to nod along saying “you’re so right, OMG, you are so right!” is less respectful than listening to and considering what they say. That dealt with, allow me to disagree with some people I respect.

Frequently, I see HTML forms coded as lists. I’ve seen this in code by some publications and people I highly respect, such as on A List Apart. The code may be:



  
    Item One
    
  
  
    Item Two

The method remains much the same if using unordered or definition lists. The argument for using this method is that forms are a list of fields. A variation is to use a table, arguing that forms are a table of labels and inputs.

I don’t believe either argument is correct, I believe forms are a series of:

fieldsets;
legends;
labels;
buttons;
inputs, selects, options, etc.

All semantic meaning for forms should come from the appropriate HTML tags. If you want to use other elements as hooks for styling, they should be semantically meaningless spans and divs.

I consider the arguments cited above as justifications for making styling easier. Without block elements, forms can be difficult to style. Rather than wrapping each input pair with a list item, I wrap them with divs.



  Item One

Wrapping each input pair in a div is just as lazy as wrapping each input pair in a list item. However, as divs are meaningless, it doesn’t require bending of semantics to justify my actions.

There is a valid argument for an element to define an input pair but I think such an element is redundant. We already have a method for defining the pairing of labels with their inputs. The “for” attribute within the label pairs with the “id” attribute of the associated input.

If you wrap your forms in a list or a table, look carefully at what you are doing. Ask yourself; is what you are doing semantically valid or are you lazily trying to make styling easier? As context for your consideration, ask yourself if a whole page of text is really just a list of paragraphs.

Valid Isn’t Best Practice

Peter Wilson — Wed, 09 Jun 2010 00:30:09 +0000

Not long ago, on the @soupgiant account, I tweeted:

While neither the xHTML nor the CSS on this site validates, we consider it to observe best practices.The HTML fails validation due to the following problems:

One of the WordPress plugins we use on the site inserts JavaScript with unencoded ampersands in the URL. This isn’t a best practice but unfortunately it’s beyond our control;
The tag has a class attribute;
Two of the fields in our comment form have an unrecognised value for the type attribute.

The CSS fails validation due to the following problems:

We load the YUI 2.7.0 CSS reset, base and fonts files from the Google AJAX API servers. These files contain star hacks for IE targeting;
We use browser extensions to implement CSS rounded corners and rgba backgrounds;
Until I started writing this post, we styled a heading with font-size: 145.4545%%.

That last one was a typo, and has since been fixed.

Justifying the invalid CSS

We’d prefer to avoid the star hacks in YUI’s CSS. If we self-hosted the files they’d be moved into the CSS files with our other IE specific hacks and targeted with conditional comments. Our compromise is to load the files from Google’s server with the aim that our site will load faster. Either the user will already have the files in their browser cache, or the user will load the files from a closer, faster server on Google’s global network.

The W3C’s CSS validator also screams at us for using CSS3 browser extensions and rgba backgrounds. While the browser manufacturers are still trying out their implementations of the new specs, we’ve no choice but to use these for the time being. As they iron out their implementations and move them over to the specified properties we can remove these. CSS3 junkies could probably have skipped this paragraph.

Justifying the invalid HTML

This site uses xHTML. We’ve discussed using HTML5 but WordPress, which powers Big Red Tin, isn’t ready to drop the /> from self closing tags. At this stage the HTML5 spec is too dynamic for our liking. Have a late afternoon snooze and the spec is likely to change during your siesta.*

Depending on your point of view, and even what you are coding, it is either fortunate or unfortunate that browsers don’t always follow specs to the letter. We’ve taken advantage of that to throw one of the biggest advantages of HTML5 into our xHTML. In our comments form, we’ve used HTML5 type attributes for two of our fields: and .

In browsers that do not support these types of inputs the type falls back to the standard of type=”text”. In browsers that do support input types of email and url, it prevents the user from entering an erroneous value. For users of the iPhone or iPad, a special keyboard is presented to make entering an email address or URL easier. In browsers that support the new HTML5 input types, the behaviour is identical regardless of the doc type.

The iPhone displays different keyboards for HTML5 input types

It may be breaking some of the rules of standards. To me it’s not so much about standards as best practices and giving the user the best possible experience on a site, even if this means breaking the rules sometimes.

Don’t take that to mean that we’ll be reverting to table layouts, or insert code such as

`Heading`

into our xHTML. It’s bending the rules around the edges, which is no different to using vendor prefixes to make use of CSS3.

*Yes. I know this is an unfair characterisation. A lot of very important people, with very important lawyers, are working hard to change this.

Why I will not be dropping support for IE6

Peter Wilson — Wed, 07 Jan 2009 01:30:58 +0000

Increasingly I’m reading of web developers deciding to drop IE6 from their list of supported browsers, usually, because of its creative interpretation of CSS standards, besides IE7 is over a year old, and, IE8 about to be released.

I’ve decided to continue support for IE6 as it’s still in wide use – especially in corporate environments – and, I don’t think it needs to take a lot of work to develop for. I’ll say that again, I don’t think IE6 is as bad it’s sometimes made out to be.

IE6 is the difficult child of the browser family – but like most difficult children, with the right tools it can be made to behave. IE7 is better behaved than IE6, but let’s not fool ourselves, it’s not the glowing example of a perfect browser, and requires hacks of its own.

Standards Mode

The best tool to reduce IE6‘s development time is to move the browser out of quirks mode and into standards mode using an appropriate DOCTYPE, and, leaving off the XML declaration; I code in XHTML Strict, so my files begin:

In standards mode the browser will inherit font styles within tables, use the W3C box model and vertical alignment defaults.

Comments

Create a standard comment format for your main CSS file which you can use when you know you’re going to have to write a hack for the IE6 style sheet, such as /*HACK ie6 ... */; rather than flicking between your main and IE6 style sheets during standards development, you can just search for hack comments during non-standards development.

#someDiv {
min-height: 300px; /* HACK ie6 - height: 300px */
float: left; /* HACK ie6 - 3px jog (adjacent), zoom: 1 */
}

Surprises

Once you’ve specified the DOCTYPE, and, repaired known hacks, IE6 is likely to surprise you with a few more creative problems, positioning, an extra few pixels here and there and other little tricks; but by ruling out the obvious in advanced, overall debugging will become less time consuming.

As I said above, IE7 requires its own set of hacks. If browser specific debugging is required anyway, I don’t think it’s overly time consuming to continue support for IE6.

Links opening in new windows

Josh Kinal — Tue, 08 Jul 2008 07:23:57 +0000

Yes I have firm views. Take that as a given. Since long before I could code, however, I’ve always been critical of websites that open their links in another window.

Back in the days before browser tabs, a whole new window would open either above or below the window you were currently working on. It was terrible and unstoppable. People kept up this practice because they thought it was a good way to get a user to keep their website open. It was seen as an audience retention device.

The browser belongs to the user. The website belongs to the creator. The website should not perform any actions on the browser that the user cannot control. That should almost always be the situation.

By keeping things uniform we can set expectations with the user that links will always open in the same window and if they want to open the link in another window they have options like middle-clicking or context-menus.

Of course there are exceptions to this. Banks often open up a separate window for logging in and doing actual banking because they can ensure an extra level of security if, when logging out, they can close the whole window.

The best way to keep a user coming back to your site is to have compelling content. They can always come back by pressing the back button if they meant to open in a new window but forgot.

Another problem with opening links in new windows comes with reporting. Reporting and analytics is another post for another time but many people still use the metrics of a visiting time. The time a user stays connected to a site become a dirty statistic if they actually navigate away from the page but it stays open in a seperate browser window. The website owner doesn’t really have an indication of how useful/entertaining/compelling their site is, all they know is they could fool some script into thinking that people were still there even when they weren’t.

These are just some thoughts. Many theories abound in any workplace so I’m sure yours has some too. Feel free to let me know in the comments.

UPDATED: This post was inspired by a discussion, in turn inspired by an article in Smashing Magazine.