HTML 5: WHATWG versus W3C

March 8th, 2007 by Robert

The new W3C HTML working group launched. The charter states that they’ll attempt convergence with the WHATWG’s recommendation. I remain a little confused with how the browser vendors will handle this.

My main concern comes from the WHATWG’s lack of DTD specification in the DOCTYPE. WHATWG proposes that HTML 5 use <!DOCTYPE html> as the DOCTYPE because browsers don’t care about DTDs. The only reason they include a DOCTYPE is to alert browsers to use standards mode (and DOCTYPE isn’t used in HTML 5 if the page is sent as XML). I think this was short sighted.1 WHATWG is essentially forking HTML. They made the false assumption that there would be no competing HTML standard. Since browsers would implement WHATWG’s HTML 5, they could take shortcuts. If the WHATWG can fork it, anyone else can.

Now there is a competing standard in the works from W3C. The W3C charter suggests that the W3C HTML Working Group will try to converge with the WHATWG’s HTML. They key word is try. They didn’t promise compatibility.

Can there be standards with multiple varying recommendations? I think so. That is what DTDs are for. The designer can even write his own DTD if he would like to define his own elements. This isn’t typically done, but it can be. WHATWG’s reasoning is that HTML 5 is no longer an application of SGML, but defines its own syntax. That’s all well and good, but DTDs at least gave us a way to determine what version of HTML to use, even if it was for our own personal standardizing. Declaring the use of the HTML 3.2 DTD, no matter what version of HTML the browser actually renders against, guarantees that the author attempted to make an HTML 3.2 document. If any problems are introduced (e.g. depreciated elements), at least it isn’t the author’s fault. After all, this standards thing is, in part, about future proofing and there is something to be said about not being on the bleeding edge.

The problem is that if the W3C departs from the WHATWG’s recommendation and agrees to the lack of DTD, there is no way to pick which version of HTML 5 you want (WHATWG’s or W3C’s). If there was some way to sniff DTDs, the designer could tell the browser which to use. WHATWG has ruled that out because, currently, browsers don’t care about DTDs / HTML 5 is not SGML.

Once upon a time, browsers didn’t care about DOCTYPE (as far as I know). When it became necessary to differentiate between standards mode and quirksmode, the DOCTYPE became important. If it becomes necessary to differentiate between versions of HTML 5, browsers may start to care about DTDs.

I imagine the reply to my concern would be, Browsers will support both recommendations, ultimately resulting in a better hybrid implementation of both WHATWG’s and W3C’s recommendations. This reasoning would work if, for example, WHATWG supported the footer element and W3C did not. The designer could still use the footer element, even though it technically isn’t part of the traditional web standards view (that is, the W3C created standards), and have global browser support (e.g. innerHTML in JavaScript is supported across all browsers, even though it isn’t in the ECMA standard2). However, this isn’t ideal. There are reasons to use particular recommendations (e.g. future proofing and avoiding proprietary elements). For longevity, picking a particular recommendation and sticking to it would be good practice, even if browsers supported the hybrid model. For argument’s sake, however, using the hybrid model in this instance isn’t problematic.

The problem will come when the two specifications differ on how to implement a particular element. While it is not the exact same case, compare the Internet Explorer box model to the standard box model. If, for example, WHATWG described something like the Internet Explorer box model, and W3C described something like the standard box model, how would the browser know what to choose? It wouldn’t unless it sniffed the entire DOCTYPE tag. Assuming the W3C keeps the DTD, a special case would have to be coded for WHATWG’s HTML that says something like, If there is a DOCTYPE but no DTD, assume it is the WHATWG’s version of HTML. Again, this isn’t ideal, but it would work. If W3C decides that the DTD isn’t necessary either, there would be no way to determine what the author wanted to use, resulting in a great deal of confusion.

Again, some may reply, Browsers will support both recommendations, ultimately resulting in a better hybrid implementation of both WHATWG’s and W3C’s recommendations. Presumably, this would eventually trickle up to the two recommendations resulting in normalizing the two documents. Again, I’ll reference the box model. The Internet Explorer team implemented the box model one way. Everyone else implemented it the other way. It was years before the two became congruent (if they even are yet). Until the two documents become normalized based on browser implementations, there will be confusion and incompatibility (aka instability). Further, it has never been a good idea for browser makers to decide what should be standard. If it were, we may have both LAYERs and DIVs. We’d have proprietary filters in our CSS and parts of CSS 2 would have to be axed completely because browsers don’t support them. It’s the job of the standards body / bodies to tell the browsers what they ought to do. It’s not the job of the browser implementation to dictate what standards ought to be.

