<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
	<channel>
		<title>brothercake&apos;s feed</title>
		<link>http://www.brothercake.com/</link>
		<description>Latest news from brothercake</description>
		<language>en</language>

		<!--(template)--><!--
		<item>
			<title>xxx (yyy)</title>
			<link>http://</link>
			<dc:date>2011-00-00</dc:date>
			<description><![CDATA[ <p>...</p> ]]></description>
		</item>
		-->

		<item>
			<title>Lessons from a Failed Experiment in JavaScript Accessibility [SitePoint Blogs]</title>
			<link>http://www.sitepoint.com/show-password-javascript-accessibility/</link>
			<dc:date>2015-05-18</dc:date>
			<description><![CDATA[ <p>When you tick the 'show password' box on a site you expect to be able to see your password. But what happens for users with screenreaders?</p> ]]></description>
		</item>
		<item>
			<title>Accessible Drag and Drop with Multiple Items [SitePoint Blogs]</title>
			<link>http://www.sitepoint.com/accessible-drag-drop/</link>
			<dc:date>2015-03-09</dc:date>
			<description><![CDATA[ <p>I'd like to show you how to extend the capabilities of HTML5 drag and drop &#x2014; so it can handle multiple elements, and support keyboard interaction, for sighted and screen reader users.</p> ]]></description>
		</item>
		<item>
			<title>Good Users and Bad Passwords [SitePoint Blogs]</title>
			<link>http://www.sitepoint.com/good-users-bad-password-ux/</link>
			<dc:date>2014-07-09</dc:date>
			<description><![CDATA[ <p>It's getting more common for sign-up forms to validate the format of passwords, and then give visual feedback on the password's content or strength. But is this good usability? And is it even good security?</p> ]]></description>
		</item>
		<item>
			<title>When Feature Detection Fails [SitePoint Blogs]</title>
			<link>http://www.sitepoint.com/javascript-feature-detection-fails/</link>
			<dc:date>2013-11-21</dc:date>
			<description><![CDATA[ <p>Once upon a time, browser detection was the stock-in-trade of JavaScript programmers. Now we use feature detection, because the important thing is whether the browser supports a particular feature, not what browser that is.</p><p>But feature detection isn't completely reliable either &#x2014; there are times when it fails. So let's take a look at some examples, and see what we can do to solve each case.</p> ]]></description>
		</item>
		<item>
			<title>We Can't Rely on Color [SitePoint Blogs]</title>
			<link>http://www.sitepoint.com/cant-rely-color/</link>
			<dc:date>2013-10-16</dc:date>
			<description><![CDATA[ <p>A recent article by Georgina Laidlaw on the flat UI design style got me thinking about the accessibility implications of this trend, and especially how it affects the use of color to convey information. </p><p>So I thought it would be useful to review these implications, have a look at the accessibility requirements regarding the use of color, and discuss some of the ways in which we can meet them. </p> ]]></description>
		</item>
		<item>
			<title>Dust-Me Selectors 4.1 for Firefox</title>
			<link>http://www.brothercake.com/dustmeselectors/</link>
			<dc:date>2013-10-06</dc:date>
			<description><![CDATA[ <p>Dust-Me Selectors 4.1 is now available <a href="https://addons.mozilla.org/addon/dust-me-selectors?src=external-rss">from the add-ons directory</a>. </p><p>Version 4.1 fixes the compatibility issues that arose in Firefox 22 (because several key classes were summarily removed, which broke the extension). </p><p>Version 4.0 was never released, because of problems with the add-ons review process (bugs in the automated validator that incorrectly rejected the first build, then delays and mistakes in the manual review process that held it up for several weeks, by which time it was broken). </p><p>Overall, the latest version is a major upgrade from Version 3, with many requested new features including the widely-requested cleaning function, which can create copies of stylesheets with the unused selectors removed. Automation has been overhauled, adding the ability to restrict it to specific sites, and replacing the existing mutation event with three mutation observers. The core scanning process has also been upgraded, adding support for internal stylesheets (i.e. rules defined in style elements), as well as some new selector filters, that make it possibe to test for things like dynamic states and pseudo-elements, which selector queries can't normally match. </p><p>Other notable new features include support for spidering XML indexes and RSS feeds, some built-in help files, a whole bunch of new preferences and options, and many important bug-fixes. Check out the <a href="http://www.brothercake.com/dustmeselectors/changelog/?v=4.1">changelog</a> for full details. </p> ]]></description>
		</item>

		<item>
			<title>The Dark Shadow of The DOM [SitePoint Blogs]</title>
			<link>http://www.sitepoint.com/dark-shadow-dom/</link>
			<dc:date>2013-08-28</dc:date>
			<description><![CDATA[ <p>Shadow DOM is designed to address the encapsulation problems that plague some kinds of web development.</p><p>But Shadow DOM can't be defined in static HTML, only via scripting, so while it's undoubtedly useful (and not inaccessible as I originally thought), it still doesn't solve the encapsulation problem.</p> ]]></description>
		</item>
		<item>
			<title>Best Practice for Code Examples [SitePoint Blogs]</title>
			<link>http://www.sitepoint.com/best-practice-for-code-examples/</link>
			<dc:date>2013-08-19</dc:date>
			<description><![CDATA[ <p>The majority of articles about web development include code examples, and across the web we see great variation in how they're formatted and presented.</p><p>But a lot of them are not very good &#x2014; because the code is badly formatted, hard to read, or can't be copied-and-pasted without unwanted junk. So in this article I'd like to take a hard look at code examples, to investigate the common problems they have, and try to establish some best practice for how they should be done ...</p> ]]></description>
		</item>
		<item>
			<title>When Do Elements Take the Focus? [SitePoint Blogs]</title>
			<link>http://www.sitepoint.com/when-do-elements-take-the-focus/</link>
			<dc:date>2013-07-30</dc:date>
			<description><![CDATA[ <p>Do elements take the focus when you click them with the mouse? Do they show focus indication, like a dotted-border or focus-ring?</p><p>The answer always used to be "yes" &#x2014; and in my view, it certainly should be &#x2014; however browser behavior has changed in recent years, in both subtle and significant ways ...</p> ]]></description>
		</item>
		<item>
			<title>Essential Audio and Video Events for HTML5 [SitePoint Blogs]</title>
			<link>http://www.sitepoint.com/essential-audio-and-video-events-for-html5/</link>
			<dc:date>2013-07-16</dc:date>
			<description><![CDATA[ <p>The VIDEO and AUDIO elements provide a comprehensive range of events. While some are quite straightforward, like the self-explanatory "play" event, others can be rather more tricky to understand, especially the "progress" event.</p><p>So let's examine some of the most important media events, looking at when and how they fire and what properties are relevant to them. We'll also try to navigate the quirks of their behavior in current browsers (well, you didn't think they'd all be the same, did you?) ...</p> ]]></description>
		</item>
		<item>
			<title>Improving Usability With Extra Navigation Keys [SitePoint Blogs]</title>
			<link>http://www.sitepoint.com/improving-usability-with-extra-navigation-keys/</link>
			<dc:date>2013-06-26</dc:date>
			<description><![CDATA[ <p>When handling keyboard events in JavaScript, most scripts and applications tend to stick to the basic range of keys that provide core accessibility. This is all good, but there are some other common keys you might consider as well, that can significantly improve usability by providing more control ...</p> ]]></description>
		</item>
		<item>
			<title>Is Generated Content Actually Content? [SitePoint Blogs]</title>
			<link>http://www.sitepoint.com/is-generated-content-actually-content/</link>
			<dc:date>2013-05-29</dc:date>
			<description><![CDATA[ <p>The CSS2.1 specification summarizes generated content as "[rendered] content that does not come from the document tree" &#x2014; in other words, text and images defined in CSS, rather than in markup.</p><p>But even though we refer to this as generated <em>content</em>, I think that's misleading &#x2014; because generated content is not content at all, it's presentation ...</p> ]]></description>
		</item>

		<item>
			<title>Accessible Audio Descriptions for HTML5 Video [SitePoint Blogs]</title>
			<link>http://www.sitepoint.com/accessible-audio-descriptions-for-html5-video/</link>
			<dc:date>2013-04-29</dc:date>
			<description><![CDATA[ <p>Traditionally, audio-described videos have to be made specially, with the audio encoded in a separate track of the single video file. It takes pretty specialised video-editing equipment to encode these audio tracks, and that raises the bar for most content producers beyond a practical level.</p><p>But if we had audio descriptions in a separate file, they could be added to a video without needing to create a separate version, and would be easy to make without specialised software. So can we use existing, widely-implemented features of HTML5 video and audio, to make that work? ...</p> ]]></description>
		</item>
		<item>
			<title>3 Neat Tricks with Regular Expressions [SitePoint Blogs]</title>
			<link>http://www.sitepoint.com/3-neat-tricks-with-regular-expressions/</link>
			<dc:date>2013-04-17</dc:date>
			<description><![CDATA[ <p>I'd like to show you three cunning things you can do with regular expressions, that provide neat solutions to some very sticky problems: Removing Comments, Using Replacement Callbacks, and Working With Invisible Delimiters ...</p> ]]></description>
		</item>
		<item>
			<title>Children of the DOM [SitePoint Blogs]</title>
			<link>http://www.sitepoint.com/children-of-the-dom/</link>
			<dc:date>2013-04-04</dc:date>
			<description><![CDATA[ <p>Close node relationships in the DOM have always been problematic, because most interpretations of the DOM include whitespace text-nodes, which scripts don't usually care about. </p><p>It's right that they should be included, of course, because it's not up to implementations to decide whether this or that node is important. Nevertheless, whitespace text-nodes are usually not important, they just get in the way, complicating what should be simple relationships like firstChild and nextSibling ...</p> ]]></description>
		</item>
		<item>
			<title>Evolving a New Mutation [SitePoint Blogs]</title>
			<link>http://www.sitepoint.com/evolving-a-new-mutation/</link>
			<dc:date>2013-03-25</dc:date>
			<description><![CDATA[ <p>I used to be a big fan of DOM Mutation Events. They provided a simple way for scripts to monitor changes in the DOM, irrespective of the event or action that caused them. </p><p>However, that simplicity masked an underlying problem &#x2014; mutation events were not well implemented, and they plagued browser development with performance and stability issues. They fire far too often, they're slow and hard to optimize, and they're the source of any number of potential crash bugs ...</p> ]]></description>
		</item>
		
		<item>
			<title>Quite Times at brothercake.com</title>
			<link>http://www.brothercake.com/</link>
			<dc:date>2013-03-18</dc:date>
			<description><![CDATA[ <p>It's been quiet here at brothercake.com for some time now, but change is in the air, and it won't be like this for long.</p><p>I have a brand new site in development which will be ready in the spring. I've had to pause work on that while I focus on a necessary update for <a href="http://www.brothercake.com/dustmeselectors">Dust-Me Selectors</a>. Once that's done and dusted (if you'll pardon the pun!) I'll be able to re-focus on the new site and get it ready for publication.</p><p>The new brothercake.com is a completely overhauled architecture and design, running off a custom-built CMS that I've spent much of the last year working on. I'll be publishing much more regularly, with (at least) weekly posts and articles, and as many scripts and tools as I can find the time and energy to develop.</p><p>That's all for now!</p> ]]></description>
		</item>		
		<item>
			<title>Bad Kogan!</title>
			<link>http://www.brothercake.com/site/resources/reference/badkogan/</link>
			<dc:date>2012-06-21</dc:date>
			<description><![CDATA[ <p>So kogan.com has introduced the world&apos;s first browser &quot;tax&quot;, on customers who use IE7, and apparently they&apos;ve received a lot of praise for this.  Well let me add my voice to those who think this is <strong><em>absolutely appalling</em></strong>. It&apos;s a <strong>stupid</strong> and <strong>callous</strong> idea, and I can only desperately hope it doesn&apos;t set a precedent.</p><p>So what&apos;s next &#x2014; a tax on screenreaders perhaps, for the extra time and effort involved in making sites accessible to them? Perhaps a tax on people who don&apos;t have Flash installed, because it&apos;s such a pain in the arse to sniff for that and design fallback behavior!</p><p>The real problem here is <em>not</em> the effort it takes to support IE7. The real problem here is <strong>false expectations</strong>.</p> ]]></description>
		</item>
		<item>
			<title>Dust-Me Selectors 3.01 for Firefox (Final!)</title>
			<link>http://www.brothercake.com/dustmeselectors/</link>
			<dc:date>2012-04-26</dc:date>
			<description><![CDATA[ <p>Dust-Me Selectors 3.01 for Firefox is finally released,  and available now from the add-ons directory.</p><p>It&apos;s been a sketchy year for Dust-Me, as the company who used to support its development no longer does so, and for a while it wasn&apos;t clear whether I&apos;d have the time and resources to maintain it. But snatching development days wherever I could find them, Version 3 was eventually finished, and I realised that I owed it to the community to keep the project alive -- especially since there really isn&apos;t anything else quite like it.</p><p>To all of you who&apos;ve encouraged the continual development of this extension,and particularly to Will Morrison -- a big thank you! Version 4 is already in development, and new features will include:support for Sitemap XML files, expanded data export and import options, some new preferences, and proper documentation.</p><p>I&apos;m also investigating the possibility of being able to scan for different kind of data, or grouping and analysing rules in different ways. For example, identifying class names and attributes that are used by CSS and those which are not. Perhaps the extension could identify rules which are not used by any media, or media which are not addressed by any rules. Or identify how images are used, whether by CSS, or markup, or not at all.</p><p>Quite a few possibilities suggest themselves, so I&apos;ll be guided by feedback on which of them would be useful. And of course, if you have any other suggestions or ideas for new features or improvements, please do let me know</p> ]]></description>
		</item>
		<item>
			<title>Dust-Me Selectors Version 3.01</title>
			<link>http://www.brothercake.com/dustmeselectors/</link>
			<dc:date>2012-04-07</dc:date>
			<description><![CDATA[ <p>I&apos;ve just submitted a 3.01 update to the Firefox Add-ons Directory, that implements the various tweaks required to pass validation. An automatic update will be available as soon as it&apos;s passed -- which typically takes about a week -- or you can grab the new version from here straight away.</p> ]]></description>
		</item>

	</channel>
</rss>
