HTML is object code | Hacker News Reader

HTML is object code

rondam.blogspot.com

48 pointslisper67 comments

Ah yes. The old "x is hard. Writing x sometimes gets messy. I don't want to deal with all the intricacies and details of x. I know, I'll create an abstraction layer!"

Of course, in the best of all possible worlds, you'll end up with a perfect abstraction layer which is powerful enough to allow you to do everything you need, while hiding all of the the gory details. In the worst case, you end up with a leaky abstraction. Suddenly you need to know not only the underlying language, but also how the compiler works.

That's not to say that all abstraction layers are evil. C vs. machine code is an example of an abstraction that works well. You rarely need to dive down into the machine code and you can, to a large extent, be ignorant of how the compiler works and still be able to be a decent C programmer.

There's no doubt that developing for the web can be quite hairy and sometimes you wish you didn't have to deal with all of the compatibility issues etc. It's possible that the solution is something like Vaadin, which lets you develop web applications as if they were Java desktop applications. But I'm not convinced just yet.

I guess the real question is, what exactly is the problem with HTML? If the problem is that HTML isn't abstract enough, then yes, an abstraction layer would be the answer. But if the problem is something else then slapping an extra layer of complexity on top of HTML won't magically solve those problems.

I guess the real question is, what exactly is the problem with HTML?

HTML is ok, it's CSS that's got the problem. It's the difference between Microsoft Word and Publisher; CSS doesn't provide enough layout primitives to do common web layouts easily. Instead, you have to specifically structure your HTML for it and layer on the <div> tags and copious amounts of CSS code.

The problem is that, unlike Word vs. Publisher, we don't have a set medium that we're working toward (e.g. paper.) When CSS was created, it controlled and formatted all the things that browsers could present, which wasn't very darn much. Then we thought of more things for browsers to do, and had to make our CSS much more complicated to get the same effects.

To give an even older parallel, when HTML was created, it had formatting primitives that were just fine for the browsers that existed at the time. Then, as people wanted more from browsers, spacer gifs and other such aberrations were invented to allow us to achieve our complex ideals, until we invented CSS and things were simple again, for a time.

The point is, the web is an ever-changing medium. We create a language for easily expressing existing web designs, and then set our sights higher and bludgeon that design language into expressing new (and previously unachievable) designs—such as, say, multi-column text layout—until we create a new web design language and the process starts over. This isn't a problem with CSS; no matter what we create, it will never be enough. There's only so much you can do with ink on the boundaries of a page of paper; there'll never be a limit to new ways to lay out shapes and vectors in an infinitely scrollable, resizable, dynamic, animated and reactive space that can be variously interpreted by different clients.

That's not to say CSS isn't showing its age. It's just that this isn't shouldn't be considered a failing in the original design of CSS; rather, it should be seen as a sign of experience for web designers, that they now have newer, larger ideas that their smaller, brittler tools aren't up to expressing. Perhaps this is the best argument of all for separating content from presentation—if they're separate, we can replace CSS with something more robust (and then replace that with something even robust-er-er) without touching the content itself.

I agree! But the main failing of the original design of CSS (which could resolve most of these arguments) is that they didn't include a way to do page layout in the way that tables work. Many years later, with CSS3, they've finally adding it. But it seems like an obvious layout deficiency given the previous use of tables for layout.

Page layout equivalent to tables was already included in CSS2 which was finalized more than a decade ago. It is just that browsers - specifically IE - were slow to support it.

CSS3 has some proposals for grid based layouts that is much more powerful that CSS2/tables.

It's a lovely story, but it isn't true.

Designers have been trying to create grid-based layouts since the beginning of the graphical web. CSS was created after that, and its creators did not see fit to bestow on us the basic tools (flexible boxes) that could be used to create these layouts elegantly.

As a result HTML and CSS have always been coupled. Only by using both together, can engineers create the layouts designers want.

This most certainly is a failing of CSS. Sadly, it is also a failing of the web development community, who looked for progress from the one group of people who were completely incapable of delivering it.

CSS does support flexible grids (with power equivalent to HTML tables), it is just that IE has not supported it until IE8, which means it hasn't been used widely.

I fint it strange that people keep blaming the shortcomings of IE6+7 on the CSS standard.

Reference? Are you referring to http://www.w3.org/TR/css3-grid/? Which is at the working draft status?

