boogdesign blog

Web design, web development, standards compliance, Linux, events I went to related to that, and random things I found on the internet.

Rob Crowther, London, UK based Blogger, Web Developer, Web Designer and System Administrator - read my Curriculum Vitae

Buy my book!

Book CoverHello! HTML5 and CSS3 available now

Buy my other book!

Book CoverEarly access to HTML5 in Action available now

10/01/10

01:06:37 am Permalink Links for January 10th

Categories: Delicious

Tweet this!
Send feedback »PermalinkPermalink

03/01/10

01:04:21 am Permalink Links for January 3rd

Categories: Delicious

Tweet this!
Send feedback »PermalinkPermalink

25/12/09

12:45:02 am Permalink An Early Xmas Present - Opera 10.50 Pre-alpha

Categories: Front End Web Development, Standards, HTML and CSS

Opera gave web developers an early Xmas present this week when they released a 'pre-alpha' of Opera 10.5 for Windows and MacOS. The main new features are a new Javascript engine, Carakan, and a new vector graphics backend, Vega, for their Presto 2.5 rendering engine. With these in place Opera catches up with Gecko and WebKit in its support for, among other things, border-radius and CSS Transitions - which I covered in my first CSS3 post back in July. With that in mind I thought it would be worth updating my earlier examples with the Opera syntax to see how things looked.

Opera 10.50 uses the (soon to be) standard border-radius instead of a vendor specific property:

#mybox {
    border: 2px solid #666;
    overflow: hidden;
    -moz-border-radius: 20px;
    -webkit-border-radius: 20px;
    border-radius: 20px;
}

After changing all the examples, my first border test page looked like this:

Opera 10.5 showing borders test page

The bad news is Opera has the same problem as Firefox in that it doesn't clip the contents of an element you've rounded the corners on, so you can end up with square corners sticking out through the rounded ones. It also treats the corners where only one side is 'thick and rounded' badly, similar bot not quite the same as Safari:

Image of Opera's poor handling of rounded corners where one border is zero width

So our third implementation of border-radius manages to be subtly different from both existing implementations, though we can hope they all converge with time (this is pre-alpha, after all). I moved on to my borders and tables example page to have a look at how Opera handles box-shadow. Again, Opera implements the standard property, so it would have worked without any effort on my part if I'd just bothered to add the standard code in the first place &#59;) Here's a simple drop shadow on a table:

#table {
    margin-top: 1em;
    background-color: #ccc;
    border: 2px solid #666;
    -moz-border-radius: 20px;
    -webkit-border-radius: 20px;
    border-radius: 20px;
    -moz-box-shadow: 3px 3px 5px black, 3px 3px 5px black;
    -webkit-box-shadow: 3px 3px 5px black, 3px 3px 5px black;
    box-shadow: 3px 3px 5px black, 3px 3px 5px black;
}

Opera looks much the same as Firefox and Safari/Chromium:

Simple box-shadow on a table in Opera

Putting the box-shadow on the table cells also worked well, even with border-radius applied:

More complex box shadow with rounded corners

It also respects the infix value, like Firefox. Where it didn't look so good was if box-shadow was applied on :hover, it seems like it won't draw the drop shadow in any place outside of the original bounds of the element when the effect is applied dynamically:

Rendering problem when box-shadow is applied dynamically through hover

Finally, CSS Transformations. Opera 10.50 has similar support to WebKit, though this time through vendor specific properties, allowing both for transformations and animations. This code, in Opera and Chromium/Safari, will spin the mybox div through ninety degrees over the course of a second when you mouse over it(in Firefox, it will flip straight away):

#mybox {
    border-top: 40px solid #666;
    border-bottom: 40px solid #666;
    -moz-border-radius: 20px;
    -webkit-border-radius: 20px;
    border-radius: 20px;
    -webkit-transition-duration: 1s;
    -o-transition-duration: 1s;
}
#mybox:hover {
    -moz-transform: rotate(-90deg);
    -webkit-transform: rotate(-90deg);
    -o-transform: rotate(-90deg);
    -webkit-transition-duration: 1s;
    -o-transition-duration: 1s;
}

Have a look at my transformation examples if you're interested.

Overall I think this is very promising for such an early release, although I didn't do much browsing on the internet I didn't see any crashes while testing my examples above. Hopefully the glitches will be worked on as 10.50 matures and we'll have yet another browser in which we can play fancy CSS3 tricks.


Tweet this!
3 feedbacks »PermalinkPermalink

22/12/09

07:08:57 pm Permalink FizzBuzz in CSS3

Categories: Standards, HTML and CSS

I was reading Rachel Andrew's 24 ways post on Cleaner Code with CSS3 Selectors today, in which she covered nth-child selectors, and I was reminded of the FizzBuzz phenomenon which swept through Programming Reddit a couple of years ago. I thought it would be relatively easy to implement a CSS solution to the problem based on the nth-child selectors and generated content.

First I tried a quick test based on an ordered list and Rachel's example code for the table:

ol:nth-child(3n) li:after {
    content: "Fizz";
}

Using the advanced technique of copy and paste I quickly produced an ol element with 100 li's in it and observed the results. It wasn't quite a spectacular failure, but no Fizz appeared. A little reflection and I think I've figured out what I was doing wrong - the li is already the nth-child of ol and there are no further li child elements, so the rule doesn't match anything. After a bit of fiddling around I came up with two alternatives, cut out the li altogether:

ol :nth-child(3n):after {
    content: "Fizz";
}

Or use nth-of-type directly on li instead of nth-child:

ol li:nth-of-type(3n):after {
    content: "Fizz";
}

