Untested, of course

a blog by Theresa O'Connor

Updating Our Prefixing Policy

WebKit’s new feature policy is to implement experimental features unprefixed, behind a runtime flag.

When implementing new features for the Web, it’s important for us to be able to get them into the hands of developers early, so they can give new things a try. (Of course, this also helps us identify and fix bugs!) In the past, browsers did this by using vendor-prefixed names for features. This was intended to protect the Web from the churn of spec and implementation changes. Browsers would eventually implement the standard version with no prefix and drop support for the prefixed version.

Over time this strategy has turned out not to work so well. Many websites came to depend on prefixed properties. They often used every prefixed variant of a feature, which makes CSS less maintainable and JavaScript programs trickier to write. Sites frequently used just the prefixed version of a feature, which made it hard for browsers to drop support for the prefixed variant when adding support for the unprefixed, standard version. Ultimately, browsers felt pressured by compatibility concerns to implement each other’s prefixes.

The current consensus among browser implementors is that, on the whole, prefixed properties have hurt more than they’ve helped. So, WebKit’s new policy is to implement experimental features unprefixed, behind a runtime flag. Runtime flags allow us to continue to get experimental features into developers’ hands while avoiding the various problems vendor prefixes had. Runtime flags also make it easier for us to have different default settings between stable builds and preview builds such as Safari Technology Preview.

We’ll be applying our updated policy to new feature work going forward. Whether or not a runtime flag should be on or off on WebKit trunk (and thus in nightly builds) depends on the maturity of the feature, both in terms of its spec stability and implementation maturity.

What does this mean for Web developers?

Initially, developers shouldn’t notice anything different. In the longer term we hope this change will make it easier for you to try out upcoming features. As always, we encourage you to give in-progress features a try. Feedback and bug reports on experimental features are very welcome.

What about currently prefixed features?

We’ll be evaluating existing features on a case-by-case basis. We expect to significantly reduce the number of prefixed properties supported over time but Web compatibility will require us to keep around prefixed versions of some features.

We invite comments and feedback on the new policy from Web developers, educators, and our colleagues working on other browser engines. Feel free to reach out to me on Twitter (@hober), Jon Davis (@jonathandavis), @webkit, or email me directly at hober@apple.com.

posted at

Herodotus on standards work

It is also their general practice to deliberate upon affairs of weight when they are drunk; and then on the morrow, when they are sober, the decision to which they came the night before is put before them by the master of the house in which it was made; and if it is then approved of, they act on it; if not, they set it aside. Sometimes, however, they are sober at their first deliberation, but in this case they always reconsider the matter under the influence of wine.

Book 1 of the History of Herodotus

posted at

Running Gnus in a dedicated Emacs

Gnus is an awesome mail and news reader, but it can be a bit of a performance bear, especially when using IMAP. Since Emacs is single-threaded, IMAP operations that take too long can disconnect you from IRC, Jabber, or any number of other network services you also use from Emacs.

The typical solution to this problem is to run Gnus in a dedicated Emacs instance. Doing so is really easy—just make a gnus shell alias like so:

alias gnus 'emacs -f gnus'

The catch is, such an Emacs doesn't know it's a dedicated, Gnus-only Emacs. When I used this technique, it was always confusing that quitting Gnus didn't quit its Emacs.