CSS2 (which has been a recommendation for a decade) supports display:table, which is equivalent to the layout model of HTML-tables: http://www.w3.org/TR/CSS21/tables.html#value-def-table

The working draft you refer to is a new model which is more powerful than either HTML tables or CSS2.

...which will be great in 2015 when enough browsers implement it to be useful. :)

CSS emulation of tables doesn't meet the requirement though.

The question was whether CSS supports the primitives required to do grid layouts without coupling the CSS to HTML, effectively requiring the two of them to be treated as object code.

If you're going to require that the markup contain divs that are ordered and nested just so, so that they can be styled to layout like a table, then you might as well just use a table. Either way you are coupling presentation to semantics.

CSS is obviously always coupled to HTML in the sense that CSS applies styling and layout to elements in HTML. If you don't have an element to delimit the chunk of content you want to style, you cant do it with CSS. The point is just that the markup HTML should be independent of any particular presentation.

You don't have to use divs, you can use semantic elements (P, whatever) if that is appropriate for the content.

You definitely might not just as well use a table. The trouble with tables for layout is that they have the wrong semantics, which means they makes the page less accessible.

First, I agree wholeheartedly that the language we use is never powerful enough for us to express ourselves. I'd say that even goes for print... but whatever.

I spent a few hours reading old RFC's because of this whole thread.

It looks to me like rfc 1942 got popular, and the CSS folks never came to grips with that. CSS1 is pretty given the constraints of the day. I think about CSS in two terms (I don't think there's a standard for this, i just made them up) Formatting, setting fonts, colors and padding; and layout, i think old newspaper guys would call it paste up, where the big blocks go on the page.

CSS is great at formatting. It sucks at layout.

This was their approach to layout, http://www.w3.org/People/Bos/Stylesheets/model.html

Mosaic had support for tables five months before that, http://www.eskimo.com/~bloo/indexdot/history/mosaic.htm

They must have known, and i don't think they had a credible solution to layout problems. they weren't willing to make a full layout language, so tables won.

CSS1 was mostly about typography, but CSS2 supports layout equivalent to (or rather a superset of) what is possible with HTML tables.

Here's a simple task you can't do in CSS2: Create a multi-line form where the labels are right-aligned to the fields, the fields all line up, and everything expands to fill the contents.

    <style>
	label { display: table-row; }
	span { display: table-cell; }
    </style>
    <label><span>Label:</span>
       <span><input type=text></span></label>
    <label><span>Longer label:</span>
       <span><input type=checkbox></span></label>

My bad, didn't check my facts, table-cell is in CSS2! Of course, in my defense, it doesn't matter which standard it's defined in if it isn't supported by IE. It isn't even supported in IE7 and we've just recently dropped support for IE6.

He seems to argue that alternative renderings - eg. for blind users - could be generated on the server rather than the client. This glosses over the important point that nobody is actually going to do that.

The beauty of correct use of html and css is that the burden of choosing an appropriate rendering is pushed to the client, which in turn means that the developer does not have to know in advance what kind of devices or assistive technologies will be used to render the content.

If I may monkeypatch the original argument, I'd point out that there isn't any particular reason that you can't output perfectly accessible HTML with this approach. In some ways its likely to be easier than some other approaches, since when you think this way, you're starting out with more actual, factual semantics in your data representation.

Moreover, if you're going to argue the "nobody's actually going to do it" argument, I'd say that "nobody's actually using CSS to generate one HTML page that works in a screen reader, cell phone, rich browser, and REST API" either. For the same value of "nobody", which is to say, not literally nobody, you can find a handful of people, but the idea that there's some mass of developers "correctly" using CSS is pretty silly too.

Obviously if you generate semantic HTML there is no problem. But the article argues (in the end) that accessibility instead can be achieved by generating different "object-html" renderings on the server based on e.g a header that says "i am blind". That is totally unrealistic!

Semantic HTML on the other hand is accessible by default, you have to specifically go out of your way to make it inaccessible or platform-specific.

But you also have to go way out of your way to make it look good. And with pure semantic HTML there are layouts that are flat out impossible. The only way to do certain things with CSS is by cluttering one's clean HTML with random divs everywhere (killing the markup/style separation in the process)...

Where the author suggested outputting audio when confronted with a "blind" header, I thought more along the lines of returning pure semantic markup. And presumably the abstract code that compiles down to html is purely semantic so it would be trivial.

