Hacker News new | past | comments | ask | show | jobs | submit login
The Joy of about:blank (hsivonen.iki.fi)
86 points by thankuz on March 21, 2011 | hide | past | favorite | 17 comments



I haven't been keeping up with all the latest HTML developments, but watching the font change in front of my eyes as the page loaded made me wonder if I was having a stroke for awhile.

Also, what's with the huge copyright on the bottom?


the font thing - http://paulirish.com/2009/fighting-the-font-face-fout/ is a good article on the subject - is it really that stroke-causing, honestly? to have a font change a bit after the page loads? in the article linked, paul irish seems to endorse the webkit view that the text should remain invisible until after the font loads, and then display - anyhoo, tl;dr: yes, it has to do with using @font-face and firefox and opera displaying unstyled text before the font file is loaded.


The font resource is obviously taking a while to load.

I opened the page in Chrome and page with just the fixed width fonts until the font finally loaded 30 seconds later. I was wondering if it was some kind meta-joke about blank pages. All I saw was the text "about:blank" placed randomly around the page.

I would have much preferred Firefox's behaviour.


Me too, it was seriously weird. I scrolled around the page for quite a while trying to figure out the joke before the text finally appeared.


> some kind meta-joke about blank pages.

  <html>
  <head><title>about:blank</title></head>
  <body>This page is intentionally left blank.</body>
  </html>
:)


It really did take quite a while. I selected the text and pasted it into TextEdit to start reading it.


The problem was that it changed a little at a time. First, the about:blank instances. Then, the headline. Then, random sections of the paragraph.

It didn't kill my family or send me into a migraine hell or anything, it was just distracting - I'm trying to read here. (I wonder how well it would work on a very slow connection.)


It has to do with the fact that the font is loaded from a remote server.


And it changed to a font that was much more difficult to read, too.


Back in the day, when table-based layouts needed content with certain dimensions to ensure widths and heights in all browsers, I used to rely on an image with src set to about:blank, instead of the silly 1x1 transparent pixel spacer.gif technique.

Later on, when I stumbled upon a CSS problem in IE6 where elements wouldn't show up unless they had a background, about:blank was back to save the day.

It's really like /usr/bin/yes or /dev/null of the web in a way. I really wanted to read more 'folklore' about it's meaning, rather than an article about the perils of it's implementation. Now I'll have to start another Googling odyssey [CMD+T -> about:blank].

Hope they manage to nail it. We're pretty used to slight delays (hiding elements until they're ready), so an asynchronous callback seems like the way to go, if it solves things for the FF developers.

Trippy page load btw, looked like some HTML art example from the nineties at first..


That page might be the hardest webpage to load.


Complicated or not, about:blank has, and always will be, my default home page.


[deleted]


Why is this here?

To show the hidden complexity behind such a seemingly simple operation, I presume. To also show what sort of effects leaky abstractions can cause. I found the cache-dependent cases particularly interesting in that regard.

This article is trash.

The article is fine. It's a little Firefox-focused, but any Web developer should be able to follow it. Web developers deal with iframes, window.open and onload events all the time.

The author is either a Markov chain or indecipherable to anyone other than his co-developer in his little corner of the Firefox code.

The author is most assuredly not a Markov chain, and I'm not a co-developer in his little corner of the Firefox code, yet I understood around 90% of the article.

How did this get 14 points?

Presumably because at least 14 people found it interesting and worth their time.


I suppose I must have a blind spot in my web programming knowledge. I see sentences like this:

The problem that prevented us from using the HTML5 parser for about:blank is that a bunch of test cases assume that when about:blank is parsed from a stream, the whole operation happens as a single event loop task.

Why do you need an HTML parser to render nothing? Gecko's test cases? Then why don't they fix the test cases?

This is OK for parsing streams from the network...However, it was a major problem with data: URLs in test cases and it still is a problem with about:blank in test cases.

Why?

[lots of stuff]

Why does this matter? about:blank is blank, right? "initially create the DOM of about:blank there synchronously?" What DOM? Is there some meaningful takeaway from this article besides "the Firefox codebase is twisted up" and the ancillary "different browsers handle iframes and new windows with different threading models?"

EDIT: Oh, OK. rwmj's comment above helped explain. I deleted my parent comment, which may have been unfair, then.


Where do all these subtleties ever get used?


I am completely, completely lost. I thought "about:blank" was just a completely empty page with nothing to render?


I didn't know this before now, but apparently you can attach an onload (javascript) handler, and then populate the blank page from that.

(Example: http://stackoverflow.com/questions/205087/jquery-ready-in-a-...)

I believe the question here is whether this event handler runs synchronously with the new window or iframe opening (causing the opener page rendering to hang); or fires off a bit later (asynchronously); or apparently in some browsers whether the event happens at all.

I'm sure someone who knows what they're talking about will correct me where I'm wrong ...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: