

HTML is object code - lisper
http://rondam.blogspot.com/2009/08/html-is-object-code.html

======
skoob
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.

~~~
wvenable
_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.

~~~
derefr
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.

~~~
jfoutz
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.

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

~~~
wvenable
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.

~~~
olavk

        <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>

~~~
wvenable
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.

------
olavk
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.

~~~
jerf
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.

~~~
olavk
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.

~~~
__david__
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.

~~~
jacquesm
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.

------
Locke1689
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_.

------
baddox
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.

~~~
darshan
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.

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

------
daleharvey
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)

~~~
wvenable
_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.

~~~
daleharvey
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.

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

------
zacman85
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.

~~~
anc2020
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.

~~~
lisper
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.

~~~
daleharvey
'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.

~~~
lisper
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.

~~~
daleharvey
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?

~~~
lisper
> 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.

------
haberman
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!

~~~
ubernostrum
"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.

~~~
haberman
> 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?

~~~
mcav
> _until web authors can use "display: table"_

IE8 supports it, so any day now.

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

~~~
mahmud
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.

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

~~~
mahmud
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.

~~~
extension
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.

------
shawnjgoff
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.

~~~
tumult
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.

------
wglb
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.

~~~
pohl
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.

------
edw519
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>

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

~~~
lisper
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.

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

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

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