I think HTML is intermediate code, not object code, not source code.

Just like you could code assembly by hand (and plenty of people still do) you can code HTML by hand. But in reality most html is generated by machine and then 'rendered' into a visual representation, the final binary end-product.

His entire intro is dumb. If you simply define object code as stuff a compiler emits and source code as stuff a compiler processes, than obviously every piece of data is both source and object code. That's the essence of the von Neumann architecture (and, incidentally, that's also why stack buffer overflows are possible). Repeat after me: data is code.

Funny, I thought HTML was a markup language. The article says HTML is (or can be) both source code and object code. I say it's neither. HTML isn't the source code for some application or piece of software, and it's not the application or software itself. It doesn't tell a cpu what to do, it tells a browser what to show.

Yes, of course. But it was clearly meant as an analogy.

The elements of good coding style that apply when writing a program in C don't necessarily apply to a compiler when it compiles a higher level language down to C.

Similarly, the best practices for writing HTML by hand don't necessarily apply to a program that generates HTML from a higher level abstraction.

By then end of the article, I was convinced the "source code vs. object code" wasn't an analogy, but a sincere claim.

I think one of the problems with seeing "HTML as object-code" is that it leads to lousy markup. Headers implemented with font elements and explicit line breaks. horizontal margins with blockquote elements. That approach makes sense when HTML is seen as plain object code that drives a browser to lay thing out a certain way.

It does not make sense when one of the most important readers of your site is effectively blind: Googlebot.

I've used both approaches, good semantic markup and sloppy made-for-IE. Choosing good semantic markup has never come back to bite me in the ass. Sloppy markup has gone two ways, more often been a time saver and soon thrown away, but sometimes come back as a horrible thing to maintain and extend.

worth saying that my argument has nothing to do with css vs tables, but I dont agree with this at all, it may be object code to you, but it is always source code to the client, the browser that has to render it, the screenscraper that wants to pull data from it, the client side scripts that want to modify it.

another disagreement I have with it is that even though it may be generated by whatever fancy backend you want, it is still source code to you, there are very few(no?) powerful html generation libraries that let you generate html as an intermediary format, before writing the "html compiler" you need to understand the html you are compiling.

asm is usually referred to as object code because there are very few people comprehend assembly language at the moment, there was a time when asm (or the binary code itself) could be referred to as source code, but those are long past for most people, web toolkits havent matured that far, you can write perfectly great assembly code without knowing any of it though c, you cannot write a program that generates nice web pages without knowing html and css (right now)

but it is always source code to the client

Source code is what people read/write, object code is what software & hardware reads/writes. HTML is always object code to the client.

HTML and CSS are still source code to most people -- most web sites are designed by designers who hand you off perfect static renderings before you tear them apart and plug them into whatever template engine you're using. But look at something like http://www.extjs.com -- the HTML is complete object code generated entirely using Javascript.

2 of those 3 'clients' were people (screen scrapers and client scripts). In order for either of these to exist the data needs to be in a code that can be read by people.

So, your point is that programs can't process data if it isn't human readable?

I think there are blind spots in this argument. The web will never be a stable environment. The technologies that have afforded its existence are notably fluid, and often leaky. These are characteristics that do not fit standard computer science.

To engineers who are accustomed to rigid runtimes, compilers, and so forth, this opinion that HTML is object code will resonate. However, it makes the assumption that by abstracting away the underlying HTML, you stand a better chance of delivering your program to the intended audience. I don't believe this is the case.

If you embrace the fact that HTML/JS/CSS will at best represent an approximation of the interface you intend to create, and leverage this accordingly, you will write code that will more easily adapt to best fit the environment in which it is run.

The power of web technologies is their resiliency. Programs written in compiled or runtime-based languages either run or they fail. Web code is much more dynamic. We should appreciate this characteristic, even when faced the frustrations of immature, misimplemented, and unsupported standards.

What are the blind spots to his argument? I read your comment but didn't see anything particularly in contrast with the post.

Edit: Oh actually I presume you're implying the ability to easily swap stylesheets, and that would be a valid point.

Huh? Why would that be a valid point? It's no harder to swap out different kinds of render methods than it is to swap style sheets.

BTW:

> Programs written in compiled or runtime-based languages either run or they fail.

This is simply not true. No matter what you're writing code in, you can write it in a way that exhibits graceful degradation. It's just that some languages make it easier than others.

