rulururu

post Single or double quotes for HTML attributes?

February 18th, 2007

Filed under: Code, HTML/CSS, PHP — Brenton Alker @ 23:02

The issue of whether to use single quotes or double quotation marks in HTML attributes is a topic that has been somewhat debated for some time now. The reason there is debate is due to the differences in, and the leniency of the relevant standards or recommendations. So here’s my take.

The W3C’s HTML 4.01 Recommendation allows the use of either single or double quotation marks and in certain cases no quotation marks are required at all.
To quote the recommendation:

By default, SGML requires that all attribute values be delimited using either double quotation marks (ASCII decimal 34) or single quotation marks (ASCII decimal 39). Single quote marks can be included within the attribute value when the value is delimited by double quote marks, and vice versa. Authors may also use numeric character references to represent double quotes (") and single quotes ('). For double quotes authors can also use the character entity reference ".
In certain cases, authors may specify the value of an attribute without any quotation marks. The attribute value may only contain letters (a-z and A-Z), digits (0-9), hyphens (ASCII decimal 45), periods (ASCII decimal 46), underscores (ASCII decimal 95), and colons (ASCII decimal 58). We recommend using quotation marks even when it is possible to eliminate them.

XHTML1 is a little stricter, saying that all attribute values must be quoted, even those which appear to be numeric, but (as far as I can tell) still allows the use of either quote.

While I am all for flexibility in standards, it can and does lead to inconsistencies between developers, projects and even within the same document.

This inconsistency is not a problem for the majority of (especially static) X/HTML documents. Even though double quotes are recommended, the choice is essentially inconsequential, and may be influenced by factors such as personal preference or the contents of the value being quoted (because single quote marks can be included within the attribute value when the value is delimited by double quote marks, and vice versa).

It does become more relevant once dynamic pages are introduced, mainly due to the uncertainty of the value within the quotes (which can be a deciding factor in the choice, as mentioned above). In this situation I strongly advocate the use of double quotes. Let me explain why with a simple example.

Imagine a template, used in a dynamic web page, that displays a form to allow some data to be entered or edited. With single quotes, an example in PHP may look like this:


<form …>
<input type='text' name='name' value='<?php echo $name ?>' />
<input type='submit' value='Submit' />
</form>

This would work fine in most cases, but consider the case where the $name variable contains an apostrophe such as in "O’Brien". The resulting HTML would look like this:


<form …>
<input type='text' name='name' value='O'Brien' />
<input type='submit' value='Submit' />
</form>

This would obviously cause problems with the display, causing only an "O" to be displayed inside the text field (not to mention invalid markup). Of course, you could run the value through the PHP’s addslashes() function, and the problem would be solved. But addslashes is one of those functions I try to use very sparingly, it has a tendency to bite you by adding slashes where they are not intended, such as before slashes intended to be escaping other characters. Instead, I prefer to use double quotes around all attributes, like so:


<form …>
<input type="text" name="name" value="<?php echo $name ?>" />
<input type="submit" value="Submit" />
</form>

The advantage is that, by passing the variables through a htmlentities function (or equivalent). This will convert any double quotes in the variable to the HTML entity "&quot;", preventing the reverse of the problem described with "O’Brien" and ensuring the markup is going to be valid and the value is as intended. This only works for double quotes because there is no standard HTML entity for single quotes (The ASCII code can be used, and &apos; is supported in some browsers, but these aren’t as widely supported as &quot;).

On the surface, the approach of converting the HTML entities may appear to be no better or worse than the method of escaping the single quotes with addslashes. The advantage is, converting the HTML entities will also account for other characters that should be converted as well, for example the ampersand (&) that, while they may not cause the page to fail to function (most browsers will compensate), will render the HTML invalid if not converted. As such, this conversion would need to be done even with the escaping using slashes, so why use both? Taking this into consideration, I have yet to find a good reason for using single quotes (at least if the value contains dynamic content).

So that’s my vote, and my reasoning behind it. Vote 1: Double quotes for attribute value delimiters.

post Priority When Multiple CSS Classes are Applied

November 3rd, 2006

Filed under: Code, HTML/CSS, Javascript — Brenton Alker @ 16:16

I’ve used multiple CSS classes applied to an element on many occasion, but never run into the problem I found today. It seems counter to the CSS system as I understand it, but I’ve checked it out and it works like this.

I had a page, who’s table cells all had a CSS class that applied a background colour, some font attributes and what have you.
The class (from an external stylesheet file):

td.listCell
{

color: black;
background-color: grey;

}

was applied individually to each cell like:

<td class="listCell"></td>

I needed to apply a second class on certain cells to change the background colour, this is part of an on-page Javascript search. This page has lots of content, a large form, most of which is hidden and only small parts are used at a time. The search is supposed to highlight the cells that contain the text in the search field.

So, I added a searchHighlight style to the head of the page, making it look like:


<head>

<style type="text/css">
.searchHighlight { background-color: red }
</style>
<link rel="stylesheet" type="text/css" href="stylesheet.css" />
</head>

On my way I went, coded the javascript to search the table and add the ’searchHighlight’ class to the cells that needed hightlighting. Easy. Except it didn’t work.

When the Javascript found it’s target, and changed the class (by appending searchHighlight to the className) nothing happened. I checked the Javascript had worked, using my trusty FireBug source inspector. It had. So why no change in the style?

I changed the Javascript to replace (instead of append) the searchHighlight class, that worked, except it lost all it’s normal formatting, which I was almost willing to put up with, but not quite. I tried pre-pending the searchHighlight class (hoping the styles were in priority order), but to no avail.

So I created a simple test page, to make sure I was wasn’t going (more) insane, and that multiple CSS styles ever worked.
The test page looked like this:


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<title>Multiple CSS Class Test</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></meta>
<style type="text/css">
.normal { font-weight: bold; background-color: red;}
.special { background-color: blue }
</style>
</head>
<body>
<div class="normal">class=&quot;normal&quot;</div>
<div class="special">class=&quot;special&quot;</div>
<div class="normal special">class=&quot;normal special&quot;</div>
<div class="special normal">class=&quot;special normal&quot;</div>
</body>
</html>

The results are sort of what I expected… the top div (normal) is red and bold, the second (special) is blue and not bold, the other two are applying both, but the order of the classes in the list doesn’t matter. So they are getting the bold from the normal style, and the background from the special style.

Great. So why didn’t it work in my application? I finally figured it out. If, in my test, I reversed the order of the declaration of the styles (so that ’special’ is declared first) and the results are very different, the ’special’ class is ignored completely.

That’s right, the styles are applied in the order they are declared in the document, the order they are listed in the element has no effect. That I now understand (although I didn’t know it previously). But what I find more suprising, is that the order of stylesheets files that are linked is also subjected to this hierachy.

For example, if (from my test page) I remove the special style, and put it in an external style sheet, and include it like so:


<style type="text/css">
.normal { font-weight: bold; background-color: red;}
</style>
<link rel="stylesheet" type="text/css" href="stylesheet.css" />

It works, but doing this doesn’t:


<link rel="stylesheet" type="text/css" href="stylesheet.css" />
<style type="text/css">
.normal { font-weight: bold; background-color: red;}
</style>

So the include is exactly the same as typing in the style in the file. Whereas I was under the impression that styles in the file took precedence over those in external (linked) stylesheets (where they overlap of course). But it seems I was wrong. Now I know.

ruldrurd
Powered by WordPress, Web Design by Laurentiu Piron
Entries (RSS) and Comments (RSS)