Posted by Dan Eastwell
Tue, 11 Nov 2008 21:00:00 GMT
A quick example of a CSS style guide - I've been reading about unit testing for jQuery and wonder if an analagous approach could be used on a CSS system.
Probably not, but a style guide featuring every type of box, unit, module and typographic style on the site can quickly allow you to not only see if any changes you make have knock-on or regression errors, but allow you to see what your styles imply.
What do I mean? Well, if you have a particular form style, a style guide should have all form elements shown, even if they appear nowhere on your site - eventually, they will.
If you have a module style, what will it look like at different widths, and in combination with other similar boxes (even if you're building a fluid layout)? A style guide will help you find out and troubleshoot.
I've written about CSS systems analysis, and am happy to find a kindred spirit in Natalie Downe in her article, which covers not only CSS systems analysis, but also the concept of css style guides in any documentation handover.
Posted in CSS, XHTML, Interface Development | Tags analysis, css, guide, style, systems | 1 comment | no trackbacks
Posted by Dan Eastwell
Sun, 04 Nov 2007 22:24:00 GMT
This interesting article covering UK government proposals to make WCAG AA standard mandatory for .gov.uk websites corresponds to my earlier qualms concerning making government websites AA complient.
I'm now coming round to the opinion that at least government websites should cover AA compatibility.
Having worked on fairly non-compliant, inaccessible websites, or websites where 'buy the book' accessibility is adhered to ('it validates so it must be accessible'), I think it's worth going through a minimal level of accessibility on any site (does it work with a keyboard only, for example).
What Bruce Lawson's WaSP article highlighted are a couple of main points:
- Firstly, CMS generated sites need to ensure that all output content validates
- and that the administration systems themselves for CMSs need to be accessible
Valid output HTML
What this means practially is that if a rogue unencoded ampersand can invalidate a page of code, then letting non-expert staff add raw HTML into managed content systems can mean running the risk of losing a site it's .gov.uk domain name.
A positive side effect of this possible legislation might well be a great rise in the use of WYSIWYM content adding tools, rather that allowing staff to add their own code (not least, from a business point of view, as WYSIWYG and HTML-editable CMSs risk breaking site branding).
Accessible admin systems
This may well be an article in itself, but one of my main bugbears is that admin systems for building and maintaining sites by non-technical staff needs to be as, if not more, usable and accessible as the main site itself.
Generally admin systems are, at worst, an afterthought, or at best, an unusable off-the-shelf system. Adding, updating and deleting content on a website necessarily requires a much larger site that the site itself (in terms of page templates). They require just as much user experience design, just as much accessibility design and just as much care and attention.
Hopefully this recommendation, if it ever becomes law, will provide the kick up the backside necessary to site commissioners, and site design and build agencies to push for the time needed to build usable and accessible administration systems as thoroughly thought through as their main sites.
Posted in CSS, XHTML, Accessibility, The Web | no comments | no trackbacks
Posted by Dan Eastwell
Sat, 07 Apr 2007 20:08:00 GMT
A bit of shameless self promotion, here, but I've made the effort, so why not let people know?
There's a few new articles on my main site:
Boots Expert: Progressive enhancement: Javascript enhancement to pages, and CSS systems analysis, to tight accessibility requirements.
This project went live at the end of last week, and I'm fairly proud of how the project went and the outcomes. The site is very accessible and has been well reviewed and tested. I think the design is great (not my work!) and I'm happy with the soundness of the XHTML and the CSS, especially, which I think has been nicely modularised.
Energy Saving Trust: Ajax modules: Reskin work on existing coldfusion-driven modules, creating javascript to enhance the look of the output code. Ajax modules written to enhance HTML forms.
Design Council: Complex Modular Site: A complex modular site using transparencies, and intricate CSS structure.
I worked on this last year and now the site is live. This was a large project with many templates necessary to match the designs, it's lead me to think a lot about the status of interface architecture for the web (or CSS/XHTML, if you will…) as a discipline requiring the same level of forethought as any other software-based discipline, when dealing with projects with any level of scale or complexity.
Posted in Usability, Browsers, CSS, XHTML, Interface Development, Design, Javascript and the DOM | no comments | no trackbacks
Posted by Dan Eastwell
Fri, 23 Mar 2007 16:58:00 GMT
In the beginning… we littered our code with <td>s <font>s, whatever. Now, through scripting, we’re doing exactly the same thing, and not caring about it.
Read more...
Posted in XHTML, Interface Development, Javascript and the DOM, The Web | Tags attribute, coding, dom, javascript, rel, scripting, tidy, xml | 2 comments | no trackbacks
Posted by Dan Eastwell
Wed, 21 Mar 2007 12:45:00 GMT
I like the The nested-objects method of embedding flash into a web page but it has its drawbacks
It gets rid of the embed element and uses conditional comments in order to hide classid and codebase parameters from non-IE browsers, which includes the W3C validator.
However, in the limited testing I've done, although this method loads swf files into Firefox, the specific example I'm working on uses contained flv video files, and the controls don't work. It may be the video, or it may be the controls, either way a javascript workaround may have to be the answer in this instance..
Update: You know what it was? <param name="wmode" value="transparent" /> This bit of code will stop controls in swf flash movies from working when using the 'nested-objects' or conditional comments flash embedding method.
My guess would be this is also true for < 1.5 Firefox and older Netscape browsers.
Posted in Browsers, XHTML, Interface Development | no comments | no trackbacks
Posted by Dan Eastwell
Mon, 29 Jan 2007 10:14:00 GMT
You'd think that with IE7's zoom feature, we'd get rid of one real testing headache when creating scalable layouts with CSS.
That's true in the vast majority of cases, but there are still issues with techniques we've come to get used to.
Take this example: www.digitaluk.co.uk.
With one level of zoom, you find that the calculation for the centering of the navigation gives a different result to that for the main content:
And is greater at the second level:
This may be due to the fact that the navigation is absolutely positioned, within a relative parent container, a technique for getting main content first on the page (normally for SEO), but not first when viewed in the browser.
This may be an issue we front-end developers need to tackle, or it may be a bug in IE7's zoom facility, I've not tested this thoroughly enough yet, but there is an issue that needs resolving.
Posted in Browsers, CSS, XHTML, Interface Development | Tags css, html, IE7, resize, resizing, zoom | 1 comment
Posted by Dan Eastwell
Thu, 14 Dec 2006 13:22:00 GMT
We've all learned that sending HTML emails is the devil's work. If you haven't yet, I suggest you look at this list of articles on sending HTML emails.
Safe now in the knowledge that you need to forget all you know about semantic structure, separation of content from style and table-free layouts, you've constructed your email, to find that Microsoft's new alternative for hotmail, Live Mail, doesn't display your emails correctly.
Read more...
Posted in Browsers, CSS, XHTML, Interface Development, The Web | Tags email, html, htmlemail, live, livemail, mail, microsoft, safehtml | 3 comments | no trackbacks
Posted by Dan Eastwell
Sat, 25 Nov 2006 11:26:00 GMT
Seeing as my site's called The Thought Balloon and I write a lot about CSS, Javascript and HTML, I get a lot of search engine queries for people looking for a 'CSS balloon' or a 'javascript balloon'.
Read more...
Posted in CSS, XHTML, Interface Development, Javascript and the DOM | Tags balloon, coding practice, comment, css, graceful degradation, html, javascript, popup, progressive enhancement, xhtml | 4 comments | no trackbacks
Posted by Dan Eastwell
Tue, 24 Oct 2006 17:58:00 GMT
This is a final thought that came to me whilst writing my article on CSS Systems Analysis. It's really a list of questions concerning whether/how the CSS and HTML could or should be automated: obviously I'm aware of the limits of automation and the inconsistencies of CSS implementation across browsers - it's more of a seed of an idea.
Automating the Process
If your CSS Systems Analysis is thorough, the obvious question that would arise to any developer is 'can I automate any part of the process'? At this stage, I'd like to leave that question open, as it raises several questions itself:
-
What tool could be used for generating the code? Could a make-like programme such as ANT be used? Could a custom php template be used?
- How would the parameters be input? Through parameters entered via a console, or through a config file?
- What will be generated? The HTML? Or the CSS? Or just the CSS/HTML framework?
This, it seems, are questions that might be useful to answer, and maybe a simplistic prototype be made. In general, though, many of these questions could be answered through the formalisation of the CSS/HTML analysis process, and a few practical workthroughs on larger-scale sites, could narrow down if not the answer to automation, but at least the questions that need to be asked.
Posted in CSS, XHTML, Interface Development | no comments | no trackbacks
Posted by Dan Eastwell
Tue, 24 Oct 2006 16:19:00 GMT
I'm writing an article currently on CSS 'Systems Analysis', so I'll quickly post the items that didn't make the cut.
Firstly, a short note on naming conventions – it would make the world happy if you named your classes by their function, or module, rather than their style. E.g.
<div class="blog_entries">
<h3>
...
rather than:
<div>
<h3 class="big_orange_header">
...
Posted in CSS, XHTML, Interface Development | no comments | no trackbacks