I'm not sure, are you talking about changing the render method to output clean html which the user can style themselves?

Don't bother answering, I'm really confused. Why doesn't the world use XML and XSLT? I give up. I'm gonna just code using tables from now on.. o_O

'Huh? Why would that be a valid point? It's no harder to swap out different kinds of render methods than it is to swap style sheets.'

its much much harder to switch rendering engines than to switch css files

try changing this websites rendering engine, first you need to hack the server, then you need to understand the source code(and learn the language if you dont know it already), then learn how the renders are perfomed, how the data is modelled.

then try switching its stylesheet, that can be a click away if you want it.

What you say is true, but only because the software most people use on their servers makes it true. The conclusion is not that we should continue to use the current broken infrastructure, but that we should build different infrastructure. Your argument is kind of like someone in 1904 arguing that air travel will never be commercially viable because there aren't any airports.

I find it a bit distressing that I would have to explain this here on HN of all places.

I didnt make an argument I pointed out a blatantly incorrect statement.

but to follow your point is there anything fundamentally flawed in the concept of html/css/javascript that makes portable sites impossible, or are you suggesting we make some pluggable generic server side rendering that can be controlled by the client because css doesnt deal with heights very well yet?

> is there anything fundamentally flawed in the concept of html/css/javascript that makes portable sites impossible

No, of course not.

> or are you suggesting we make some pluggable generic server side rendering that can be controlled by the client because css doesnt deal with heights very well yet

Yeah, pretty much. That way you don't have to wait for the standards bodies or the browser developers.

> It's no harder to swap out different kinds of render methods than it is to swap style sheets

The point is that with css the client can change the rendering in ways not foreseen by the developers. If I happen to have a rare form of color-blindness that means I cannot perceive the color purple, I can create a Firefox extension that changes purple to blue, and immediately all websites in the world becomes accessible to me.

If we consider HTML a kind of object-code where presentation is hardcoded into the on-the-wire output (like eg. PostScript), I would have to call around to all web-masters in the world and beg them to change their render-methods to accommodate my unique disability.

> if you embrace the fact that HTML/JS/CSS will at best represent an approximation of the interface you intend to create

-- start rant --

Why embrace it ? I see this as a major shortcoming.

It's like it is 1986 again, everybody and their brother coding new and exciting user interfaces on their EGA screens.

Every website works differently. It's a UI nightmare. Throw in the 'approximation' factor and it is understandable why efficiency/productivity goes down the drain.

Because there is no standard menu structure, because there are no standard form validation methods you need to re-implement these basic features, and it seems that there are endless ways to do so.

The software wheel has not been re-invented as many times in the past as it has been on the web.

What should really be embraced is the resilience of the USER, not of the web technologies. End users are the people that have to put up with the messy environment that the architects of the web produce, and they do so admirably.

Take HN as an example. It's hard to even improve the slightest bit over the austere user interface that it offers. A few minor nitpicks, that's about it. And yet, I'm sure if I asked some art director to do a 'makeover' that he'd manage to run it right in to the ground. It would take 10 seconds per page to load and you wouldn't be able to make heads or tales of it. It would look positively fabulous though...

Rigidity is not always a bad thing.

-- end rant --

The "tables vs. CSS" argument has a clear answer and I can't believe we are still arguing about it.

CSS people who argue against tables are obeying their instinct that content and presentation should be separate. They are mostly right about this (I say mostly because the more graphical a webpage is, the more the content and the presentation are inextricably linked).

What the CSS people refuse to acknowledge is that CSS dropped the ball on this, and that CSS failed to incorporate tools for describing layouts in table-based ways. The table-based paradigm is a very natural way to describe layouts -- that's why everyone used tables for this prior to CSS!

Tables are not the enemy! Tables are natural! Tables are expressive! Give me any web page and I'll draw you the lines that show its "table-ness".

If CSS supported tables properly, the web standards people wouldn't have to walk around being enforcers about this. If you could easily convert HTML-based tables to CSS-based tables, everybody could be happy and live in harmony.

The CSS advocates should redirect their ire to the shortcomings of CSS, rather than the people who are working around those shortcomings!

"The table-based paradigm is a very natural way to describe layouts -- that's why everyone used tables for this prior to CSS!"

Wrong and wrong.

