tech support 8

  • Subscribe to our RSS feed.
  • Twitter
  • StumbleUpon
  • Reddit
  • Facebook
  • Digg

Sunday, 1 December 2013

Web Development Advent Calendars for 2013

Posted on 05:46 by Unknown

Photo of an advent calendar with a leg lamp, potted ivy, and small statue of Ganesha.
Ganesha may or may not be stealing chocolate from the advent calendar.




For a few years now web developers around the world have celebrated Saturnalia Christmas with advent calendars covering topics related to the web. Some come and go, but you'll probably recognize a few regulars on this list.




I may have missed some, so please pass them along if you know of any. For those I know are not returning, I have listed them at the end.




1. 24 Ways




24 Ways, the one that most of this think about for web development calendars, is back again. It's been going strong since 2005 and based on its history this year should have some good articles.




2. Perl Advent Calendar




Perl Advent Calendar goes all the way back to 2000 (and back then looked a bit more like a traditional advent calendar, too) and has been dispensing tips for Perl developers ever since.





3. 24 Jours de Web




24 Jours de Web is starting its second year as an advent calendar for web folk. Written in French, it is clearly primarily targeted at French speakers, but a round of Google Translate will open it up to far more readers (like me).



4. UXmas




UXmas is an advent calendar aimed at the user experience community. Coming from Australia, American readers may be thrown just a bit by the schedule. The calendar promises everything from sketches, to articles, to tools, to videos.



5. Webkrauts




Webkrauts has an all German advent calendar, and it also dates back to 2005. It covers general web topics, but being in all-German readers like me will benefit from a Google Translate version of the page.



6. 12 Devs of Xmas




12 Devs of Xmas will also start the day after Christmas and go for 12 days from then. When all the other calendars have wrapped up, you'll still have one to read. The site is silent on its return, but this tweet suggests it's gotten writers and has a plan.



7. Freelancember




Freelancember 2013 is targeted squarely at freelancers. Its daily entries will consist of downloadable gifts in the form of PDF worksheets. Think of this as less about web-tech and more about MadLibs for projects. It has last year's calendar there as well, and so far (as of December 1) I cannot tell the calendar will just be a repeat of last year.



8. Mozilla Developer Network Holidays calendar




Mozilla Developer Network Holidays calendar includes brief links to resources or demos and suggests that you can edit them (if they are MDN resources). It doesn't link to previous years, but you can just hack the URL.



9. SysAdvent