Simply put, I’m worried about how WHATWG’s HTML and W3C’s HTML will interoperate. It could easily work out, but there could be problems just as easily. Luckily, WHATWG’s HTML isn’t a final recommendation and W3C hasn’t started yet. These problems can still be worked out.

  1. This might be an unfair statement. They might not be short sighted. They might be looking out for developers by making it easier to use DOCTYPE. This is noble, but ends up being a problem if I’m right. The other explanation is that the WHATWG is arrogant and believes it is the only version of HTML that matters. If we were talking about the W3C, I might suggest this was the case. I’m hoping that the WHATWG doesn’t pick up on the W3C’s bad habits. I’m giving them the benefit of the doubt since I have a lot of respect for many of the members.
    ↩

  2. This was proclaimed by Douglas Crockford in his talk called An Inconvenient API: The Theory of the Dom that can be seen via the Y!UI blog.
    ↩

Tags: , , ,
Posted in Meta | Comments Off

PHP Documentation Generators

February 15th, 2007 by Robert

I’ve been looking at documentation generators recently. Specifically, I’m playing with a new website that I want to do Right. Here are some notes for anyone looking at PHP documentation generators.

Languages

I needed a documentation generator primarily for PHP. However, I thought it’d be nice if it’d create documentation for JavaScript as well.

Possible Options

  1. PHPDocumentor

    Formerly called PHPDoc, PHPDocumentor was my first choice because I’ve heard of it before. It’s based on JavaDoc, and is conveniently packaged in PEAR. The syntax is a little weird at first, and documenting blocks of code inline doesn’t seem to be possible. However, it figures out a lot of useful stuff. PHPDocumentor, of course, doesn’t work with JavaScript. Despite the lacking feature, this is document generator I implemented.

  2. HeaderDoc

    HeaderDoc is Apple’s documentation system. It works with both PHP and JavaScript (as well as several other languages). I browsed the documentation, but haven’t bothered downloading the PERL code to compile it. I skipped on it because it seems far too robust (that is, bloated) for what I need and lacked some of the niceties of PHPDocumentor (e.g. detecting function names).

  3. Natural Docs

    I was really excited about Natural Docs when I first heard about it. The syntax seemed easy and it was supposed to understand inheritance, which would be a boon for JavaScript. Unfortunately, JavaScript and PHP are only supported insofar as they can be read in the document. No nifty features like they have with ActionScript, PERL, and C#. Too bad.

  4. Others

    I briefly looked at a few others that supported PHP and JavaScript. RoboDoc has fugly syntax and TwinText is supposedly Windows only (assuming it existed). Neither were going to be right for me.

PHPDocumentor in Use

Install

As I mentioned, PHPDocumentor is a PEAR package. That made the install very easy. I actually overcomplicated it quite a bit because of a few errors I had with the script. For future reference, you want to run pear install PHPDocumentor-beta since PHPDoc is depreciated. One will override the other.

As I said, when I tried to run phpdoc, I got an error about a file missing. Mac OS X apparently stores files in different places than the package expects. So, I had to edit the package and add chdir("/usr/lib/php/"); so that include("PhpDocumentor/phpDocumentor/phpdoc.inc"); would be run in the proper directory.

Since I wanted to have my documentation as a sub directory of my site, I had to write a shell script to clean out my documentation folder then run the PHPDocumentor command. Otherwise, PHPDocumentor would attempt to document the documentation.

Learning

I was a little bewildered by the syntax at first. This is mainly because it’s really hard to find solid examples of how to document code. The manual provides a little bit of instruction, but lacks real world examples. Luckily, I found a good example in the PEAR coding standards documentation. It wasn’t long until the syntax was second nature.

The only real gripe I have is that I’d like to be able to make inline comments about specific blocks of code. For example, a switch. It turns out that you have to do that within the function discussion. You can print code blocks in the discussion area, however. So, it’s almost as though you can do inline documentation.

I also should note that @var can only be attached to a class variable declaration, not any variable at all.

Output

