• Full-finger-typing on a regular-size keyboard
• Writing with a pen/pencil on paper
• Thumb-typing on a small QWERTY keyboard
• Stylus recognition on a touchscreen
• Voice notes
• Scoring the flesh of my forearm in Morse Code with a rusty Bowie knife
• Typing with one thumb on my phone’s number keypad

Which one do you use? Guess which one I use…

And finally, some flamebait questions:

• Why in God’s name are there duplicate enter and Apple keys?!?
• Does anyone REALLY think the MacBook right-click equivalent is simpler than putting two #@!$ buttons on the pad?!? That button is huge-ass!

First, a quick description of what Subversion is: Subversion is a revision control software that allows multiple people to check out and make changes to documents from a central repository. For convenient use, it requires the centralized server to be always running and for users to have network access.

The problems I face deal mostly with the centralized aspect, really. First, I’m running a Linux server at home that is not always available (sometimes I boot it into Windows to get some video conversion/media editing done). Second, I am collaborating on several projects at once which means I have to access several repositories, some of which are not under my control – everything in Subversion hinges on the a single server that contains the repository.

So actually Subversion comes close to my requirements, but fails on the decentralized thing. Git is sounding better. I may have to give it a shot one day as their tools mature.

Does anybody have any experience with organizing things like code, documents and photos with a version control system? Any recommended software?

Driving home from work Friday, I was flipping around the stations and somehow ended up listening to the following paraphrased exchange between a DJ and a caller for 103.5 Kiss FM:

Caller: “I can’t figure out how to get to the $500 contest.”

The DJ: “Uh oh, maybe our website’s broken, let me check… No, it’s right in the center of the page.”

Caller: “But I can’t click it”

The DJ: “What browser are you using? Are you using Firefox or some crappy browser like that?”

Caller: “Yeah”

The DJ: “You have to use Internet Explorer. The website sometimes doesn’t work on Firefox. Go back to your old ways.”

Here’s the relevant code:

Can anybody figure out why Firefox doesn’t allow clicks?

If you haven’t read about XPointer before, you can start at my recent blog post here.

At the moment, things are pretty much in a raw, not-at-all-ready-for-prime-time state, though I’ve traveled down some lanes that I’ve always wanted to try out (specifically I’ve got my first real taste of XUL and XBL). Unfortunately it took me a while to get even a little clue on some of this stuff and it can be a bit discouraging. Here’s hoping the Mozilla documentation improves both in coverage and recency – but I’m not holding my breath.

The goal is: I want to modify the view of an HTML document if any XPointer parts show up in the URL bar.

I started with simply adding a “load” event handler to the gBrowser. This worked fine any time a page had to load (including in a new tab or in the existing tab). However, what I noticed was that a “load” event would not fire if the link was in the same page (i.e. just the “hash” part of the URL had changed) if you clicked a link or when you typed it in. So if I’m at page foo.html and that page has a link to foo.html#element(bar), when I click that link I do not get a “load” event.

So that led me into learning a bit more about XBL to try and add some bindings to the chrome.

Where I sit now: I’ve got XBL defining an evalXPointer() method on the “urlbar” XUL widget. When a new document is loaded, I invoke this method. Also, when a new URL is entered into the location bar (and the user presses Enter), I invoke this method. Finally, if the “Go” button is clicked I also invoke this method. All my “logic” sits in JavaScript in the XBL at the moment.

Anyway, I kind of get the idea that what I’m doing is not appropriate. That’s what community feedback is all about. The above bindings seem kind of like a hack. What I really want to do is get notified when any link has been activated (by click or otherwise) and regardless of whether this link causes a “load” event or if it’s in the same page. Does anybody know the sane way to do this?

Better yet, is there a way to detect when a browser tab’s address has changed in a definitive way? I don’t want to look at every keypress.

Start with Doug’s excellent post on this topic. I don’t have any opinion on the aria-specific elements of the debate. I’m fine with either adding a namespace to these attributes when used in XML or letting those attributes attach themselves to the SVG language without a namespace if it simplifies things, I don’t see a need to update the SVG specification for this though. I also don’t see a need to reinvent or create a new namespacing mechanism using underscores or dashes, this seems silly and/or dangerous to me.

