Posts Tagged ‘w3c’

One of the biggest issues in older scripts (and in this example) is reliance on proprietary vendor techniques such as document.all, which has limited browser support beyond Internet Explorer. Web standards support open, nonproprietary technologies that work across browsers, and there are certainly alternatives defined by the W3C in its Document Object Model. Two of these alternatives are

document.getElementById(id) Returns an element when passed an id that is the ID attribute of the element;
the ID needs to be unique in the document.

element.getElementsByTagName(tag) Returns a nodeList (JavaScript array) of the matching elements by tag.

There are several examples above where document.all can be seamlessly swapped out with document.getElementById. Replace the following:

var x = document.all(“myDHTML”)
with this:
var x = document.getElementById(“myDHTML”)
And replace this:
var x = document.all.tags(“p”)
with this:
var x = document.getElementsByTagName(“p”)

These two methods are key to W3C-based DOM scripting.

Comments Off

As with any software, an evaluation should be made of all the required functionality, a core set of functions created or agreed upon, and a standard way of interacting with UI elements created. Scripts should be stored in a central location and documented by a knowledgeable staff that is aware of what is available and what is needed.

A reference for a JavaScript function can be just like any other programming language. For instance, if there was a utility function to combine two strings together (not that someone would ever need such a thing), it might be documented as follows:

string myStringCombiner(string param1, string param2)
Purpose: combines two strings, returns a new string
Parameter Description
param1 Required. First string to concatenate to the second.
param2 Required. Second string to concatenate to the first.
Notes: Function is available by including base-functions.js.

Comments Off

Some more css printing rules:

body {
font-size:12px;
color:#000;
background-color:#fff;
font-family:Arial,Helvetica,sans-serif;
padding:120px 10px 20px;
margin:0;
}
div.vcard {
font-size:11px;
position:absolute;
top:25px;
right:10px;
text-align:right;
width:400px;
}
div#print-logo {
position:absolute;
top:45px;
left:10px;
}

The hidden print logo is not hidden in the print version, and both it and the footer are set to absolute and moved to the top of the document to establish a letterhead-like quality. Notice how the body has a padding-top of 120px, which leaves room for the absolutely positioned letterhead style print logo and hCard data. The result is a well-formatted and easy-to-read printed page that emphasizes the content.

Using similar techniques can save time and effort on the server-side implementation of mixed-media and multiple-device publishing from a CMS or any other tool. CSS support for handhelds gets better ever day, and it will only allow for greater versatility as time goes by, lessening the burden and level of effort required to provide alternative forms of publishing of the same content.

Comments Off

Moving through the whole print.css file, there are even more elements, classes, and IDs that are hidden. This demonstrates how this technique is in fact an exercise in removing as much as possible. The above rules hide the global navigation as well as the branding, white-on-color logo, and the right and left columns. This essentially leaves the middle content and the footer, as well as the logo that is usually hidden at the bottom, at least on screen.

With this technique, there are a few more rules required for the printer CSS than with printing techniques that share the screen and print rules. The reason is that authors will need to set the fonts and colors for all type styles from scratch once again, since not a single rule from the screen.css file is applied to the print version.

However, starting with a clean slate these days is typically more reliable for print CSS, since browser support is inconsistent and poorly documented.

Comments Off

Back to top