Sun, 13/09/2009 - 19:44 — horuskol
At almost 1,000 pages, the HTML5 specification from the W3C can seem a bit daunting.
However, the reason for this extremely wordy specification is to clear up a lot of ambiguity that existed in previous specifications targeted at browser vendors and producers of related software. This is actually a good thing, since it locks down the behaviour and rules that browsers have to obey, meaning that web developers can be more sure of conformity across browsers.
But that does mean that the specification is full of sections that are just not relevant to the creators of websites.
Wed, 17/09/2008 - 22:08 — horuskol
One area where I regularly hit a wall is when using JavaScript. Documentation on the various browsers' support of JavaScript and the Document Object Model (the DOM - a way of interacting with the various elements within a document in a logical fashion) is not always well documented. Sometimes the information is there, but it takes a lot of digging, and other times it's just time to try and learn by finding what works.
Wed, 17/09/2008 - 22:08 — horuskol
FireFox lets you add rows to a table simply by using the innerHTML property of the table object:
function addRow() { var table = document.getElementById('data_table'); table.innerHTML += '<tr>'; table.innerHTML += '<td>Cell 1</td>'; table.innerHTML += '<td>Cell 2</td>'; table.innerHTML += '</tr>'; }
Wed, 17/09/2008 - 22:08 — horuskol
A longstanding popular effect in forms are multiple selects – your choice in one select element (for example, a country) will cause a second select element to display a different list of options (states or counties).
The update of the second element is done using JavaScript:
var states = []; var states[0] = ['South Australia', 'New South Wales']; // Australia var states[1] = ['Cumbria', 'Berkshire']; // United Kingdom function change_state_select() { var nation_select = document.getElementById('nation_select');
Mon, 15/09/2008 - 21:57 — horuskol
I was presented with an interesting problem today.
We supply some of our clients with a desktop CMS application with which they can publish articles and pages to their websites. The CMS was written a good few years ago, and outputs mostly transitional HTML4 and some CSS. Like all “WYSIWYG†systems, it can throw a spoke in the works which cause pages to break. Digging out the cause isn’t always simple, although it generally turns out to be a very simple cause once found.
Sun, 31/08/2008 - 20:41 — horuskol
I came up with this solution about a month ago, and have since been implementing it into new site designs.
To tie up the extra information related to each input, I'm going to recruit the oft-overlooked <dl></dl> element.
Sun, 31/08/2008 - 20:41 — horuskol
It's been a web design mantra for years now - tables are for data, not for structure.
The simple reason is that it is easier to apply CSS positioning to elements outside of tables - whereas, moving a table cell has compounding knock-on effects - column and row issues which need to be cleaned up before the table will be valid and display properly again.
Another reason is that tables used for structure do not make use of a lot of the other related elements which help browsers to render the table (colgroups, for example), making them pretty slow to display on a page.
Sun, 17/08/2008 - 22:08 — horuskol
I was writing some JavaScript functions to react to onclick events which changed the background and text colours of a number of elements. Because I wanted “unselected†elements to return to a normal state, I had used the following JavaScript:
var selected_element_id = null; function select_element(element_id) { var element = document.getElementById(element_id); if (element_id == selected_element_id) { selected_element_id = null; element.style.color = "inherit"; // set the text colour to match the parent's setting