Then I realised that the ordered list was probably a mistake - I ought to be printing the number when none of Fizz, Buzz or FizzBuzz applies. My initial thinking was that having the number built into the markup would make it easier, but now I realised I'd have to both remove the default numbers and then insert new numbers in. So I switched to a table with 100 rows in it and started reading up on counters and numbering. This seems to work almost like a programming language, first you declare your variable on the root element:

table {
    counter-reset: number;
}

Then you stick it in a loop:

tr td:before {
    counter-increment: number;
    content: counter(number);
}

So now I have a table which counts up to 100, I override the generated content for each third and fifth child:

tr:nth-child(3n) td:before {
    content: "Fizz";
}
tr:nth-child(5n) td:before {
    content: "Buzz";
}

Finally specify the content for elements which are both a third and a fifth child:

tr:nth-child(3n):nth-child(5n) td:before {
    content: "FizzBuzz";
}

And, ta-da, FizzBuzz implemented in CSS (with the slightly unusual input requirement of a 100 row HTML table).


Tweet this!
Send feedback »PermalinkPermalink

20/12/09

12:25:32 am Permalink Links for December 20th

Categories: Delicious

Tweet this!
Send feedback »PermalinkPermalink

13/12/09

12:19:09 am Permalink Links for December 13th

Categories: Delicious

Tweet this!
Send feedback »PermalinkPermalink

01/12/09

01:04:35 am Permalink YDN: More Accessible User Interfaces with ARIA

Categories: Usability & Accessibility, Front End Web Development

Review: More Accessible User Interfaces with ARIA at Skills Matter, 116-120 Goswell Road, London, England EC1V 7DP 18:30 to 20:00

I've long been meaning to take a closer look at WAI-ARIA, so last week's YDN talk at Skills Matter by YUI developer Todd Kloots seemed like an excellent opportunity to learn the basics. With them starting at half six, forcing me to travel halfway across London in the middle of rush hour, I often miss the start of Skills Matter events and this one was no exception - though this time the main problem was that they are now at new offices and I went to the old one first.

The talk was split into four parts, followed by some Q & A:

  • How ARIA solves problems of perception
  • How ARIA solves problems of context
  • How ARIA solves problems of discoverability
  • Tips and tricks for working with ARIA

How ARIA solves problems of perception

One of the problems faced by screen reader users is working out what a page element they come across is for and what state the element is in. A sighted user can look at a web page and easily see an area devoted to navigation and an area for main content, what things are toolbars and buttons and what state they're in (eg. bold mode in a text formatting toolbar).

How ARIA solves problems of context

HTML has only a limited palette of context setting elements - headings, lists and form grouping elements, such as h1 and fieldset can be used to indicate section breaks in your content. But if you wanted to indicate a tab control or a toolbar to assistive technology there's no standard markup to do that.

To address this ARIA has landmark roles, as we saw earlier, but it also allows you to indicate which sections of your page should be treated as a document and which should be treated as an application. In document mode, the screen reader responds to its own keyboard shortcuts for browsing, in application mode you can provide keyboard shortcuts for working with your widgets. ARIA also provides recommendations for keyboard shortcuts to use.

Todd discussed two ways of making sure your widget is keyboard accessible without drowning the user in choices. For example, if you have a toolbar widget you may not want the keyboard user to have to tab through every item on the toolbar every time they encounter it. It would be better if they could tab to select the toolbar but then tab again to skip over it if they didn't need any toolbar functions at this time. The two techniques are to use aria-activedescendent or to use a roaming tab index - set a tabindex of -1 on all the child elements of your widget and then adjust focus programmatically in response to key strokes. Todd has previously published a blog post which describes both focus management techniques in detail, he currently prefers the roaming tabindex approach because of its backwards compatibility (though watch out for the known focus event delegation issues).

How ARIA solves problems of discoverability

After you've created a keyboard accessible widget using ARIA roles and states you need to make sure users can actually discover your widget - all your good engineering work goes to waste if users never realise the functionality is there. This is where aria-live and aria-describedby are useful.

A live region allows text to be spoken to the user without that text gaining focus, thus losing the reader's place in the content. Depending on the nature of the message it can either be polite, assertive or rude - ranging from waiting until a pause or interrupting the user whatever they may be doing. An auto-complete list would be an ideal candidate for a live region - Todd demonstrated how live regions work on the Yahoo! Suggest feature on their search page.

The aria-describedby property allows you to link to a longer description of what your widget does, so you can inform the user, the first time they focus on your widget, of how to access the functionality of your widget as well as what to expect when they interact with it - again this was demonstrated in the suggest feature on Yahoo! search.

Tips and tricks for working with ARIA

The key tip if you're going to delve in ARIA is to install a screen reader and test things yourself! There are free ones for various platforms (eg. Windows and Linux). If you're unsure where to start, read this tutorial about setting up a test environment with NVDA and Firefox.

The second tip was more of a warning - ARIA gives developers a great deal of control over the end user experience, because it allows them to bypass the virtual buffer of the screenreader and talk directly to the user. This brings with it a risk - having all web browsing mediated by the screen reader made for a consistent user experience, now there's the potential for every site to be different leading to user confusion.

Q & A

There was an interesting question and answer session at the end. The first question was about the new semantic elements in HTML5 and whether screen readers were taking advantage of them yet - not so much, Todd felt that mush of ARIA is available today to far more users. Further questions brought up the frightening prospect of web developers having to take into account not just compatibility across various browsers but also a second dimension of cross screenreader compatibility and finally if any of the popular Javascript libraries had built in support for ARIA (YUI 3 has built in support).
http://skillsmatter.com/podcast/os-mobile-server/aria

All in all this was an excellent talk, 5 out of 5. One of the most technically detailed talks I've attended at Skills Matter - far more stuff was discussed than I've managed to fit into this blog post. If you're interested I recommend you watch the video.

Technorati tags for this review:    

Tweet this!
Send feedback »PermalinkPermalink