But there’s something I’m not getting about the recent discussion of allowing inline SVG in text/html (or HTML5). Anne seems to be of the opinion that it would be a good opportunity to simplify the SVG language – maybe eliminate namespaces, allow upper-case SVG elements. Kind of an “if you want to play in the HTML playground, you have to wear the right kind of sneakers” attitude. This is kind of like HTML abusing its monopoly, isn’t it?

I don’t think this is a good idea. If you allow <CIRCLE CX=40> to be the same thing as <circle cx=”40″/> eventually we’ll start to see people producing non-compliant SVG in the wild. Then we’ll have people creating inline SVG for HTML that won’t work in the many SVG tools and viewers that are already out there and we’ll just have frustrated authors. Then some tools might feel forced to accommodate the lax HTML-style of SVG, just like the mess we have now with browsers trying to understand as much content as they can in order to compete. Then we’ll have to rewrite the SVG spec so that SVG has two serializations (like we’re having to do with HTML5/XHTML5). It just seems to be going at it backwards, since SVG was designed from the ground up as an XML technology. Must we rewrite all XML specifications into HTML5-style languages in order to get inlining? I don’t think so.

I guess I don’t fully understand why the HTML5 parser can’t just have the ability to hand off the character stream to another parser when it encounters some “special” elements like <svg> or <math>. Why does everything have to be in the hands of the HTML5 parser? In other words, in the document:

Upon encountering the characters “<svg “, the parser should back up five characters and send the bytes to the browser’s parser that handles content with the MIME type image/svg+xml. When that parser is complete, those elements can be injected into the DOM in the proper namespace and the HTML5 parser can pick up after </svg>

I see some problems, none of which seem insurmountable to me:

1. If the browser has no SVG parser, then what should happen? My proposal here is that all HTML5 browsers must also include a bog-standard XML parser to handle inline content that is known to be XML. This should be pretty straightforward, since XML parsing is actually much simpler than HTML5 parsing. In the case of a browser not grokking SVG, it throws the character stream to the bog-standard XML parser and waits for the character stream to return to it. Whether those elements are injected into the DOM is up to that browser (a browser could inject the foreign elements into the DOM even if it doesn’t know how to render them).
2. I hear that some browser don’t properly handle namespaced content or colons or something. Can someone clarify which browsers? Can someone further clarify what exactly the problems are? Can someone confirm if that browser will have fixed itself, say, next year would we be good to go?
3. Maybe the biggest problem with this idea is defining what happens in error scenarios – i.e. when the SVG is malformed, then at what point does the SVG parser return the character stream back to the HTML parser. In other words, maybe the challenge here would be in defining how parsers need to behave towards each other when mixing MIME types. Anybody have a suggestion here? Is this the deal-breaker?

As for namespace removal – why? Seriously just because it’s hard to remember it? If we’re trying to get to a “cut-and-paste” environment for some web authors, then they can just cut and paste the whole thing (namespace definitions in <svg> element and all). Maybe it’s because I’m used to writing SVG, but I really don’t have a problem with the concept of mixed namespace content. Sam’s off-the-cuff solution seems to favor even skipping the <svg> element, which would seem to me to cause a mess of problems. Where would you define the viewBox? Where would you define the version of the SVG language? You couldn’t, for example, cut and paste his “inlined” SVG content into a standalone SVG document for editing and be guaranteed it will even display properly, even if you wrapped it in a simple <svg/> element.

It seems like the belief that XHTML being a failure is a reflection on XML-on-the-web in general. In fact, all browsers except for IE can handle application/xhtml+xml MIME type these days, so it really seems to me that the verdict’s still out on whether XHTML is a good technology or not. Some people out there still think that XML has a place on the web. People like Shelley, who also shares her thoughts on SVG in text/html here.

I think we should explore relaxing the draconian error handling on XML on the web, but I don’t agree with re-inventing changing XML languages into HTML-style languages one after another.

What I’m looking for is something like SVG Fragment Identifiers where you can use XPointer syntax in the URL to navigate to a specific section of a document. Before I spend time learning XPointer syntax, can anyone tell me if any HTML browsers support it as fragments in the URLs?

Another option is to link to a cached page from a specific Google Search, but it still requires the user to scroll down to the highlighted section. It’s a shame that Google doesn’t insert specific anchors into the web page for this very purpose. It might make some web authors angry that Google mucks about with their source, but this is a case where I don’t mind – authors should learn to properly identify portions of their documents. This becomes increasingly important for mobile devices with those smaller screens.

On the other hand, is there any way to add a System Environment Variable to Windows from the command prompt?