Slashdot Mirror

Looks like stockart are good at doing this sort of thing. See this blog post for more info.

Bloggers: 43 Folders, Kris Dresden, Diane Duane, Paul Ford, Neil Gaiman, Michael Hanscom, Jason Kottke, Anne Murphy, Jessamyn North, Alia Phibes, Quentin Tarantino, and Wil Wheaton.

Linklogs: Anil Dash, Best of Craigslist, Boing Boing, CoolGov, Daze Reader, Fazed, Kottke Remainders, LinkMachineGo, MetaJournal, Michael Hanscom's Linklog, Museum of Hoaxes, NewYorkish, Paul Ford's Linklog, Snopes: New, SubText, and UFies.org.

Chicago: Chicagoist, jamas.org, CHICAGO.Metroblogging, Chicago Snapshot, CTA Tattler, Gapers' Block, and L or El.

Miscellaneous: Ask Slashdot, Citying, Cult of the One-Eyed Cat, Good Plastic Surgery, I Work With Fools, Schmo Blog, TeeVee, This Is Broken, Today In Alternate History, and x-entertainment.

Apple Bloggers: Buzz Andersen, Bill Bumgarner, Todd Dominey, Folklore, Steven Frank, John Gruber, Dave Hyatt, Brent Simmons,

As for many of the animations, fades, slides, etc in the widgets themselves., they simply look so damn cool because of Safari's rich support for CSS3 used in conjunction with DHTML.

What follows is from What do I know

-----------

Get Ready for IE Changes

Apple has posted helpful developer documentation concerning the changes Microsoft will be making (as required by the Eolas case) to Internet Explorer in early 2004, and how web developers (on any platform) can prepare now in advance:

• Creating the Best User Experience for Active Web Content
• Authoring Websites for Compatibility with Internet Explorer for Windows FAQ
• Preparing Websites with Active Content for Upcoming Changes to Internet Explorer for Windows

To prepare yourself for the ensuing insanity, solution includes using external javascript files to write (document.write) the object / embed tags into a document instead of directly writing the tags into your code. This means that each and every piece of embedded content (Flash, QuickTime, Java, whatever) would require a unique external javascript file, or a builder-function you pass attributes to to embed your rich content.

By abstracting the embedding process through JavaScript, rich media content will behave in the same seamless, non-user initiated manner it currently does. But if developers don't abstract the object/embed elements, and a visitor views the page using the upcoming revised build of IE, they will have to click through a series of dialog boxes granting permission for their browser to load the content.

Whichever way, the new workarounds will lead to page bloat, additional server-calls, confusion, and additional monetary expense / time suckage for businesses and web developers everywhere. Yay Eolas.

What follows is from What do I know

-----------

Get Ready for IE Changes

Apple has posted helpful developer documentation concerning the changes Microsoft will be making (as required by the Eolas case) to Internet Explorer in early 2004, and how web developers (on any platform) can prepare now in advance:

• Creating the Best User Experience for Active Web Content
• Authoring Websites for Compatibility with Internet Explorer for Windows FAQ
• Preparing Websites with Active Content for Upcoming Changes to Internet Explorer for Windows

To prepare yourself for the ensuing insanity, solution includes using external javascript files to write (document.write) the object / embed tags into a document instead of directly writing the tags into your code. This means that each and every piece of embedded content (Flash, QuickTime, Java, whatever) would require a unique external javascript file, or a builder-function you pass attributes to to embed your rich content.

By abstracting the embedding process through JavaScript, rich media content will behave in the same seamless, non-user initiated manner it currently does. But if developers don't abstract the object/embed elements, and a visitor views the page using the upcoming revised build of IE, they will have to click through a series of dialog boxes granting permission for their browser to load the content.

Whichever way, the new workarounds will lead to page bloat, additional server-calls, confusion, and additional monetary expense / time suckage for businesses and web developers everywhere. Yay Eolas.

Hehe, Slashdot's not really a shining example of web accessibility, but it's a good place to ask for help none-the-less.

The first stops for help (as someone's no doubt pointed out already) should be:

Section 508

Mark Pilgrim's excellent "Dive Into Accessibility"

The W3C's web accessibility guide

The UK Disabled Rights Commission website, paying particular attention to the superb Interactive Demos (e.g. Inaccessible Website Demo).

Buy these books:

Constructing Accessible Websites

Building Accessible Websites

Oh, and a copy of Zeldman's Designing With Web Standards for good measure.

Write your pages using validating HTML or XHTML, and style the pages using CSS.

Validate your webpages using the W3C Validator and your CSS using the W3C CSS Validator. Use Watchfire's Bobby to validate your pages, and aim for AAA rating (also note that Bobby has some helpful hints when it does find errors).

Other excellent resources (in no particular order):

http://www.webstandards.org/
http://www.w3.org/WAI/References/QuickTips/
http://www.mezzoblue.com/
http://www.meyerweb.com/
http://www.simplebits.com/
http://www.whatdoiknow.org/
http://www.stopdesign.com/

check what do i know?.
todd bought one recently and posted a long rant on it.