I struggled with the output. I hate frames. So, I used the Smarty layouts for output at first. Eventually, I switched to the default frames layout because it handled some of the output better (e.g. unordered lists in discussions). Otherwise, it makes nice legible documentation that can be read on a web browser. It can also output PDF, and Windows Help files.

Final Opinions

PHPDocumentor is a pretty nice tool. Not only does it create documentation, it introduces a standard for commenting that is very legible. While I wish I cold have found a JavaScript and PHP document generator that I was happy with, PHPDocumentor does its job well.

Tags: ,
Posted in Web Development | Comments Off

How To Do Modern Web Design

January 12th, 2007 by Robert

I’ve been trying to figure out the best way to explain how to do modern, semantic, standards compliant web design. I’ve been trying to make the point to my current protege that one should first look at a website like a term paper and move on from there. I’ve formulated a method now that I’d like to outline.

I once described how I see web design as a left brain plus right brain task. However, a new A List Apart article called Grok Web Standards breaks it down even more, suggesting that a web designer must think like a writer, artist, and engineer. The article inspired me to write the steps I think web designers should take to making a site.

I must say now that I seriously doubt anyone will ever work this way. It relies on the idea that content is given to the designer first. Rarely, if ever, will a client give you content without seeing a design. This is unfortunate because the goal of a website is to communicate a point. Looking pretty is the icing. You won’t be able to bake a cake without letting the client taste the icing first until you have a very good reputation. However, I hope my steps are written well enough that, if need be, designs can be done first.

