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
Mon, 28 Jan 2008 14:34:00 GMT
Just come across a problem that may occur again - if you're trying to create a button using background images for button tops and bottoms and a span for an icon (for example), then be careful that the 'hand' cursor appears in Internet Explorer (IE), in all latest versions (5.5, 6, 7).
If you have HTML of the form:
<div class="button">
<a href="#"><span>Button text</span></a>
</div>
you might well set the span to display:block in order to have a background image show. In this case, IE will render the default cursor for span, rather than the hand ('pointer') you're expecting
in this case, set the CSS to:
div.button span{
cursor:hand;
}
in your IE only css file (or add cursor:pointer;cursor:hand if you don't filter out Internet Explorer using conditional comments). The hand for the link will now show.
Posted in Browsers, CSS | no comments | no trackbacks
Posted by Dan Eastwell
Fri, 07 Dec 2007 17:53:00 GMT
You've spend months on a project, place it on your portfolio with pride. A year or so later, you go back to the site and - horrors - it's completely changed!
I've had that feeling twice recently.
Firstly I was looking for an old image gallery I'd created for the javascript I'd used. When I got to the site all I could see was a 404.
One to change on my portfolio.
This evening I saw an advert on TV for a company I built HTML/CSS templates for, that I was fairly proud of.
Then I did a double-take.
If they've come up with new style product and a new style advert, their site is likely to be rebranded, too. Oh dear.
Leaping to my laptop I looked at their homepage - it's greatly different. Their main landing pages: different. Then I went deeper into the site, to some of their several thousand product and information pages. Very similar. Phew!
This pleases me on a couple of counts - firstly I don't have to take the page from my portfolio, and that the structure, template layouts, palettes for colours and the other CSS systems tricks I'd put into place were still there.
I can only hope the makeover was easy and therefore cheap for the new design team.
The most pleasing thing of all? My name and site still there in the boilerplate in the css files
CSS templates by Dan Eastwell www.thoughtballoon.co.uk
Is it that wrong to have a little pride in your work?
Posted in CSS, Interface Development, Design, The Web | Tags design, websites | 2 comments | 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
Tue, 19 Jun 2007 08:19:17 GMT
I had what appears to be a hasLayout issue triggered in Internet Explorer 6: extra bottom padding (equal to the top padding) on an element which
has bottom padding explicitly set to 0 in the CSS.
This only occurred when an element this element contained was clicked and an a click event was triggered. On click a javascript function added a class to the link that was clicked.
I could resolve the extra padding problem using the IE developer toolbar
by adding position:relative or padding-bottom:0, but it wasn't
resolved by either adding these declarations to the CSS or adding them to the
element on the click event on the <li> that was clicked.
This problem appeared in IE6 only and was due to adding an additional unecessary float to the contained >ul>.
There was no workaround for this issue being triggered by a click event, except for creating a reduced test case in the HTML, and then commenting out the CSS piece by piece until I found what was causing the problem.
Posted in CSS, Javascript and the DOM | 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
Wed, 04 Apr 2007 16:05:18 GMT
But at least I look good.
The site's gone CSS naked until a Rails upgrade glitch is sorted out. James is on the case...
Posted in CSS, Interface Development | 2 comments | no trackbacks
Posted by Dan Eastwell
Thu, 15 Mar 2007 17:10:23 GMT
Links don’t work in transparent elements in IE6 using the filter:progid:DXImageTransform.Microsoft.AlphaImageLoader method, when the container the filter is applied to is absolutely positioned.
One (extra) hack to get round this is to change the sizingMethod to crop and then make sure that the links are only going to be over an area that is transparent.
The only other hack is to move the filter up onto the link container, as per here:
http://www.satzansatz.de/cssd/tmp/alphatransparency.html
or serve IE a flat background, as it’s all it can robustly cope with…
Posted in Browsers, CSS | 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
Fri, 12 Jan 2007 11:05:46 GMT
If you have a containing element (.container) with two elements, floated left and right, with fixed widths, the implied space between them wont show within Safari, unless the containing element's width is specified.
If the width is not specified, all browsers except safari assume the container takes up 100% of the space it has to go in. Safari was assumes it takes up 100% of the space its components occupied.
The margin between objects is 'implied', in that it was 'the space between objects'. In safari, this means there is no implied space between these floated elements.
Setting:
div.container{
width:100%;
}
sorts it out.
Posted in Browsers, CSS | 1 comment | no trackbacks
