Live data from Hacker News

A Shocking Truth About CSS

blog.twoalex.com

31–40 of 70 posts

Re: A Shocking Truth About CSS

#31
post #4

Can anyone point to where this is required by the css specification? Or is this an implementation detail? The reality may be that all the browsers do it this way, but why couldn't someone add some more smarts to choose selectors based on selectivity, just as a SQL query planner would?

It’s quicker to walk up a DOM tree than it is to walk down - that’s the root reason why browsers have all implemented it this way.

Can you please explain why this is so?

Re: A Shocking Truth About CSS

#33
post #25

Earlier quoted context omitted.

> a computer capable of executing millions of instructions per second Billions, not millions.

Billions of cycles per second. But executing an instruction frequently takes 20 cycles or so. That reduces instructions to hundreds of millions.

Presumably any modern processor would use some form of pipelining, which I think would take instructions back up into the billions. (The pentium 4, if I recall correctly, had a 20+ stage pipeline)

Re: A Shocking Truth About CSS

#34
post #31

Earlier quoted context omitted.

It’s quicker to walk up a DOM tree than it is to walk down - that’s the root reason why browsers have all implemented it this way.

Can you please explain why this is so?

A DOM node can have multiple children but only one parent. To go up the tree and check for a hit you simply call (in pseudocode) node.parent.isOK?.parent.isOK? etc. To go down the tree you have to not only choose your search strategy (depth-first, breadth-first) but also check a whole lot more nodes in the hope that you’ll find what you want.

Re: A Shocking Truth About CSS

#35
post #25

Earlier quoted context omitted.

> a computer capable of executing millions of instructions per second Billions, not millions.

Billions of cycles per second. But executing an instruction frequently takes 20 cycles or so. That reduces instructions to hundreds of millions.

Except that pipelining, multiple cores, and hyperthreading then bring it back up. So, let's not get overly pedantic here.

Re: A Shocking Truth About CSS

#36
post #32
post #3

(from the header:) The Two Alexs Alexes? Alex's? Alexi? Alexim? In hackanonical form, Alexen. As in oxen, vaxen, boxen.

Damn Google http://www.google.com/search?ie=UTF-8&q=Hackanonical

Sorry about that, just made it up on the fly. Hacker(-speak) + canonical (form) portmanteau.

Re: A Shocking Truth About CSS

#37
post #25

Earlier quoted context omitted.

> a computer capable of executing millions of instructions per second Billions, not millions.

Billions of cycles per second. But executing an instruction frequently takes 20 cycles or so. That reduces instructions to hundreds of millions.

Well, it doesn't happen in real life, but an Intel i7 is capable of issuing 4 instructions per clock cycle (sometimes 5, with a little microcode cheating). A 3.2 GHz quad-core could issue 51.2 billion instructions per second.

Re: A Shocking Truth About CSS

#39
post #25

Earlier quoted context omitted.

Billions of cycles per second. But executing an instruction frequently takes 20 cycles or so. That reduces instructions to hundreds of millions.

Presumably any modern processor would use some form of pipelining, which I think would take instructions back up into the billions. (The pentium 4, if I recall correctly, had a 20+ stage pipeline)

From CSS to processor design in just 5 comments! Only on HN ;)

Re: A Shocking Truth About CSS

#40

Earlier quoted context omitted.

Yeah, OK. So just be ignorant instead.

do you read the source of the linux kernel to understand how to use bash? how about the source of a wifi driver before connecting to a network? your premise is rediculous.

I don't do those things, but that's not because it's a bad method, but because I don't care. If there was some bug in some system call, or if I needed to investigate why hardware is misbehaving, of course I'd read the Linux source. That's one of the great things about open source software; you don't have to treat it like a black box. You can just look at the internals and see how they work.

(And I have proof that I do actually do this; I had a misbehaving joystick, and the linux fork in my github contains the fix.)

Anyway, in conclusion, if you want to know what algorithm Firefox uses to process CSS selectors, just read the Firefox source code. If you don't give a damn, then don't do that instead. But if you care and you do nothing, that's just silly.

Post reply on HN