How To Do Modern Web Design

  1. Understand Your Content

    Content is king. Before you touch an editor, read your content and understand it. Once you understand what you want to present, it becomes easier to mark up and will give you ideas on how you want to present the content to the user. Make a mental outline of what is in the content to help make decisions. To be clear, content does not just mean the text on the page. Content includes navigation and footer information as well as regular page content and images.

  2. Format Your Content

    The first goal of a site (web apps excluded) should be to present a message in a clear manner. The best way to do this is to make sure your markup is structured and semantic. I like to think of it as manually marking up a term paper or essay. Term papers must be clearly arranged and defined in logical sections. Lists should be presented as lists, paragraphs as paragraphs, and headings as headings.

    Every designer should have some boilerplate to work with. That is, having a very simple HTML template with basic elements (e.g. DOCTYPE, head, title, body, and any other basic elements you usually work with) will save you a few minutes up front and allow you to get down to business. Smultron, for example, has this built in. If you don’t, write a basic, empty HTML document. Don’t include stylesheets yet.

    To qualify the previous paragraph, boilerplate is only really needed if you want to validate as you go. If you trust your ability to write valid disembodied markup, just bang out the markup in a text editor without the rest of the code. It’s how I’m writing this post since it’s going to be injected into a design that has the rest of the code. In the end, you might save some time by not using boilerplate (e.g. if you have tons of pages that will need extra elements inserted during step four below). For the beginners, though, understanding the document structure will be more useful than the time saved by skipping out on it.

    Your task is to turn your content into something logical, legible, and semantic. Use your understanding of the content to create a document. Based on your mental outline, use headings with the correct level (typically the document title should be the first level heading, for example), lists, paragraphs, blockquotes, tables for tabulated data. Give emphasis, citations, and hyperlinks. Front load your lists if you need to. Don’t use divisions, fonts, or styles. Do rely on the browser’s built in formatting. Default styles are well thought out by the browser maker. You just want to make sure your content makes sense. Yes, it looks boring, but it also looks clean. When you view your document in a browser with no stylesheets, it should make sense when you try to read it.

  3. Design For Your Content

    By now, you should be pretty intimate with the content. You should have a clear idea about what the content is about. This will allow you to create a design that helps present that content in a truthful manner. Take what you know about your content and mockup something that can present it well. I suggest using Photoshop to work on mockups at this point. This will keep you from having to write a big stylesheet when you don’t know if you need it.

    Also, focus on usability. People that come to this site have no knowledge of how you intended them to use it. They have certain knowledge about the way the web usually works. It’s best to take that into consideration. If you break from tradition, you need to make it obvious how you intend the user to interact with the site.

    After you are certain that the content is accurately represented and the design is usable, then worry about aesthetics.

    Typically, clients will want to approve a design. So, make a good composite to show off. You may even want to do a little HTML and drop a full-sized composite into a browser so the client can get a feel of how it would look.

    If it turns out that you have to do this step first, you should have an idea about what sort of content the client wants to be on his site. You may have to use your imagination a little more. Don’t worry, though. This is where most people have to start, and I believe starting here can still produce a great site, even if it isn’t the most ideal place to start.

  4. Start Merging Content and Design

    Open your basic document in FireFox, Opera, or Safari. Since these browsers basically agree with one another, this will help you start with a standards compliant site. Now is when you want to start working on your stylesheets.

    Start coding your stylesheet based on what you already have. Before, people misused tables to create designs. Using web standards, people tend to get div diarrhea. Instead of using elements that exist, people put divs around everything whether they need it or not. So, I suggest making creative use of headings, navigation lists, and paragraphs to trim down your stylesheet as much as possible.

    The best place to start is by throwing out some of the default formatting. I know I just said it was well thought out. It still is. It just isn’t well thought out for your design.

    The first part of my main stylesheet clears margins, paddings, and borders (i.e. *{margin:0px; border:0px; padding:0px;}). From there, it’s the designers job to figure out the best proximity. It also forces the designer to take a better look at default behavior and hopefully start coding it out (or coding it in) to have well thought out alignment and contrast, which makes cross-browser compatibility a little easier to achieve.

    As you go, you will probably find that you need a div here and there to help represent a certain aspect of your design. For example, I like my designs centered on the page. In HTML 4, the best way to do this is a div that has margin: auto wrapped around all the content (though in real XHTML, the html and body elements can be used to achieve the same ends with no extra markup).

    So, add extra divs when you absolutely need them, and make sure to either code in or code out default styles. Be creative, though. It’s your job. Usually the easiest solution is not the best.

  5. Make Sure It Is Accessible

    A pretty design is useless if it isn’t a good design. Good designs are accessible to the most number of people possible. So, audit your site and make sure there aren’t any serious accessibility problems. Make sure images have meaningful alt tags, form elements have labels, etc. Don’t forget niceties like skip to content links. This section really deserves an article of its own. So, I won’t go into much detail.

    Since I’m on a Mac, I’ve familiarized myself with browsing web sites with VoiceOver. While it isn’t as good as the other web screen readers, it helps me get an understanding of what the page might be like. I highly suggest this (or some similar testing) be part of the audit if you have access.

  6. Debug for Internet Explorer

    Internet Explorer 7 was supposed to bring in a new age of standards compatibility. It didn’t. Even if it did, use of Internet Explorer 6 is still rampant. In the old days, stylesheet hacks were the way to account for differences in browser rendering (fighting bugs with bugs). Now, though, Internet Explorer has a proprietary concept called conditional comments.

    This is the first proprietary HTML concept Microsoft has created that is worth a damn. Conditional comments allows the designer to hide or show page content in Internet Explorer based on variables such as browser name or browser version. So, we create a conditional comment to show our Internet Explorer bug fix stylesheet only to Internet Explorer (e.g. <!--[if lte IE 6.0]> <link rel="stylesheet" type="text/css" href="ie_fixes.css"> <![endif]-->). No hacks needed.

    Work in Internet Explorer to clear up any layout issues by overwriting your real stylesheet values. So, if you had a fieldset{border: 1px dotted gray;} in your real styesheet, which causes weird results in Internet Explorer, you can change it by adding fieldset{border: 1px solid gray;} in your Internet Explorer stylesheet. Don’t get bent out of shape if things aren’t one-for-one the same. Sometimes a reasonable likeness is as good as you can get.

  7. Show It To The Client

    By now you have a semantic document custom tailored to your client’s content that is usable, accessible, and hopefully aesthetically pleasing. You can now show it to the client. Since you had the forethought to use web standards, you can make changes to every page at once via the few stylesheets you created. It will save you time and your client money. Since the code is semantic, search engines can better understand the content and index it properly, which may lead to increased revenue for your client. Everyone wins.

Tags: , , , , , , , ,
Posted in Web Design, Web Development | Comments Off

Markup Not Safe For Work Content

December 29th, 2006 by Robert

Some guy named PJ Doland suggested we use rel="NSFW" to markup content that is NSFW.

I’m not validating or endorsing the idea by posting about it. I’m posting because I had written a comment on the accompanying Slashdot article (that I never posted) that addressed the issues below.

