4 ms·

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 c

by sid0 16y ago

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.

mquander 16y ago
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.

by sid0 16y ago

mquander 16y ago

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.