mathias

Even easier — here’s a userscript that removes the SOPA overlay on English Wikipedia: https://gist.github.com/1631807

Works in all browsers on OS X Lion.

𝐖𝐨𝐚𝐡, 𝐇𝐚𝐜𝐤𝐞𝐫 𝐍𝐞𝐰𝐬 𝐚𝐥𝐥𝐨𝐰𝐬 𝐭𝐡𝐞𝐬𝐞 𝐜𝐡𝐚𝐫𝐚𝐜𝐭𝐞𝐫𝐬 𝐢𝐧 𝐜𝐨𝐦𝐦𝐞𝐧𝐭 𝐭𝐞𝐱𝐭!

(𝐺𝑖𝑡𝐻𝑢𝑏, 𝑓𝑜𝑟 𝑒𝑥𝑎𝑚𝑝𝑙𝑒, 𝑑𝑜𝑒𝑠𝑛’𝑡.)

Hipster.

    The "data:" URL scheme is only useful for short values. Note that
    some applications that use URLs may impose a length limit; for
    example, URLs embedded within <A> anchors in HTML have a length limit
    determined by the SGML declaration for HTML [RFC1866]. The LITLEN
    (1024) limits the number of characters which can appear in a single
    attribute value literal, the ATTSPLEN (2100) limits the sum of all
    lengths of all attribute value specifications which appear in a tag,
    and the TAGLEN (2100) limits the overall length of a tag.

These are references to (theoretical) limitations in HTML/SGML. They are not limitations of the data URL scheme.

Also note that bytex64’s page doesn’t use a link; it just shows the data URL so you can copy and paste it. Either way, none of the above limitations apply here.

</nitpick>

> "CHIP. CHIP, WAKE UP. YOU KNOW WHAT WOULD BE TOTALLY BITCHIN'? A VERSION OF SNAKE THAT COULD FIT IN A URI!"

Sorry to Melvin all over this comment, but technically, anything can fit in a data: URL. On its own, it’s not much of an accomplishment.

OTOH, a fully functional snake game that fits in ~1KB is pretty impressive. Kudos to you, sir!

The spec doesn’t make &amp valid though, it just makes it work the way browsers have always treated it. I don’t see the harm in that. “Support existing content” is one of the HTML design principles.

If you want to write valid markup, that’s great. Heck, we should all do it! But there’s a lot of invalid existing content out there that isn’t going to fix itself anytime soon.

By the way, this project got bundled with Node.js v0.6.2+ (replacing their older, not fully compliant Punycode library). \o/

So, do one of these companies work at night, or what?

7am to 3pm = 8 hours 4pm to 12am = 8 hours

> As for the performance, I'm pretty sure you're just guessing, and haven't done any testing.

Have you?

Are you saying it’s not necessarily slower to use JS to generate CSS on the client-side, compared to just serving up the CSS with all prefixes included in the first place? Do we really need a test case for that? I’m not even talking about your code or anything; just the general idea.

In general, it’s a bad idea to rely on client-side JavaScript for something that can be done without. PrefixFree is no exception.

I can see how PrefixFree can be useful for quick demos or during presentations (the way you use it is awesome!) but when you’re gonna post an article like this on a site like Smashing Magazine _people are gonna use it_ in production as well.

I love your work Lea, you know I do; I just don’t agree with the philosophy behind this particular project.

When did we stop caring about FOUC and client-side performance?

> 410s

FTFY.

Nowadays this is the default again, no?

And there we go:

    defaults write NSGlobalDomain NSQuitAlwaysKeepsWindows -bool false

Commit: https://github.com/mathiasbynens/dotfiles/commit/7346f4c4592...

Thanks! Committed: https://github.com/mathiasbynens/dotfiles/commit/7346f4c4592...

Yes, that works.

If — like me — you hate the Resume feature so much, you can disable it system-wide in System Preferences. I’m still looking for a command that does this :)

Ah, forgot about that one. Thanks! Added: https://github.com/mathiasbynens/dotfiles/commit/18044c4c882...

I’d love to get a command-line version though :)

It’s about these icons: http://i.imgur.com/RGRQy.png

I should probably point out that `.osx` is not a standard or anything. I just found myself collecting all these gems – not all of them are hidden settings, but most are – and decided to organize them into a single file :)

It’s pretty useful though; when I set up a new machine, I just clone my repo, run the bootstrapper, then `./.osx` and BOOM!

Why are you comparing this to `jQuery(document).ready()`? Apples and oranges.

You say it’s faster, but fail to provide any numbers / a jsPerf test case. I’m sure it’s faster to execute `waituntilexists()` initially, but if you take into account it uses an 5ms interval in which it traverses the DOM for the same elements over and over again until they’re finally found, it seems it probably has a negative impact on performance overall.

What’s wrong with event delegation anyway?

Hacker News wouldn’t accept the ftp:// URL, so I had to run it through my URL shortener. Sorry for the confusion!

This post is based on ES3. Both U+2028 and U+2029 are valid in ES5 string literals as part of a LineContinuation. See http://es5.github.com/#x7.3 (ES5) instead of http://bclary.com/2004/11/07/#a-7.3 (ES3).

So really, the title should be: “JSON: The ES3 subset that isn’t.”

Issue reported: https://github.com/judofyr/timeless/issues/57

A very fragile fence, in this case.

I made a user script for this a while ago: https://gist.github.com/880967 Just click one of the “raw” links to install.

That won’t work in all browsers. User scripts are executed in their own context and don’t know of plugins and libraries that are available on the page.

The good news is, you don’t need Prototype at all. I made this userscript this morning: https://gist.github.com/880967 Just click one of the “raw” links to install.

I made a user script for this a while ago: https://gist.github.com/880967 Just click one of the “raw” links to install.

As the guy who wrote the article, I agree with your point on the magic URL — in an ideal world it wouldn’t be like this. However, it is now too late. /favicon.ico has been the de facto standard for a long time and the HTML spec explicitly mentioning doesn’t really make much of a difference — it is really just standardizing what is already generally supported.

It’s time we stop complaining and start embracing this part of the URL layout as if it was robots.txt we’re talking about.

IE doesn’t support any other format than ICO for favicons. Redirects, spoofed MIME types or fake file extensions won’t change that.

The article mentions SeaMonkey, currently the only browser that doesn’t fetch /favicon.ico by default.

But yeah — some web apps rely on /favicon.ico as well. All the more reason to just place it there :)