Then I wrote half of a post about how the rel attribute could only be applied to hyperlink-type elements and that putting it on other tags would cause the document to fail validation. Instead, class or title attributes should be used, depending on how microformat he wanted to go. However, I realized that he beat me to it. His second article pretty much says what I was going to with more words. I had already written the HTML for a document to prove that it wouldn’t validate.

Tags: ,
Posted in Web Design | Comments Off

The Great MIME-Type Swindle

November 19th, 2006 by Robert

It’s a really old subject, but I haven’t said my piece on the XHTML 1.0 versus HTML 4.01 debate. While commenting on Roger Johansson’s blog, 456 Berea Street, I said a little bit about what I think. I figured I ought to go ahead and say my fill.

XHTML was supposed to be the death of HTML. HTML 4.01, until recently, was supposed to be the last iteration of HTML. I think XHTML is great. It allows the designer to implement bits of XML, should he want to. It also is very strict, requiring proper syntax where HTML didn’t. If there is something wrong with the code, the page should not render at all. This makes good syntax coding a requirement rather than a suggestion. However, the current implementation of most of the XHTML pages I know of is ideologically broken. The rest don’t work on Internet Explorer.

The comments I made assumed a little foreknowledge but basically say what I want to say here. However, I’ll go ahead and lay out my full argument here.

In 2000 when XHTML 1.0 was introduced, there was a need for backward compatibility since most browsers could not render real XHTML. That is, browsers were built to render HTML served as text/html. Sending XHTML as XML resulted in, I assume, an interpreted XML tree. So that adoption of XHTML would occur, it needed to work in browsers. So, the XHTML recommendation had guidelines in place of how to make XHTML work on HTML browsers. This wasn’t backward compatibility so much as a hack. It didn’t allow for any of the benefits of XHTML, though it succeeded in making pages written with XHTML syntax render on old browsers. So, the mime-type is the modern equivalent of DOCTYPE triggering quirksmode (which the Web Hypertext Application Technology Work Group embrace).

As far as hacks go, it worked. Like all transitional solutions, it was supposed to be dropped as browser support for XHTML grew. The problem is that Internet Explorer never supported it (even in version 7) and people opted to continue to send HTML-XHTML. Further, it seems, many people don’t realize that real XHTML requires the correct application/xhtml+xml mime-type being sent. This is something that must be set up on the server, as text/html is the default mime-type for sending .html documents on every web server I know of.

When XHTML is sent as text/html, it behaves differently than if it is sent correctly. XHTML sent as HTML is treated as tag soup, which means any optimized, light weight XML parsers aren’t used. Tag Soup XHTML doesn’t require strict use of CDATA elements and improper syntax doesn’t stop rendering of the page. The null closing tags are treated as broken attributes. While it still works, XHTML is ideologically broken if it is sent as text/html. People who suggest we ought to use XHTML to guarantee that fledgling designers pick up XHTML (which would require strict syntax) are suggesting that we use a broken implementation to uphold an ideal that is at odds with broken implementations (ignoring that an unforgiving markup language would cause most designers to give up out of irritation). It is hypocritical.

So, I see two choices that are ideologically sound. The first is to use XHTML and send it as application/xhtml+xml, Internet Explorer be damned. However, this is really not a good choice for most. Some would suggest content negotiation, but this is still a hack that requires a lot of extra thinking and planning (albeit a better one than sending XHTML as HTML). The second is to only use XHTML in specific instances where compatibility can be guaranteed.

Let me elaborate on the second choice. HTML 4.01 is a web standard. Anyone in the web standards group that always advocates XHTML over HTML on grounds that XHTML is better suited for use than HTML doesn’t understand what tools are for. HTML with a strict DOCTYPE can be validated, written semantically, and obsessed over as much as XHTML. HTML just allows the web designer to make the choice (and good designers will obsess over their markup no matter what).

HTML and XHTML are tools to solve a problem. Just like a screwdriver won’t help when a hammer is needed, XHTML is no good when HTML is needed. I’ll be specific. On pages where free-form user input is allowed, the potential for non-designers (and designers, too, for that matter) to enter bad markup is huge. In a real XHTML page, the user could easily break a page, preventing rendering. When using HTML, the page may no longer validate, but it will still render. In instances such as these HTML is a better tool than XHTML.

