| Quarrel.Net | Online Flash Games | Browser Games | MySpace Layouts | Daily PSP Movie | |
 |
|
| Weblogs [Personal] (1861) | Weblogs [Tech] (699) | Business (2080) | Technology (1544) |
| News (601) | Miscellaneous (379) | LifeStyle (930) | Shopping (329) |
| Regionals (709) | Companies (1830) | Recreation (1568) | Political (49) |
| Other Languages (133) | Pets & Animals (52) | Romance & Relationships (60) | Celebrities (98) |
| Total feeds: 12922 |
| Add Your Feed |
| 456 Berea Street | |
[ Put this feed on your website - Click Here ] |
|
| Description: | 456 Berea Street is where Roger Johansson writes about web standards, accessibility, usability and other topics related to web design and development. |
| Format: | RSS 2.0 |
| Feed URL: | http://www.456bereastreet.com/feed.xml |
| Latest Headlines | |
456 Berea Street |
|
|
Validation statistics from Nikita the Spider
Tue, 29 Apr 2008 19:44:00 +0800 About a year and a half ago I mentioned Nikita the Spider: a bulk validation and link checking tool as a useful quality assurance tool. Well, Nikita the Spider has received a lot of fixes since then and has recently been taken out of beta. It is no longer completely free, but the first 125 pages it crawls will cost you nothing. But what may be more interesting is what Nikita finds when it crawls a site. Philip Semanchuk, Nikita's author, has analysed the statistics Nikita collected during March 2008 and walks you through the results in By The Numbers – March 2008. A few highlights: The most common validation error is neglecting to specify an alt attribute for img elements The second most common error is failing to escape ampersands XHTML doctypes are much more common than HTML doctypes Over sixty percent of the crawled pages use a transitional doctype Of course these statistics are only representative of a very small sample of the pages that exist on the web. In addition to that, those pages live on sites that somebody has actually asked Nikita to crawl, so it is likely that they are more aware of web standards than the average website owner/author/developer. It's still interesting reading though.Add 456 Berea Street to your Technorati favorites.Posted in (X)HTML, Web Standards. |
|
|
Authentic Jobs API and Affiliates program
Sat, 26 Apr 2008 10:10:00 +0800 If you've been looking for a new job or looking to hire a skilled web professional you may have come across Authentic Jobs. You may also have noticed that there have been Authentic Jobs listings on this site for some time. The news is that now anyone can display job listings on their site. You can also make some money when someone you refer posts a listing on Authentic Jobs. To display job listings you will need to apply for an Authentic Jobs API key, and once you have that you can start doing all sorts of with the job listing data. Find more details on that in The Authentic Jobs API Documentation. Even if you don't want to display job listings you can become an affiliate by applying for The Authentic Jobs Affiliate Program. Once you're approved you will get a personal code that you can use when referring people to Authentic Jobs. For each new full-time listing posted as a result of your referral you will get USD 75, and for each freelance listing your award will be USD 25. If you're completely new to Authentic Jobs, it is "a targeted destination for standards-aware designers and developers and the companies seeking to hire them." In other words, it is a place where companies looking for modern web professionals can find talent.Add 456 Berea Street to your Technorati favorites.Posted in Job openings. |
|
|
What does Acid3 mean to you and me?
Tue, 01 Apr 2008 09:59:00 +0800 So, last week two browser vendors proudly announced that their rendering engines now achieve a 100/100 score on the Acid3 Browser Test: Opera (Opera and the Acid3 Test) and Apple (WebKit achieves Acid3 100/100 in public build). Getting a 100/100 score does not mean that the browser has completely passed the Acid3 test, since there are other criteria as well - the animation has to be smooth and the final page has to be a pixel perfect match of the reference rendering. Despite that, it's great news to see browser vendors in a battle to implement standards first. Too bad the biggest two in terms of market share - Firefox and Internet Explorer - didn't take part in the Acid3 race. What I'm wondering is if, how, and when, this will help Web designers and developers like you and me. How long will it take for the other vendors to catch up enough that the standards that are tested by Acid3 can be used reliably? And what parts of the Acid3 test checks stuff that we really can't wait to use? What's your thinking on this?Add 456 Berea Street to your Technorati favorites.Posted in Browsers, Web Standards. |
|
|
Designing Web Navigation (Book review)
Wed, 19 Mar 2008 19:50:00 +0800 What? An entire book just about designing navigation on the Web? Yes, that's right. And if you think about it for a while you'll probably realise that there is a need for a book on that subject. Heck, considering the number of sites out there that are incredibly hard to navigate, there is room for plenty of books that explain how to create Web navigation that works. And you're very likely to have run into problems more than once when trying to figure out how to make a website or Web application easy and intuitive not only for yourself, but for your own or your client's end users, to find their way around. Designing Web Navigation by James Kalbach aims to help you master the fundamentals of navigation design. While there is no guarantee that you will master the subject, reading this book will definitely give you a lot of insight into the problems that you encounter in navigation design as well as possible solutions to those problems. The way Designing Web Navigation is structured makes it usable not only as a book you read from cover to cover, but also as a reference to keep handy for the next time a tricky navigation problem shows up. It can also give you arguments to use in discussions with clients or other team members when there is something that doesn't feel quite right about the solution somebody is suggesting but you can't put it into words. In fact, it may also make you look at the problem from a different angle and realise that maybe your solution isn't the best one. The author starts the first part of the book by explaining the foundations of Web navigation. Those foundations include why we even need navigation in the first place, how we use Web browsers to interact with websites, the most common types of navigation on the Web, and how we can label navigation to make it easy to understand. The second part of the book is called "A Framework for Navigation Design", and is focused on providing you with a systematic approach to designing Web navigation. It does that by describing a number of phases that you will often move through while turning a concept into a working navigation system. In the third and final part, James Kalbach takes a closer look at navigation in special contexts, such as before and after searching, in social tagging systems, and how Web applications can be navigated. Throughout the book there are many references to accessibility and internationalisation issues that can be caused by some types of navigation. It's great to see that those two very important aspects of Web navigation aren't overlooked here as they are in many other places. Overall this is a great book that I enjoyed reading. The examples and references are current and credible. One area that has room for improvement is the layout and typography, which I think could be more usable. Line-length is a bit too long for the book to be a really comfortable read, and page numbers are smaller than the text on websites designed by ad agency art directors. But don't let that discourage you from picking up a copy of this book. My impression is that there is a lot of research behind this book, and I think all web designers and front-end developers can learn something from it. Designing Web Navigation Author: James Kalbach ISBN-10: 0596528108 ISBN-13: 978-0596528102 Add 456 Berea Street to your Technorati favorites.Posted in Reviews, Usability. |
|
|
DOMAssistant bundle for TextMate
Mon, 10 Mar 2008 19:41:00 +0800 Like many other Mac users I do most of my coding in TextMate. It has tons of really nice features, one of which is its extensibility – if you need support for a coding language that isn't included with TextMate, you can add it yourself. Well, I've been using Robert Nyman's DOMAssistant JavaScript library quite a bit lately, and TextMate doesn't support DOMAssistant's methods and syntax. I was getting a bit annoyed at knowing that I was doing a lot of unnecessary typing because of this, so I decided to create a TextMate bundle for DOMAssistant. Armed with my copy of TextMate, James Edward Gray II's excellent TextMate: Power Editing for the Mac, and the DOMAssistant documentation, I started hacking away. This was the first time I took a closer look at adding support for a language in TextMate, but it turned out that it really isn't that difficult. After a few hours of work, the result is a DOMAssistant TextMate bundle with tab triggered snippets for all methods, a code completion dictionary, and documentation links for all DOMAssistant keywords. Google Code project: textmate-domassistant Direct download link: DOMAssistant-tmbundle-1.0.zip If you use TextMate and DOMAssistant I think this will save you a few keystrokes :-). Suggestions for improvement are welcome. Remember that this is my first TextMate bundle, so please be gentle.Add 456 Berea Street to your Technorati favorites.Posted in Coding, JavaScript, Mac, Productivity. |
|
|
First impressions of Internet Explorer 8 Beta 1
Fri, 07 Mar 2008 14:17:00 +0800 So Microsoft released the first beta of Internet Explorer 8 to the public the other day. Press releases and documents on the IE 8 site contain plenty of exciting promises of new and improved features, such as: Full and complete CSS 2.1 support Partial CSS 3 support Better JavaScript performance Fixes for a number of long-standing JavaScript bugs Built-in developer tools WAI-ARIA support It all sounds very promising, but if you're hoping for IE 8 Beta 1 to catch up with other contemporary browsers, you'd better lower your expectations a bit. I had high hopes after reading about the new features and improved support for standards Microsoft are aiming for in IE 8, but after trying out Beta 1 I have to say that I am a little disappointed. Yeah I know, I know. It's a beta version, so bugs and problems are to be expected. I still thought IE 8 Beta 1 would be more polished than it is. Anyway, here are some of the areas I have looked a little closer at. CSS 2.1 Microsoft have made it clear that they aren't done with the CSS 2.1 implementation yet and that there is much more to come in Beta 2, so things will improve. After checking a bunch of the sites I've built recently in IE 8 Beta 1 I can verify that CSS 2.1 support is not complete – some things break. Full CSS 2.1 support is very, very promising though, so I really hope the IE team manages to fulfill this promise. Built-in developer tools Internet Explorer is in desperate need of a reliable debugging tool on par with Firebug, and IE 8 does have built-in developer tools for CSS and JavaScript debugging. Great! I suppose it's unfair to compare IE 8's developer tools to the excellent Firebug extension, but it can't be helped. Firebug has set the bar for what any browser based developer tools need to match. Unfortunately IE 8's developer tools are currently very lacking in features, look very unpolished, and seem quite buggy. They don't come anywhere close to Firebug. Like CSS 2.1 support, Microsoft is open about the developer tools not being finished, so they will hopefully be much improved in the next beta release. Zoom Since IE 8 still refuses to resize text sized in pixels, zoom functionality is very important for people who need larger text. Zooming in IE 7 is a mess, and it is supposed to be improved in IE 8. So is it? Well... yes and no. Zooming is less likely to create massive horizontal scrollbars than in IE 7, but it has major problems on some sites, where zooming just one step completely destroys the layout (try it on this site to see what I mean). Talk about breaking the web... Zoom appears to need more work before it becomes usable. Looking forward to Beta 2 I realise I may be coming across as being a bit negative here, but I was really hoping for more after Microsoft's surprising move to let IE 8 use its most compliant standards mode by default. I guess I was hoping for too much at this stage. To end this on a positive note, it's excellent to see the improvements mentioned on the IE 8 website. Beta 2 is sure to deliver much more than Beta 1, and I'm looking forward to it.Add 456 Berea Street to your Technorati favorites.Posted in Browsers. |
|
|
Surprise of the year: IE8 will use Standards mode by default
Tue, 04 Mar 2008 08:36:00 +0800 When I woke up this morning and checked my RSS feeds I had to rub my eyes and look again. Was I still asleep and dreaming? But no, I was awake, and what I saw reported from multiple sources is that Microsoft has reversed its decision to make IE8 behave like IE7 unless specifically requested. Wow. I didn't see that coming. And even more surprising is their reason for making the change. In Microsoft's Interoperability Principles and IE8 on the IEBlog, IE General Manager Dean Hachamovitch says: In light of the Interoperability Principles, as well as feedback from the community, we're choosing differently. Now, IE8 will show pages requesting "Standards" mode in IE8's Standards mode. Developers who want their pages shown using IE8's "IE7 Standards mode" will need to request that explicitly (using the http header/meta tag approach described here). And in a press release titled Microsoft Expands Support for Web Standards, Microsoft chief software architect Ray Ozzie states that there is a concrete benefit to Web designers if all vendors give priority to interoperability around commonly accepted standards as they evolve No, I'm not making this up. It seems like Microsoft actually listened to the developer community, which is so surprising to me it hasn't quite sunk in yet. As a standards-advocating web developer I have become so used to Microsoft completely ignoring the needs of myself and my fellow standardistas that I could never have imagined them changing their minds on this. And it doesn't stop there. Dean Hachamovitch goes on to say that: Long term, we believe this is the right thing for the web. Shorter term, leading up not just to IE8's release but broader IE8 adoption, this choice creates a clear call to action to site developers to make sure their web content works well in IE. And Ray Ozzie hints at better education for developers who do not use web standards: we will work with content publishers to ensure they fully understand the steps we are taking and will encourage them to use this beta period to update their sites to transition to the more current Web standards supported by IE8 Sounds great. Thanks for listening! I hope that this new focus on web standards and interoperability also means cleaning up the horrible, stinking, inaccessible piles of code that are regurgitated by products like MOSS and Visual Studio. I also hope that it means educating Visual Studio cowboys to use and understand web standards.Add 456 Berea Street to your Technorati favorites.Posted in Browsers, Web Standards. |
|
|
Specify a maximum width for em-based layouts
Mon, 03 Mar 2008 07:51:00 +0800 As someone who likes to bump up text size a notch or even two on many sites, I often notice that this behaviour is not something that web designers in general anticipate. However, layouts do tend to be a little bit more robust now than a few years ago, at least at a moderate increase in text size. That's good, though I think in many cases it is just a matter of luck that nothing gets obscured as text size is increased. One technique that can easily make reading a site a lot more uncomfortable is using an elastic, or em-based, layout such as the one I use here (and talk about a bit more in detail in Fixed or fluid width? Elastic!) without specifying a maximum width in another unit. I've come across a few of those recently, which could perhaps be explained by the fact that the preset fixed width layouts created by YUI Grids CSS are of this kind. Since the em unit is tied to the browser's text size, increasing that size will have consequences. Let's say you have specified that the total width of a layout is 60em. As text size is increased, so is the entire width of the layout. In the absence of a max-width CSS property that uses another unit, like pixels or percent, that will rather quickly lead to horizontal scrolling - and plenty of it - unless you're browsing with a very wide window on a very wide screen. And how is that a problem? Well, if you need larger text, you're likely not going to appreciate that in order to get larger text you will have to put up with a lot of horizontal scrolling to find parts of the site. It doesn't make the site completely inaccessible or impossible to use, but it does make things harder for anyone who likes larger text and does not use a very wide browser window. Alastair Campbell talks more about the issues this can cause (and why "elastic" may not be the ideal name for em-based layouts) in Elastic layout - wrong term?. So just a heads-up: when creating an em-based layout, consider using max-width instead of width. As for IE 6, which does not understand max-width, I tend to either use a dynamic property to give it a maximum width in pixels or just give it a fixed width (again, in pixels). I think both options are better than setting a fixed width in ems since they are less likely to cause massive horizontal scrolling at large text sizes.Add 456 Berea Street to your Technorati favorites.Posted in Accessibility, CSS, Usability. |
|
|
The WCAG Samurai Errata are now available
Thu, 28 Feb 2008 07:42:00 +0800 It took nearly two years, but two days ago on 26 February 2008, version 1.0 of the WCAG Samurai Errata for WCAG 1.0 were finally published. As stated in the Introduction, this version is also likely to be the final version. A quick summary for anyone who is not familiar with the WCAG Samuari or their WCAG 1.0 errata: The WCAG Samurai consisted of a group of accessibility and standards-aware web developers brought together by Joe Clark in 2006. The group's goal was to create a document that provides corrections and updates for the Web Content Accessibility Guidelines (WCAG) 1.0. The reason to provide corrections is that since WCAG 1.0 was originally published by the W3C in 1999, both web browsers and assistive technologies have evolved. At the same time, accessibility-aware web developers have learned and invented a lot of techniques for building accessible websites. Developers have also learned that some of the techniques that were useful in the past are no longer needed or even cause problems for users. The WCAG Samurai errata thus removes, rephrases, and adds information that makes WCAG 1.0 more applicable to today's Web. You might also want to read Joe Clark's WCAG Samurai errata released, where he talks a bit more about the errata and the development process used. So do the WCAG Samurai Errata actually contain any improvements? Yes, definitely. I don't agree one hundred percent with every word in the errata, but all in all I think they make a lot of sense and match what I strive for in my daily work. Note that you can't use the WCAG Samurai Errata as a standalone document. It should be used in combination with W3C's WCAG 1.0.Add 456 Berea Street to your Technorati favorites.Posted in Accessibility. |
|
|
DOMAssistant 2.6 released
Tue, 26 Feb 2008 21:40:00 +0800 Last week Robert Nyman updated the DOMAssistant JavaScript library to version 2.6. As always with a new version of anything there are a number of new features and performance enhancements, but this release also marks a couple of other changes for DOMAssistant. First a couple of words about performance. In DOMAssistant 2.6, the performance of CSS selectors has been improved a lot – run the SlickSpeed Selectors Test to see just how fast it is. Opinions on the usefulness of the SlickSpeed test vary, but no matter how you spin it, DOMAssistant's CSS selectors are really fast. A new feature is support for plugins, which among other things will enable people to add stuff like animations and superfluous visual bling bling. The plugin model can of course be used to add useful functionality as well :-). In order to make DOMAssistant a little less of a one man show and more of a community, Robert also asked a few people, including myself, to join the DOMAssistant Team. Sure, the community around DOMAssistant is still small when compared to that of the major JavaScript libraries on the market. I don't think that's a problem really, since I'm not so sure that massive amounts of forum or mailing list traffic automatically means that something is good. For Robert's own, more detailed, description of the news and changes in DOMAssistant 2.6, read his post on the DOMAssistant development blog: Releasing DOMAssistant 2.6 - overall fastest CSS selectors, plugins and more. If you're like me and are more interested in building websites than trying to emulate desktop applications in the browser, DOMAssistant should appeal to you. Give it a try. If you like it, great! If you prefer another library or framework, good for you. Just be aware of the options.Add 456 Berea Street to your Technorati favorites.Posted in JavaScript. |
|
Webmasters - Another button for your collection
FeedBoy.com © 2005-2007
Hosted By NeonHQ
Partners
Quarrel.Network |
Browser Games |
Online War Games |
Mafia Game |
Online Flash Games
Singapore Outsource |
Backpacking Travel |
Legal Glossary |
Mobile Ringtones |
Internet Marketing
PT Cruiser |
Car Videos |
Honda Car Forum
Turnkey Scripts |
Photoshop Tutorials |
RSS Protocol |
Linux Web Hosting
Zoekmachine Optimalisatie |
DirArchive Web Directory |
Sidney Cosby |
Free Teen Webcam Chat |
Free Video Chat
Orlistat |
International City |
Alli |
Groovy Java Games