Tables for layout didn't really take off until the late 90's, and mostly were popularized by the work of one person (Dave Siegel, who wrote a book where he referred to table-based techniques as part of "third-generation" web design, implying just how much had come before).

And even when they did take off, tables were still burdened with the sorts of quirks and browser incompatibilities people complain about with CSS (remember font-size inheritance? Remember the two different baseline alignment models?); too many people seem to have forgotten all the tricks they had to learn to make those layouts work properly, and how complex the resulting HTML had to be.

> Tables for layout didn't really take off until the late 90's

Which was coincidentally when websites started having sidebars. Are you arguing in favor of pre-1995 web design? Are you arguing that there is a more natural way than tables to express site layouts with sidebars?

When I say "prior to CSS" I mean "prior to wide CSS adoption and browser support". Yes, CSS1 was released in 1996, but it didn't really catch on among web authors for a few years (and wasn't really practical to use anyway due to limited browser support). In that intervening time, websites started sprouting sidebars, and basically all the sites that used sidebars did so with HTML tables.

> And even when they did take off, tables were still burdened with the sorts of quirks and browser incompatibilities people complain about with CSS

Quirks or no, HTML-based tables are more fit for describing layouts than CSS ever will be until web authors can use "display: table" or something like that. With HTML-based tables, you're working around browser quirks (which really aren't as bad as you make them out to be). With CSS, you're working with a language that is too weak (even if implemented perfectly) to express what you're trying to say. With CSS, a three-column layout (something that many, many sites want) is considered a "holy grail" (http://www.alistapart.com/articles/holygrail/).

CSS (pre-"display:table") doesn't have the right abstractions for achieving designers' demonstrated needs. Why do you live in denial of this fact?

> until web authors can use "display: table"

IE8 supports it, so any day now.

The first point is absolutely correct. Nearly every other visual layout system uses grids or stacks. Novices love using Excel for layout. Nevermind computers, look around and you'll find plenty of examples of space organized with grids.

Say what you will about semantic purity yada yada but grids (aka tables) are damn intuitive.

The issue is that they're both flawed solutions and you should pick the solution that's the least worst depending on what you're trying to do. Sometimes that's tables, sometimes that's CSS, sometimes it's some combination of the two. They both have advantages and disadvantages.

Saying "CSS dropped the ball, and that CSS failed to incorporate tools for describing layouts in table-based ways" is an incredibly oversimplified summary. Back in 1996, CSS1 was published and while the styling was incredibly well-thought-out, the layout part of it was somewhat tacked on (somewhat to its detriment), with the aim that CSS2 would tackle the complex layout issues that needed to be addressed. CSS2 was introduced in 1998, except no-one implemented much of it for years, most notably display:table which gets the most of the advantages of using CSS and tables within CSS. Sometime around 2002 or so (after the death of Netscape) someone realised you could hack around with 'float' property (introduced in CSS1 and well-supported) to achieve column-like layouts.

Once IE6 and IE7 dies we can finally switch to display: table. I'll give an optimistic estimate of this happening in 2013, but it really depends on how long XP/Vista last.

A huge part of the problem is that HTML is a really bad object code for UIs.

HTML should not be used for UI, it's for inserting content and from elements into a presentation. CSS, with the help of graphics and javascript for interactivity should do the UI.

Doing something like:

  with-html
    :ul :id "site-menu"
    dolist (menu-item (list "home" "news" "blog" "aboutus"))
      :li (:a :href concat(*server-root* menu-item) menu-item)

Should generate this:

  <ul id="site-menu">
    <li><a href="example.com/home">home</a></li>
    <li><a href="example.com/news">news</a></li>
    <li><a href="example.com/blog">blog</a></li>
    <li><a href="example.com/aboutus">aboutus</a></li>
  </ul>

Then in a CSS page referenced by that presentation, you do whatever you want to #site-menu; you make it a vertical menu, horizontal, tabbed, or even generate big fat fish-eye icons that look like the Mac's. HTML knows nothing of that.

Used in this sense, HTML is a very good object code.

In what universe are content, forms and menus not part of the UI?

In a world where you can layer truly higher-level UI elements on top of them? Just because some elements map 1:1 doesn't mean all do. You can generate a button from <button /> or <input type="submit" /> but that goesn't mean you can't generate image "buttons". The final generation of a "button" should be left to your rendering module.

This is very similar to addition being a far higher level process than the ADD opcode present in every instruction set. Sure, sometimes addition translates to a single ADD, but not always.

What you're describing is what most would call "skinning" or "theming", whereas "user interface" is generally considered to penetrate much deeper into the functionality of the app. Decoupling UI requires an incredibly abstract description of functionality. I've never seen a practical and generalizable example of such a thing.

Skinning, as you point out, often demands modification to the DOM, a task to which HTML and CSS alone are unsuited. It can be done with JavaScript, but it's much more practical and reliable to use a server-side abstraction a la ASP.NET or Seaside. This is more or less the point made by the original article.

The problem is that your "object code" is someone else's "source code". When you follow standards, it's easy for people to use what you've published; when you don't, it's painful.

A simplistic example: say you put out a typical web page with a navigation area and content area. Maybe for some reason, your website is much easier for me to use if I put the navigation above or below the content or maybe you put it on the left, and it works better for me on the right. If you used standard practices (CSS) to position your elements on the page, it's really easy for me to go in and mold that to exactly what I want. Why? Because it's the standard, so there are plenty of tools out there for this. All I do is tell the browser to overlay my css rule on your page and I'm done. On the other hand, if your layout is done with tables, well then it becomes much more difficult because you didn't follow the rules that the majority of us have agreed to.

can you show an example? most sites with pure CSS layouts must have the HTML elements ordered specifically, otherwise it breaks, due to the limitations of CSS.

the best way to customize sites in a client is with something like greasemonkey, where you can use javascript to manipulate the page. you can do it with just css too of course (like stylish) but usually that's limited to just changing the sizes, colors and visibility of things.

I think this makes good points about how we should be working with html these days, except those few of us who do static tables by hand.

One thing I am concerned about in the concept of doing all the work on the server is that CSS has the ability to let the client override some of the presentation issues, such as is the case for accessibility. I wonder if that can be done as effectively on the server.

The server is still producing HTML and CSS which can modified by the client.

GWT fully embraces the notion that the languages implemented by the browser can be treated as target languages for cross-compilation. The beauty of its design is that the server need not play any role beyond delivering the compiled output...or rpc/json requests for data if you need some. I'm shocked that GWT went unmentioned in his essay and the comments.

This a a major leap. Once you understand that HTML is object code, a whole new world of architectural possibilities opens up to you.

Not exactly a new idea either. pg talked about this years ago...

http://news.ycombinator.com/item?id=50159

Ron Garret reads or has read HN, so its very possible he knew about that comment.

I didn't know about that particular comment, but I did know that this is not an idea that's original with me. It's completely obvious to anyone who has learned Lisp. The only reason I wrote it is that it's apparently not completely obvious to CSS advocates. I seemed to have garnered their attention for reasons passing my understanding, so I thought I'd try to take advantage of that to spread some enlightenment. I have found that sometimes merely stating the obvious somewhere that people can see it and link to it can be useful.

Not only is HTML object code, but the code that generates my HTML is also object code. Macrology is fun :-)