Web applications, however, are a different story. System requirements can be specified as they are on traditional applications (e.g. a browser that supports XHTML can be required). This means that no hacks need to be used. Since web applications generally use form elements to display and edit data, concerns over user input are drastically reduced. Most of the time, discreet data is required rather than free-flow data that one might find on, say, a comments page. So, data can be more accurately validated. When that data is inserted into an XHTML page, it’s far less likely to break the page. On a syntactical level, XHTML meshes well with programming languages. That is, the code must live up to certain standards. XHTML would help tie the front end to the back end. XHTML is a perfect tool for web applications.

So, ignoring all the common arguments about the dangers of using XHTML, the ideology of XHTML is broken if the page works in Internet Explorer 7 or below. Advocating the use of a broken technology is hypocritical when well written HTML 4.01 with a strict DOCTYPE is better suited for normal web usage. However, XHTML has a defined and useful place on the World Wide Web.

If you want another opinion, Maciej Stachowiak of Apple’s WebKit / Safari project weighs in with pretty much the same opinions I have.

Update: The Lachlan Hunt pointed out that I screwed up the XHTML MIME-type. I fixed the error.

Tags: , , , ,
Posted in Web Design, Web Development | Comments Off

Wikka Wiki Bread Crumbs

November 10th, 2006 by Robert

Dan decided he wanted to set up a wiki to build content. I wasn’t involved in the process, but I got the job of making a bread crumbs script for the site.

Dan decided to use Wikka Wiki. When I asked why he didn’t use Media Wiki (the software that Wikipedia uses, which seems to be the de-facto standard), he said it required PHP 5, which our server doesn’t have. I guess that was a good-enough reason.

For all my niggles with Wikka Wiki, it is actually pretty standards compliant and has a cute name. The main issue with Wikka Wiki, which might be an issue with all wikis (I wouldn’t know since this is the first one I’ve ever coded on), is how it stores links from one page to another. It has a links table with a from_tag and to_tag. This is logical and works quite well until you try to do bread crumbs.

When you send a query to get every link that should go on a page, recursive links aren’t a problem. When you are trying to make a recursive function to get a bread crumb trail, it is quite annoying. Since Dan was in a hurry, he just did 10 left joins on the same table with a limit of one. That got the job done but didn’t always show a logical or short-route path to the current page. Dan decided that I was better at recursive functions and told me to work on it when I had time (except he calls them cookie crumbs instead of bread crumbs, which you’ll see in the code). After about 10 tries, I came up with the following: 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

function BuildCookieCrumbs2($page, $depth=0, $menu=array("CareerOpportunities","DefaultMenu","CurrentFrontPage")){
	if($depth &gt; 10)
		return;
	if(in_array($page,$menu)){
		return $page;
	}
	$sql = "SELECT to_tag, from_tag FROM career_opportunities_links WHERE from_tag IN ('".implode("','",$menu)."')";
	$r = $this-&gt;Query("SET NAMES UTF8");
	$r = $this-&gt;Query($sql);
	$o = array();
	$f = array();
	while($row = mysql_fetch_assoc($r)){
		$o[] = $row["to_tag"];
		$f[] = $row["from_tag"];
	}
	if($ret = array_search($page,$o)){
		return $f[$ret]."&gt;".$o[$ret];
	}
	else{
		$ret = "";
		$bcc = $this-&gt;BuildCookieCrumbs2($page,$depth+1,$o);
		$ret .= $bcc;
		$tmp = explode("&gt;",$ret);
		$sql = "SELECT FIND_IN_SET(from_tag,'".implode(",",$menu)."') as fis FROM career_opportunities_links WHERE from_tag IN ('".implode("','",$menu)."') AND to_tag = '".$tmp[0]."'";
		$r = $this-&gt;Query("SET NAMES UTF8");
		$r = $this-&gt;Query($sql);
		$row = mysql_fetch_assoc($r);
		$ret = $menu[$row["fis"]-1]."&gt;".$ret;
		if(in_array($page,$tmp)){
			return $ret;
		}
	}
	return $ret;
}
function BuildCookieCrumbs($page) {
	$ret = $this-&gt;BuildCookieCrumbs2($page);
	$ret = explode("&gt;",$ret);
	unset($ret[0]);
	return array_values($ret);
}

These two functions can be dropped into the Wakka.class.php file. I have no idea how to call it and put it into the template, as that part was already done when I started working on it. Sending the current page will return an array of tags to use in the bread crumb trail. You’ll probably want to change the default menu array in the BuildCookieCrumbs2, as it is set up to reflect our site.