SysAdvent is targeted to systems administrators, but there is a some cross-over to web developers. It has posts dating back to 2008 (and yet I missed it in last year's collection), so there is plenty of good material there if you're too impatient to wait for each day to be revealed.



10. Web Accessibility Advent Calendar 2013




Web Accessibility Advent Calendar 2013 is in Japanese, and thanks to the wonderful powers of Google Translate, I can tell you that it is a calendar to make the talk about Web accessibility (based on this statement: Webアクセシビリティに関する話題でつくるカレンダーです。). If you know Japanese, I welcome any corrections. The site Adventar.org appears to host other advent calendars, some about web technologies, some about ramen.




Not Returning




A handful of calendars aren't returning this year (so far), but in most cases content from previous years is still available. These include Font Deck's Adfont Calendar (which also skipped 2012), the Fronteers advent calendar (in Dutch, and also skipped 2012), Web Advent (it's taking a year off), Performance Calendar, HTML & CSS Advent (this is the 2012 calendar), She Said It (no access to old calendar), 12 Days of Podcasts (or at least there is no indication on its site or Twitter).



Not Web Related




ScienceGeek Advent Calendar Extravaganza is not web-related at all, and frankly it isn't promoted nor is it tagged (although I linked to “special” since that tag had the first day and nothing else). It is, however, probably going to be neat stuff given the first day is a giant image of the Christmas Tree Cluster.

Read More
Posted in accessibility, css, design, fonts, html, internet, mobile, standards, usability, UX | No comments

Wednesday, 27 November 2013

Thanksgiving, Technology, and Just Picking a Fight

Posted on 14:09 by Unknown


November 25: Update Your Parents' Browser Day, with photo of little girl and perhaps father at computer.

My logs tell me that nobody took this 2011 plea seriously. I blame the typeface.




Last year on Thanksgiving I made the case for ignoring social media for the day. I felt strongly enough that for the new year I even wrote about some social media behavior goals for the coming year that we could all try to follow.




The year before I cautioned you that you might get wrapped up in helping your parents (or elders in general) with tech support issues (like upgrading browsers, surfing tips to save a turkey that has caught fire, and so on).




Those are both a far cry from the prior two years where I wrote about how nifty social media could be for the holidays. Oh the heady days of 2009, with so much opportunity to come from so much interconnectedness.




In the span of four short years I had mostly decided that social media can make for an awkward and unpleasant holiday if not used properly (or, in some cases, if used at all).



Let's Try Something Different




Maybe we should try to have ourselves a completely disconnected, proper face-to-face meal. I know this is difficult, but this time around I'm supplying talking points!



Politics!




The President of the United States of America has decided we should talk about Obamacare. He says that, chances are, folks at the dinner table probably look to you, mostly as a voice of reason, on the subject. And so his team has put together a brand new site just for the holidays: It's time to have the talk.




I should note, this site was most likely not done by the same folks who built HealthCare.gov. I do, however, think they were vying for a front-page spot over at TC;DR (Tab Closed; Didn't Read):




Screen shot of holiday discussion cheat sheet at barackobama.com.
And let's not even get started on the print styles.




It's impossible to make jokes about political subjects without people assuming it's a political statement. On balance, I also offer a link for the other side of the table: Healthcare.gov and the Gulf Between Planning and Reality. The advantage here is that each side will actually be talking about different things. How is that not hilarious?




Science!




Maybe you can pose a question to the table without letting on that you know the answer? Haven't you ever wondered how many batteries it might take to cook a turkey? I haven't. But Wired thinks it's a worthy topic: How Many Batteries Would It Take to Cook a Turkey?




I'll spare you the effort of clicking the link. Just do this quick math for a 10-pound bird starting at room temperature:





Solve for black bar.



Language!




If you have any pedants in your family, perhaps you'd like to quiz them on the history of the word turkey. Dictionary.com has a digestible (and according to the comments, mostly accurate) post that covers it: The Mistake that Gave Turkey (the Bird) the Same Name as Turkey (the Nation)



Or Just Suck It Up and Be Tech Support




If all goes wrong or you just can't get people to bite on any debate, then you can always fall back to the safety net of tech support. Heck, you might even end up like this guy: In Which I Fix My Girlfriend’s Grandparents’ WiFi and Am Hailed as a Conquering Hero.




Now go relax. Read The Oatmeal's comic on Thanksgiving as a Kid vs. as an Adult. Prepare for where you'll sit using College Humor's Thanksgiving Seating Chart (which ties in nicely with The 8 Relatives You'll Talk to at Thanksgiving). Take this Map of Thanksgiving Dinner to plan your assault on Crudités Dam. Maybe you can debate the merits of the turkey that, like an &lquo;elected” prom king or queen, will be the National Thanksgiving Turkey as designated by the White House:



Confused. Is the White House asking us to choose which turkey, by exclusion, dies? http://t.co/aWNmLnLdF2 #TeamCaramel #TeamPopcorn

— Adrian Roselli (@aardrian) November 26, 2013




While they are both pardoned, they'll still die an early death.




In short, disregard your family and stare at your computer/phone all day, just like the moody teen we all truly are.

Read More
Posted in internet, social media | No comments

Sunday, 24 November 2013

Image alt Exception Change Re-Re-Re-Requested

Posted on 14:38 by Unknown


HTML5 logo — I am the 'alt,' not the 'title'
This post is an unexpected follow-up to my post Image alt Exception Change Re-Re-Requested (note one fewer “re-”) from June 2012. Back then, some had called into question the need for alt attributes to be required and ubiquitous on all img tags.




Well, guess what — alt is back under review.




The Web Content Accessibility Guidelines (WCAG) working group is reviewing (and soliciting feedback on) changes to determine how a page may fail WCAG Guideline 1.1 Text Alternatives, which outlines how a page uses the alt attribute for images. This also means changing the techniques authors may use to pass Level A validation for WCAG SC 1.1.1.




To simplify, the discussion is centered on allowing authors to omit alt if the author uses aria-label, aria-labelledby, or title attributes. For example, the following three examples would all be valid:




<img src="fox.png" title="Photo of a fox reading aloud from a book.">
<img src="fox.png" aria-label="Photo of a fox reading aloud from a book.">
<img src="fox.png" aria-labelledby="FoxPic">
<p id="FoxPic">Photo of a fox reading aloud from a book.</p>



David MacDonald has already captured the arguments for and against that are already being bandied about, which I reproduce here:



Arguments for the Change





  • These alternatives on the img element work in assistive technology;

  • The ARIA spec says these attributes should get an accessible name in the API;

  • They say it's easy to teach beginner programmers to just always use an aria-label on everything, rather than requiring a label on form fields and alt on images;

  • They feel that F65 is overly strong since it can fail the entire page for a single missing alt (regardless of the validity of the rest of the page), and they would like to soften it to allow those other valid elements to carry the page;

  • HTML5 allows a figure/legend combination instead of alt, so they feel WCAG will have to change F65 regardless in order to allow a figure with a legend, and that helps open the door to this discussion.





Arguments against the Change





  • aria-label, aria-labelledby, and title, are not really suitable attributes for img alternative text because they imply a label or title, rather than alternate text, so they are not semantic equivalents;

  • title is not well supported;

  • Some feel that the ARIA spec is not in any way suggesting these as replacements to alt;

  • ARIA instructs authors to use native HTML where possible, and they could not come up with viable use cases for omitting alt text;

  • There are hundreds of millions of dollars invested in current evaluation tools and methodologies, and this would represent a major departure from one of the most basic accessibility conventions, one that is almost as old as the web and is the “rock star” of accessibility;

  • It could cost a lot of money to change guidance to developers and muddy the waters on a very efficient current evaluation mechanism;

  • When the figure/legend combination is supported by assistive technology we can amend F65, but that is a different issue and the semantics of this construct are OK for text alternatives, rather than the aria-label, aria-labelledby, and title options;

  • It may cause some confidence problems to WCAG legislation because it represents a strong loosening to a fundamental Success Criteria, an unnecessary change that doesn't help the cause of accessibility, but just complicates things;

  • alt is better supported;

  • The alt text appears when images are turned off;

  • Initial twitter feedback from the community is strongly against changing this failure.



Where You Come In




You don't have to be a part of any standards body to weigh in with your opinion. You can leave comments here and I will happily carry them back to those discussing this (even if I don't agree). You can also let me know on Twitter or you can let Steve Faulkner know, as he is one of the HTML editors.



My Opinion




It is my understanding that ARIA was intended to cover the gaps where HTML didn't already have elements or features to enable accessibility. Moving to supplant an accessibility feature that is widely understood and broadly supported with one that most web developers don't understand seems like a step backward, especially when that specification should fall away in time.




There is also the case to be made for the current status of WYSIWYG editors and code generating features of CMSes. It's taken more than a decade, but for the most part they have support for alt. It seems unlikely that these tools will implement logic to exclude alt when there are valid aria- or title attributes, so they will probably still include alt regardless.




Revisiting HTML elements and attributes is warranted and should be part of the process. We've removed oddities such as hgroup and re-instated valuable bits like time. However, I am not sure why alt seems to get an annual review when it has clear history and use cases.




My very quick responses to the arguments outlined above:



Alternatives to img work in assitive technology




I am not an AT user, so I cannot address this other than to say that it is my understanding that the alternatives work inconsistently across AT whereas alt has a far more consistent experience.



ARIA says these attributes should get an accessible name




That may very well be the case, but should itself doesn't require it.



Easier to teach aria-label on everything, rather than requiring a label on form fields and alt on images




I think there is a false dichotomy here. In modern development shops, the team making forms isn't necessarily the one placing images. Labels have a clear functional association that mirrors desktop software experiences. Alternative text for an image is not a label, though sometimes it may be considered such. This also implies the label element itself may be replaced with aria-label, which isn't the point of ARIA.



Missing alt can fail an entire page




As far as I am concerned, if your entire page fails accessibility validation because of a missing alt, then that is a valid failure. It stands to reason that some items should fail regardless of how perfect the rest of the code may be. Softening the failing power of alt can be a separate discussion, but allowing it to be bypassed seems like a blanket solution. I can't imagine an entire new building is considered accessible even though there is no ramp to bypass the front steps.



Since HTML5 allows a figure/legend combination to bypass alt…




This goes back to my original resistance to allowing any exceptions for alt. I worried that any exceptions would be used as a wedge to ultimately tearing down alt. As such, I don't consider this a valid argument. If anything, it should be used as an argument to re-examine the value of making exceptions for alt and perhaps rolling them back (counter-suit!).




Related (on this blog)




  • Image alt Attributes Not Always Required in HTML5, April 19, 2011.

  • More on Image alt Requirement in HTML5, May 2, 2011.

  • Image alt Exception Change Re-Re-Requested, June 11, 2012.

  • Still Guessing on Accessibility, January 31, 2013.



Update: November 27, 2013




It is possible for W3C non-members to post their opinions/thoughts to the Accessibility Task Force list (one of the lists where this being discussed). Source:



@patrick_h_lauke anyone can mail public-html-a11y, it just may take some time to show up on list http://t.co/sFe84xMDio :) cc @stevefaulkner

— Mark Sadecki (@cptvitamin) November 27, 2013



@chaals @patrick_h_lauke @w3c all a11y TF moderated emails are being redirected to the list as quickly as they can, w/in minutes of posting

— Mark Sadecki (@cptvitamin) November 27, 2013




All the info you need to respond (reproduced here):




  • E-mail discussions taking place on the HTML Accessibility TF's W3C mailing list, public-html-a11y.

  • Weekly (or less frequently, as needed) HTML Accessibility TF teleconferences with minutes distributed to HTML Accessibility TF mailing list (archive);

  • Sub-group teleconferences with minutes distributed to HTML Accessibility TF mailing list;

  • The HTML Accessibility TF Wiki.

  • The HTML Accessibility TF may use Web-based surveys instead of email to poll group opinion.


Read More
Posted in accessibility, html, standards, W3C, WAI, WCAG | No comments

Friday, 22 November 2013

Print Styles Are Media Queries

Posted on 13:07 by Unknown



I have alluded to this point in the past. Usually when I get off on a rant about print styles, I lump it into the overall process of making responsive sites and I use media query formatting in my examples. But I haven't just flat-out said that print styles are media queries.




I believe I always assumed that the reader would just understand that in the context of my writing, in using print styles on sites, and understanding that print is a medium in which web pages have been displayed for years.




Peter-Paul Koch (@ppk on Twitter) has spent years tracking browser support for even some of the most minute features. From way back in the evolt.org days I've watched him dive into testing without concern for his own wellbeing (browsers have sharp edges). Most recently he put out calls on the Twitters for web developers to fill out a survey about how they use media queries.




I did not grab a screen shot of the survey, but he asked the following two questions (which you can glean from the raw results):




  1. Which media queries have you used AT ALL in practical projects in the past year?

  2. Which media queries have you used in MORE THAN HALF of your practical projects in the past year?




He presented the following options:




  1. width

  2. height

  3. device-width

  4. device-height

  5. device-pixel-ratio

  6. resolution

  7. orientation

  8. aspect-ratio

  9. device-aspect-ratio

  10. Other




You'll note that “print” is not an option. Despite that, 1% of his respondents to the questions (of the 33 and 23, respectively, that chose “other”) wrote in “print,” because that's what this chart indicates in his write-up (Media query/RWD/viewport survey results):



























































Media query use
Media query Regular use Occasional use
width 84% 7%
device-width 32% 15%
device-pixel-ratio 25% 18%
height 17% 16%
orientation 13% 20%
resolution 9% 5%
device-height 7% 7%
aspect-ratio 3% 4%
device-aspect-ratio 3% 3%
print
1% 1%




I want to be clear, I am not faulting PPK. His survey was very much about the work he's been doing lately understanding how viewports, pixel densities, and screen sizes are reported across the current landscape (jungle) of devices. Instead, I am happy that 1% of his 1,251 respondents consider print to be a media query and took the time to make it a write-in answer.




Now I just wonder how long before the other 99% would do the same. Or even for the much smaller percentage who write media query tutorials, examples, libraries, CMSes, and so on.




@ppk I’m really sad there are only 1% print MQs…

— Nicolas Hoizey (@nhoizey) November 22, 2013



Related




If you want to learn how print media queries can be useful to you, please follow the links below (which themselves contain many more links). “The more you know.”




  • My WordCamp Buffalo 2013 Presentation: Making Your Site Printable, Sept. 14, 2013.

  • My Presentation Slides: Making Your Site Printable, May 19, 2013.

  • Tracking When Users Print Pages, Mar. 26, 2013.

  • Calling QR in Print CSS Only When Needed, Mar. 8, 2013.

  • My Print Styles Article in .net Magazine, Jul. 18, 2012.

  • Announcing PrintShame.com, Apr. 9, 2012.

  • More Evidence of the Need for Print Styles, Apr. 6, 2012.

  • Test in Lynx and Print, It's Your Job, Dec. 12, 2011.

  • More Samples of Responsive Web Design ≠ Print, Oct. 13, 2011.

  • Print Styles Forgotten by Responsive Web Developers (at evolt.org), Oct. 4, 2011.

Read More
Posted in css, print, standards, usability, UX | No comments

Wednesday, 13 November 2013

Captions in Everyday Use

Posted on 11:35 by Unknown


Yesterday Henny Swan asked a simple question on the Twitters:



I'm curious to know, who uses subtitles on web content (X device) who's not deaf or hard of hearing? For example I did when breastfeeding.

— Henny (@iheni) November 12, 2013




Adam Banks put together a Storify of the responses that show there are plenty of use cases for those not hard of hearing to get value from closed captioning.




In general, any context where either the audio track is loud enough that the viewer doesn't want to disrupt those nearby, or the background noise is too much to hear the audio track clearly, is a case where captions have value for all users. Other cases that popped up include multi-tasking or working with a new language or just tough accents.




In short, closed captions have value for all users.




There is also no reason to panic about providing them, particularly if you use a video service that can do them for you. For example, back in 2010 YouTube committed to enabling auto-captioning for everyone, and Google has documents to help plus tutorials from others, such as this step-by-step or or this video.





Image of the captions in use on President Obama's speech about the Chile earthquake.




Of course, as I was writing this post, Henny posted her own reference to the Twitter conversation: The weird and wonderful reasons why people use subtitles / captions




The Storify of responses I mentioned above is embedded here to spare you all the hassle of clicking the link and to bloat my page with unnecessary script blocks:





Update: November 14, 2013




While I was writing this, Dave Rupert was putting together a very neat experiment, Caption Everything: Using HTML5 to create a real-time closed captioning system.




It's a neat proof-of-concept to show how real-time closed captioning is a possibility with current technology, albeit imprecise and cumbersome. If nothing else, hopefully it can bring more attention to a technique that, as demonstrated above, can benefit all users in everyday situations.




It's such a nifty experiment, I am embedding it here (remember, this isn't mine, this is Dave Rupert's code):



See the Pen Closed Captioning with HTML5 by Dave Rupert (@davatron5000) on CodePen



Read More
Posted in accessibility, i18n, internationalization, localization, translation, usability, UX, video, YouTube | No comments

Tuesday, 12 November 2013

WayBack Machine Handler for Your 404 Pages

Posted on 08:15 by Unknown


Image cheerily stolen from the Internet Archive blog post.
Last week I mentioned that the Internet Archive WayBack Machine had released a feature to allow custom URLs for on-demand archiving. That wasn't the only coolr feature it announced.




Another nifty feature that the Internet Archive offers is the ability to enhance your 404 pages. You can provide a visitor to a missing page with a link to that page in the WayBack Machine: Free “404: File Not Found” Handler for Webmasters to Improve User Experience




A nice feature of this service is that if there is no page with the current URL (that the user requested) in the WayBack Machine archive, then no link will appear and your 404 page will appear unblemished.




While some businesses might not want to direct people to an archived version of a bio for a long-gone staff member, or perhaps product details that are no longer correct, there is plenty of value for governments, not-for-profits, and other organizations who, ostensibly, shouldn't be removing any information. Organizations whose sites undergo regular upheavals, whether by changing the entire site structure, changing platforms, or generally just not building redirections during normal content restructuring, can offer a better experience to users.




The code is pretty simple (though I recommend against the self-closing div in the Internet Archive example, as some WYSIWYG editors will create the closing tag and wrap it around the script block):




<div id="wb404"></div>
<script src="https://archive.org/web/wb404.js"></script>



Granted, it relies on client-side script, and there is a chance some browser configurations will block it, but the benefit may outweigh those concerns.





To test it, I hopped into our web content management system at Algonquin Studios (QuantumCMS) and dropped that code block into the content area of the generic 404 page. Then I scoured the site for a page that we hadn't updated or redirected during one of our site overhauls and that also existed in the WayBack Machine.




Until I can get around to redirecting that missing page, you can see the effects of the 404 handler from the Internet Archive. If you are reading this after I made that redirection, here's a screen shot of how the link appears on the page:





Screen shot of the 404 page with the WayBack Machine link (the Redeemer animated GIF has nothing to do with the WayBack Machine).




That's it. Simple, straightforward, and potentially very useful to your visitors.



Update: November 13, 2013




Thanks to the story Conservatives erase Internet history, we know that the Internet Archive's WayBack Machine can be pretty easily cleared of historic pages just by updating a site's robots.txt file. While I would expect that the effect should only kick in from the date of the edit of the robots.txt file forward, that doesn't appear to be how it works.




I guess this casual tweet from my one of my partners at Algonquin Studios was more prescient than I thought, though in the opposite direction:



@aardrian unless Wayback captures that legally indefensible policy that made you take down the page. Or a hacked version of the site.

— stevenraines (@stevenraines) November 13, 2013


Read More
Posted in usability, UX | No comments

Friday, 8 November 2013

Tables as Responsive Image Containers

Posted on 13:09 by Unknown



If you've been following the latest chaos in the responsive image debate, you may know that there is a battle afoot between supporters of src-n, srcset and picture. If you don't believe me, I refer you to this WHATWG post, a polite round-up of today's bar fight. Key is that it links to multiple discussions in its round up:




[1] http://tabatkins.github.io/specs/respimg/Overview.html

[2] https://groups.google.com/a/chromium.org/d/msg/blink-dev/tV3T1wHuXqE/SvWKxIyG6IIJ

[3] https://lists.webkit.org/pipermail/webkit-dev/2013-October/025763.html

[4] https://lists.webkit.org/pipermail/webkit-dev/2013-November/025809.html

[5] https://bugzilla.mozilla.org/show_bug.cgi?id=870021



Granted, picture has been mostly abandoned by the Responsive Images Community Group (RICG), but after today's fight it looks like it might have legs again.




All of these, however, neglect a responsive image solution that we've had since 2005: tables.




Consider the RICG logo:




RICG logo.



And consider this version encoded as a table, with none of those troublesome pixels:


















































































......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................
......................................................................................................................................

Look, I even added transparency!







If you look through the Use Cases and Requirements for Standardizing Responsive Images, you'll see this approach satisfies none of the requirements and is made of incredibly complex code. This, in effect, guarantees employment for responsive web developers for years to come. You can make your own tabled images, though you'll want to tweak the code a bit.




I tried to make this clear earlier today:



Guys! Stop fighting about resp image syntax (https://t.co/kE6T7Nv5ne)! I found a solution! http://t.co/yBkji15Yyk Backward compatible!

— Adrian Roselli (@aardrian) November 8, 2013




I can only hope this example sets us all on the right path.



Update: November 14, 2013




If you came here actually looking for something useful about the status of responsive images in general, check out Mat Marquis' responsive images standings cheat-sheet, which he plans to update regularly.

Read More
Posted in browser, css, design, rant, W3C, whatwg | No comments
Newer Posts Older Posts Home
Subscribe to: Posts (Atom)

Popular Posts

  • Browser Performance Chart
    Jacob Gube has posted a handy chart over at Six Revisions titled " Performance Comparison of Major Web Browsers ." He tests the c...
  • Google Dashboard: What Google Knows about You
    Google announced a new service/feature today, Google Dashboard . Given all the services Google offers and all the ways you can interact with...
  • Facebook, HTML5, and Mis-Reporting
    My Twitter stream and the headlines of sites across the web yesterday lit up with Facebook's CEO blaming its stock price (failure to mee...
  • App Store Meta Tags
    Why yes, Dominos, I'd love to tap again to get your real home page to order a pizza when I could have done it right here, below your ove...
  • Speaking at Mom 2.0 in Houston, TX
    I will be in Houston this week to speak at the Mom 2.0 Summit (Feb. 18-20, 2010, Houston, TX). To make it a little easier to describe, here...
  • Codepen Has Handy Sharing Tools for Devs
    There are plenty of online resources for playing around with code right in the browser, no server of your own needed, that you can then shar...
  • History of Eye-Tracking as Research Tool
    If you've ever wondered what eye-tracking is and where it came from, there is a historical breakdown in the article A Brief History of E...
  • Opera: Presto! It's now WebKit
    Opera is replacing its Presto rendering engine with WebKit (Chromium, really, when you factor in the V8 JavaScript rendering engine). Big n...
  • The Science of Trust in Social Media
    I am one of those people who always needs to see proof of some assertion, evidence to back up a claim. While I can accept anecdotal evidence...
  • Developer Discusses Dyslexia and Dyscalculia
    Sabrina Dent , a web designer hailing from Ireland, has blogged about her struggle with dyslexia and dyscalculia and web applications today...

Categories

  • accessibility
  • Adobe
  • analytics
  • Apple
  • apps
  • ARIA
  • Bing
  • Blink
  • Brightkite
  • browser
  • Buzz
  • Chrome
  • clients
  • css
  • design
  • Facebook
  • Firefox
  • Flash
  • fonts
  • food
  • Foursquare
  • g11n
  • geolocation
  • globalization
  • Google
  • Gowalla
  • html
  • i18n
  • ICANN
  • infographic
  • Instagram
  • internationalization
  • internet
  • Internet Explorer
  • JavaScript
  • JAWS
  • Klout
  • L10n
  • law
  • localization
  • Lynx
  • Mapquest
  • Microsoft
  • mobile
  • Netscape
  • ning
  • Opera
  • patents
  • picplz
  • Plus
  • print
  • privacy
  • project management
  • QR
  • rant
  • RSS
  • Safari
  • SCVNGR
  • search
  • SEM
  • SEO
  • social media
  • Sony
  • speaking
  • standards
  • SVG
  • touch
  • translation
  • Twitter
  • typefaces
  • usability
  • UX
  • Verizon
  • video
  • W3C
  • WAI
  • WCAG
  • WebKit
  • whatwg
  • Wired
  • WOFF
  • xhtml
  • Yahoo
  • YouTube

Blog Archive

  • ▼  2013 (39)
    • ▼  December (1)
      • Web Development Advent Calendars for 2013
    • ►  November (7)
      • Thanksgiving, Technology, and Just Picking a Fight
      • Image alt Exception Change Re-Re-Re-Requested
      • Print Styles Are Media Queries
      • Captions in Everyday Use
      • WayBack Machine Handler for Your 404 Pages
      • Tables as Responsive Image Containers
    • ►  September (4)
    • ►  July (3)
    • ►  June (2)
    • ►  May (5)
    • ►  April (3)
    • ►  March (6)
    • ►  February (2)
    • ►  January (6)
  • ►  2012 (63)
    • ►  December (2)
    • ►  November (4)
    • ►  October (5)
    • ►  September (5)
    • ►  August (4)
    • ►  July (6)
    • ►  June (7)
    • ►  May (7)
    • ►  April (8)
    • ►  March (5)
    • ►  February (3)
    • ►  January (7)
  • ►  2011 (67)
    • ►  December (5)
    • ►  November (7)
    • ►  October (5)
    • ►  September (4)
    • ►  August (8)
    • ►  July (3)
    • ►  June (8)
    • ►  May (3)
    • ►  April (1)
    • ►  March (6)
    • ►  February (6)
    • ►  January (11)
  • ►  2010 (100)
    • ►  December (8)
    • ►  November (7)
    • ►  October (5)
    • ►  September (10)
    • ►  August (7)
    • ►  July (11)
    • ►  June (12)
    • ►  May (6)
    • ►  April (8)
    • ►  March (10)
    • ►  February (5)
    • ►  January (11)
  • ►  2009 (51)
    • ►  December (9)
    • ►  November (6)
    • ►  October (21)
    • ►  September (13)
    • ►  August (2)
  • ►  2003 (3)
    • ►  October (1)
    • ►  January (2)
  • ►  2002 (9)
    • ►  December (1)
    • ►  June (3)
    • ►  April (1)
    • ►  March (3)
    • ►  January (1)
  • ►  2001 (1)
    • ►  February (1)
  • ►  2000 (4)
    • ►  October (1)
    • ►  July (1)
    • ►  June (1)
    • ►  January (1)
  • ►  1999 (7)
    • ►  November (1)
    • ►  September (2)
    • ►  August (2)
    • ►  July (1)
    • ►  June (1)
Powered by Blogger.

About Me

Unknown
View my complete profile