We can use command-switch-alist to define a custom -gnus command line argument that does what we want. Here's what I have in my .emacs file:

 '("gnus" . (lambda (&rest ignore)
              ;; Start Gnus when Emacs starts
              (add-hook 'emacs-startup-hook 'gnus t)
              ;; Exit Emacs after quitting Gnus
              (add-hook 'gnus-after-exiting-gnus-hook

To use the above, we just alter our shell alias to use our new argument:

alias gnus 'emacs -gnus'

The only other thing to keep in mind is how this sort of setup interacts with emacsclient. (This is a command that lets you edit files in an already-running Emacs.) I really only want emacsclient to open files in the other Emacs I have running, and not in my Gnus-only Emacs. Let's fix this by restricting when we start the server that emacsclient talks to.

(defvar ted-server-emacs t
  "If non-null, this emacs should run emacsclient.")

Now that we have a flag we can use, let's only call server-start when the flag's been raised:

(add-hook 'emacs-startup-hook
          (lambda ()
            (when ted-server-emacs

The only bit left to do is to (setq ted-server-emacs nil) inside the custom command line argument handler above.

posted at

A simple shell lifehack

OpenSSH lets you use per-host settings in your ~/.ssh/config file, like so:

Host foo
HostName foo.example.com
ForwardX11 no

If you have the above in your ~/.ssh/config file, you can simply type ssh foo instead of ssh -x foo.example.com.

It’s pretty much always the case that I’ll fire up GNU Screen when SSHing into a remote host. Here’s some code that’s been banging around in my .cshrc for a few years. It sets up handy shell aliases for all of the machines I commonly SSH into:

set ssh_hosts=`grep '^Host [^*]' ~/.ssh/config|cut -c 6-`

foreach host ($ssh_hosts)
    alias $host "ssh -t $host screen -DR"

Now I can simply type foo and I’ll be up and running with a screen session on foo.example.com. If I want to SSH into a box without firing screen up, I simpy ssh foo directly.

Now that we have this handy ssh_hosts variable, we might as well use it for other things too, like for adding intelligent tab completion:

complete ssh 'p/1/$ssh_hosts/'

Now I can just type ssh f TAB RET and I’m good to go.

posted at

Ignite San Diego

The second Ignite San Diego was this past Tuesday night, and it was awesome.

Like last time, The Hive was our gracious host, though this time we were in the parking lot next to their new location in the East Village. It’s August, and we’re in San Diego, so why ever be inside? People brought beach chairs, blankets, or whatever else they had to sit on.

MIHO Gastrotruck served up their unique brand of farm-to-table street food. Everyone I talked to raved about the food afterwards. (I had the burger, and holy crap that shit is tasty.)

One of the great things about doing Ignite outside was that we got to enjoy Hive241’s wonderful new street art mural. I’m not sure if it was done as part of the Museum of Contemporary Art’s Viva la Revolución exhibit that’s going on right now, but either way, it provided a striking backdrop for our speakers.

Speaking of the talks, I have to say that, while the presentations at our first Ignite rocked, our speakers this round really took things to a new level of awesomeness. Both Jed and Brian, in different ways, pointed out ways that our community can be more politically active. Jason made everyone want to stop what we were doing and eat some waffles. We had talks on everything in between, from AI to the End of the World. Really inspiring stuff.

Many thanks to everyone who made our second Ignite what it was: our sponsors, volunteers, speakers, attendees, MIHO, and organizers.

Let’s do this again in a few months.

posted at

Home Ownership

As of yesterday, April 21st, Erin and I are officially homeowners!

posted at

Hacienda Guadalupe & Laja

Just south of San Diego lies the beautiful Guadalupe Valley. Baja's wine country, the Valle de Guadalupe is home to several wineries and other attractions including Laja, an amazing farm-to-table restaurant. Erin and I have been meaning to check Laja out for ages and ages, ever since Lindsay first told us about it. We finally had an excuse when my folks recently visited from Boston.

The four of us stayed at the lovely Hacienda Guadalupe while in the valley.

Hacienda Guadalupe

A room at Hacienda Guadalupe The pool at Hacienda Guadalupe

Hacienda Guadalupe is simply perfect. Great view of the valley, lovely rooms, and an idyllic pool make for a very relaxing stay.

After a gruelling afternoon sipping wine in the jacuzzi and reading by the pool, we headed over to Laja for dinner. I suppose I shouldn't have been surprised that we ran into Michael and Steph from The Linkery there.

Laja Erin and me, in the garden at Laja

The meal was amazing. Seriously, I had the most tender beef I've ever tasted, and everything else was awesome too.

We had such a lovely time that we're heading right back tomorrow.

posted at

Thoughts on converting HTML to Atom

For better or worse, HTML is The Format. So why not use HTML as your underlying data format, producing other formats from it as needed? I’m convinced that this is how we should be thinking about webarch long-term. Other formats come and go, while HTML remains an unbroken line.

Ironically, my blog software uses Atom for its backing store.

With Microformats, of course, this is already being done. Authors link to services like H2VX to provide people with downloadable, subscribe-able vCard and iCalendar feeds. You can use hAtom2Atom to generate an Atom feed from your blog. Software like Falcon use HTML+hAtom for backend storage.

HTML5 contains several new semantic elements, derived in part from Web authors who have used class="" to add additional semantics to their markup. <article> and <time pubdate> provide, in native HTML, similar functionality to what the hAtom microformat provides in HTML 4. (When HTML5’s new elements are more widely implemented, you can expect hAtom to be updated to encourage the use of these new elements where possible.)

Hixie’s not the sort of guy to leave things underspecified, so HTML5 defines (in excruciating detail) how to convert an HTML document to Atom, even when the HTML document in question is, shall we say, less than ideal. Because documents can vary wildly in quality, it is not always possible to extract an appropriate <atom:id> for the articles present. We prefer to handle errors, so in such cases the algorithm allows the HTML→Atom software to make one up. Because different software may make different IDs up, or even the same software invoked in different circumstances, this doesn’t quite live up to the requirements of the Atom spec. This is unfortunate, but is basically unavoidable in any such algorithm (hAtom, for instance, punts on this issue entirely—it only defines the conversion for valid input).

posted at

ARIA’s role (class 2: Electric Boogaloo)

This blog post has been sitting around in my drafts folder for a long, long time, and is about a debate long settled. While spring-cleaning my drafts, I thought that it might still shed some light for people on the weird naming difference between role="" and the other ARIA attributes, so there you go.

Suppose you’re a web author, or maybe a widget developer, and you’re reading about how to use WAI-ARIA in HTML. You might find it odd that all but one of ARIA’s attributes look like aria-foo="". The exception is role="". So what’s the deal with that?

Several years ago, the (now defunct) XHTML2 Working Group decided that XHTML2 needed a way for authors to imbue elements with custom semantics, to layer additional meaning onto elements. But HTML-family languages already had such a mechanism: class="". Web authors have been using class="" to enhance their markup with additional semantics for years and years. The practice of using semantic class names has been widespread in the web authoring community since at least 2002. The W3C itself has encouraged authors to use class="" with semantics in mind since 2004. The whole Microformats effort is built around this.

Anyway, the XHTML2 WG decided to invent their own class="" attribute, which they called role="". They then back-ported role="" into XHTML 1. This is the entirely-redundant-with-class="" XHTML Role Attribute Module.

Well, role=""’s been about as successful as XHTML2 itself, which is to say, not successful at all. But when WAI started to work on ARIA, XHTML2 and all that were still going concerns, so they tried to be forward-looking by attaching ARIA semantics to elements with the XHTML Role Module. (They also decided to do some other things that didn’t work out, like their since-reversed decision to use XML Namespaces for the other ARIA attributes.)

The concerted, successful effort to integrate ARIA into HTML5 and SVG revealed a lot of these issues, and ARIA is much improved as a result. aria:foo="" became aria-foo="", and ARIA stopped using the XHTML Role Module and CURIEs. But at that point, given already-deployed web content with ARIA in it, it was considered too costly to bring role="" into alignment, name-wise, with the rest of the ARIA attributes. So role="", though restricted to its ARIA use-case, remains this weird echo of the abandoned XHTML2 effort.