This may not be the best solution, but it works pretty well.

Tags: , ,
Posted in Web Development | Comments Off

Browser Tools for Web Designers

November 7th, 2006 by Robert

I told Kathryn that I had a few browser tools for Macs she should check out for web design. I decided to make a post about it instead.

Make Safari Better

I really prefer to work in Safari on a Mac. Firefox, frankly, is slow as hell. The problem is that Safari, like most of Apple’s software, is simplified for general use. Out-of-the-box, it lacks a lot of features that even Internet Explorer have. The qualifier there is out-of-the-box.

Debugging JavaScript

While it doesn’t feel as robust as Firefox’s JavaScript debugger, Safari ships with one hidden away. One of the first things I do with a fresh install of Safari is turn on the Debug menu. To turn it on, open Terminal and enter defaults write com.apple.Safari IncludeDebugMenu 1 and press enter. The next time you launch Safari, the Debug menu will appear. Make sure Log JavaScript Exceptions is checked, then open the JavaScript Console from the Debug menu (or press command + shift + j).

The interface is very minimal. At first blush, it seems to be lacking compared to Firefox’s console. After you use it some, you’ll find that it is as good as Firefox when it comes to picking up, identifying, and finding errors in your code.

Safari Tidy

The other tool I find quite helpful is Safari Tidy. Safari Tidy is a plugin for Safari that runs every page you browse through HTML Tidy. HTML Tidy helps to find any errors in your HTML. While it isn’t a validator, it does a pretty good job of identifying problems.

Safari Tidy puts a simple message in the bottom right side of the status bar in Safari. It may say 0 errors / 2 warnings. This tells the developer that there are three potential problems in the code. Double clicking the message will bring up a modified view source window that displays the errors. By double clicking an error in the view source window, the line with the problem is highlighted. Identifying errors is much quicker this way.

Make Firefox Better

Firefox is already a great browser for developers. The JavaScript debugger is top notch and it has a built-in DOM inspector. However, I’ve found one extension that I can’t live without: The Web Developer Toolbar.

The Web Development Toolbar

This toolbar adds a lot of functionality by allowing web designers to see tons of information about what is in the HTML. It has too many features to list all of them, but I’ll list the ones I use the most (which aren’t necessarily the most helpful).

  1. JavaScript Error Notification

    In the far left of the tool bar, there is a small info icon. When a JavaScript error is encountered, it turns into a red icon. Clicking it will show the JavaScript Error Console. This at-a-glance error notification is the feature I use the most.

  2. Validate Local HTML

    Under the tools menu, there is an option to run the current page through the World Wide Web Consortium’s validator as a local file. The source is submitted as a file, which allows any page to be validated. To boot, they have assigned a key combo to do this quickly in a new tab. There is also options to validate local style sheets, as well as regular validation options.

  3. Resize Window

    This sounds pretty silly, but there is no way to accurately resize a browser window without JavaScript or a tool bar. This one includes resizing to 800×600 as well as custom values.

There are tons of other features packed into this tool bar. The features I use most don’t accurately represent how powerful it is.

FireBug

FireBug is a great extension that is very useful in certain situations. While I don’t use it every day, FireBug is very powerful. It exposes the HTML on the page at a given time. That means any changes to the DOM are accounted for in the source view.

What makes FireBug great is that you can then live edit the HTML and CSS. The browser updates as you type. FireBug won’t let you save your work, but it does allow for rapid debugging without impacting the actual files. Basically, you can experiment with various ideas to debug your layout without having to deal with backups or limited undos. Once you figure out your issue, you can copy and paste the updates to live files.

Got Any Suggestions?

Do you have any browser add-ons for web designers or developers that you can’t live without? Let me know!

Posted in Web Design, Web Development | Comments Off

W3C Listens, Incremental Update to HTML On The Way

October 28th, 2006 by Robert

Surprisingly, SlashDot scooped all the web design websites I normally read on Tim Berners-Lee’s announcement that HTML will be incrementally updated (as well as things such as the W3C’s HTML validator)

In the post, Berners-Lee addresses folks like (in order of impact) Bjoern Hoehrmann, Jeffery Zeldman, Eric Meyer, and Molly Holzschlag who have been angry with the W3C for resting on their laurels, instead of listening to the community (apparently blatantly ignoring them). As everyone points out, the W3C should be advancing the web. Instead, small work groups are bringing us things like microformats and recommendations to update HTML.