Seaside and Web Velocity are very much in line with this idea.

This is also the approach in ASP.NET. You build the page out of controls, and each control knows how to render itself as HTML.

The linked comment seem to state that if you consider HTML object code, then you don't have to worry about accessibility. This is obviously wrong - HTML does not become more or less accessible whatever you call it.

However, used in the right way, an abstraction on top of HTML can improve accessibility. For example IE versions before version 8 does not support display:table, which lead many developers to chose table markup rater than CSS (because the share of IE users on a given site typically is greater than the share of disabled users). But with a higher-level language you can write:

  (flexible-grid
    (row
      (cell (width fixed 200px) "This is a sidebar")
      (cell (width spring) "This is the main content")))

And for IE-user you render this as table-markup, and for everyone else (Firefox-users, small devices, Google etc.) you render as accessible non-table HTML+CSS.

Some developers claim to find table-markup much more intuitive than equivalent CSS. In that case you can choose a language like:

  (table
    (tr
      (td (width: 200px) "This is a sidebar")
      (td "This is the main content")))

...and still render it into clean, accessible HTML for everyone except IE<8 users. Win-win!

HTML is not object-oriented. It maps to objects as does a relational database.

They don't mean object as in object-oriented, but rather as in compiled (but not linked) .o files.

I need to make a blog, where I can pontificate on things I don't understand and get lots of pageviews.

Reply on news.ycombinator.com