So, the really important part of Berners-Lee’s post is not that HTML will be updated. It is that the W3C is claiming that it will now listen to the community by actually following the feedback mechanisms they have in place instead of blatantly ignoring them. The W3C is going to get back into the community instead of towering above it. Assuming they follow through, this could be a new age of progression.

I might have more to say after the weekend when the web design celebrities weigh in on the subject.

Tags:
Posted in Web Design, Web Development | Comments Off

Ajax vs Specific Accessibility vs General Accessibility

October 23rd, 2006 by Robert

I was reading Rob Cherny’s article Accessible Ajax, A Basic Hijax Example and started thinking a little more about accessibility. Cherney claims that this hijax method, using unobtrusive JavaScript to make a form submit with Ajax instead of traditional POSTing when Ajax is available, is more accessible. While I think it is more accessible than only using Ajax, it is only more accessible for generic alternative browsers; it isn’t any more accessible for disabled people.

Apparently the term hijax that was used in Cherny’s article was coined by a guy named Jeremy Keith. I don’t think the term was really needed as the concept of unobtrusive JavaScript pretty much sums up the idea of hijax. I’ve inadvertently been using hijax since May, however. So, I have some opinions on it.

Web accessibility is a big beast with two opposing heads. The original term accessible meant that the site was designed such that people with disabilities could use the site. Recently, the term has changed to include people with or without disabilities that browse from alternative devices. By alternative I mean mobile phones, ultra-mobile PCs, screen readers, and the like. These alternatives often lack the typical mouse-based interface of desktops, JavaScript support, cascading stylesheet support, or even HTML support. So, one head of the beast is accessible-for-disabled-persons and the other is accessible-for-alternate-devices.

I personally prefer the inclusiveness of the second head when I talk about accessibility. However, the caveat is that saying something is accessible to some facet of alternative browsers may not make it accessible to the disabled. If you aren’t specific about what you are trying to be accessible to, you end up confusing people (see my comment).

Cherny’s article elegantly addresses a facet of the second head. The form degrades gracefully. Unobtrusive JavaScript is designed this way: create a normal web page, then spice it up with JavaScript to improve the existing functionality. So, for Ajax forms, it is a three step process that might go as follows:

  1. Create a form that works by POST.
  2. If JavaScript is available, unobtrusively add support for validation.
  3. If Ajax is available, unobtrusively add support for Ajax.

If there is no JavaScript, the form will post normally. If there is no Ajax, the user gets error correction and the page posts normally. If there is Ajax, the user gets error correction and doesn’t have to wait for a page load. Whatever the case, the form is submitted and no alternative browser is left out.

However, there are still problems with Ajax and the first head of accessibility. I’m going to focus on screenreaders, as people with motor disabilities or deafness still have random access to the page (they aren’t limited to linearly reading the page). I will say this, though, in reference to the deaf and those with motor disabilities: the form itself must be accessible, using labels and accesskeys, or it’s still not fully accessible. Screenreaders, at this point, are still no good with dynamic page updates, which are a mainstay of Ajax. Some aren’t even good with alerts. Of all the available solutions to the problem of updating content dynamically, none of them work across the board. The only way to accessibly do dynamic content updates is to give the user another option.

Since I was aware of this problem when I redesigned my site, I built in a link to turn off Ajax above every form that uses Ajax. The Ajax is unobtrusive, or hijax if you prefer. This was the only method I could think of to allow full access to my forms. Until screenreaders catch up to the technology, the best Ajax accessibility may be no Ajax at all. So, let the user opt out if he wants.

Tags: , ,
Posted in Web Design, Web Development | Comments Off

Internet Explorer 7

October 19th, 2006 by Robert

Internet Explorer 7 has been released. Download it now! Help usher in a new era: an era where Microsoft is actually interested in web standards.

Update: There is some discussion going on over at 456 Berea Street. Particularly of interest is how to install multiple stand alone versions of Internet Explorer. While this info can be gathered elsewhere, the feed back from the comments is useful in deciding which method to use. Plus, these are opinions from web designers rather than tech pundits. So, that is nice.

Update: Apparently someone already found a vulnerability. Some things never change.

Tags: ,
Posted in Meta, Web Design | Comments Off

« Older Entries
Newer Entries »