Richard Sexton
August 2015


Vivaldi is the new web browser from the core Opera team that seem to have split from Opera, the latter now simply rebranding Chrome now thus loosing all the unique features Opera had, many of which they invented such as tabs and CSS.

An experimental version of the browser has been out for a couple of months now, it's on the edge of being my "daily driver" here now, displacing the venerable Opera 12 that I'll never upgrade.

So. Is it everything I've hoped for? Looks like it. Probably. It might be, or be on the path to being, the best browser hands down bar none. And that sucks.

Why?

Recall Shaw's quote about the reasonable man:

"the reasonable man adapts to the status quo, therefore all progress depends on the unreasonable man"

So, by making the perfect browser for today's needs, that's adapting to the status quo. I want an unreasonable browser, it's the only straight line between here and a vision I have of how this is supposed to work.

Here's my list of unreasonable requests and features. You'd better sit down.

1) Dump HTML
2) Dump CSS

Ok, you can leave them in for comparability with 20th century stuff, but they should always bee swapped out in a fair and just word.

3) Keep JavaScript.

Markup languages are great for marking up documents into virtual and physical containers. They're just swell. But as a way of driving display and print devices? They're the worst thing ever and it's a miracle they work at all. JS is the only language since C worth knowing and a naked browser with just javascript could do everything (and more) you can do with HTML and CSS.

4) Decent web page editing.
I've been writing and looking at web based editing sytems since the second day I stumbed onto HTML in 1993 or 4. I think mine is better than anything out there and we're a generation away from decent web editing. Fair play, the technology just came out to let you do certain things.

Think about that. The web came out in 1989 and in 2015 you can do a few more things. Let's see how HTML5/CSS3 stack up today:

"I need to display a 14 point outline of an upper case Garamond demibold 'A' - how do I do that in HTML?"

"Oh, easy, in Webkit, you just say -webkit-text-border"

"What about everything else?"

"Not supported."

That's right. You can't do it. a quarter century of HTML and it can't do this... yet.

Will it be another 25 years before this happens? 50? Who exactly has the 100 year plan for this?

This is not a failure of math or science, this is a failure of vision and thought.

HTML came from SGML which came from SCRIBE, Brian Reid's document database system. It's the sort of product that makes writing a maintenance manual for a 747 possible, to quote Brian when he worked ar director of Digital Equipment Corporation's Western Research Laboratory (DECWRL).

HTML isn't really new. Before it there was runoff.

Runoff/Roff was the markup langiage that came out of Bell Labs, Cherry Hill, in the late 1960s early 1960s. Three major things did: Unix, C, Runoff.

Runoff was written to Dennis and Ken cold write manuals for Unix and C by using Unix and C. The first job any Unix system ever did was to replace hot lead publishing. Ironically, as a teenager I worked at a newspaper computerizing their system to replace hot lead casting of actual printing plates in the evolution of digital typography and printing.

So all though the 1970s if you did anything with printing or displaying text you used Roff and it was as ubiquitous around Digital machines as HTML is today. So there was a real case of lunch bag letdown when Sir Tim proclaimed ot the world "Here's how you make a new paragraph: "<p>" and here's how you make the first heading: "<h1>"

Sir Tim beams.

But this was a facepalm moment.
Note the similarity:


In other words, Sir Tim gave us state of the art 1969 text markup. By 1989 Tim was able to use a laser printer that didn't exist in 1969 and in 1987 I wrote a program a programmer, such as Tim, might use to format source code for HP or Postscript printers. If you wanted to make a printout on an HP or Postscript printer at CERN you probably used my code.

Lasers changed printing, not the web. Why worry about conversion to 1280px screens to HD or 4K, laster printer imaging models already deal with far greater resolutions and you'll note PCL died, as it should have as an obsolete relic of a more primitive world, whereas the postscript imaging model still in use today in Acrobat.

Dennis and Ken had serial line printers. 10 years later everybody had an Epson MX-80 dot matrix printer, but they were functionally identical and drop in replacements; you could unplug the $25,000 Digitial PDP-11 printer and plug in a $99 Epson and it'd still work.

Either one, when you send it the letters "H e l l o   w o r l d" it'll print "Hello world".

Not so a later printer. Send it those 11 letters to a laser  printer or typesetter  and you get nothing. Send it to any HP compatible (and by this it means "can speak the printer control langauge known as "HP-PCL" printer and you'll get 11 tiny letters and the paper might be the wrong way around.

Laser printers are so complicated that you have to talk to them in their own language and there are two: PCL used by HP and compatible printers, and PostScript used by LaserWriters, Typsetting machines, iPhone and PDF files.

PCL is not meant to be read/written by humans.

For exampe: "ESC & l # c" sets the VMI to #/48 on an HP Laser. Want to draw a circle? Send me the dots. All of them. Junk.

Got that? If you want to print on one of these you need a program to print your file for you, you can't just send text to the printer and have it show up on a page. It has to be a combination of PCL commands and the original text you want to be printed.

Postscript on the other hand is a computer language, like Forth, and it drives the guts of all high end printers and typesetting equipment. It's a human readable language. A program to draw a circle is a few words, not megs of data like it is in PCL.

In 1998 Canon sold a $12,000 laser printer engine and in 1985 Jobs announced Apple would sell a $7000 PostScript printer.  PCL "lacked the power and flexibility of PostScript". So does HTML and it's 25 years later.

The LaserWriter succeeded because it could be shared among up to sixteen Macs, you'd need sixteen HP's for 16 PC's to do this or additional hardware, Macs did it out of the box and because that same PostScript file can be used by Phototypesetters as well as LaserWriters then you can go from screen to paper, then to mylar for proof, then clear mylar at 1200 or 2500 dpi for production. Oh and don't kid yourself that "effective 4300 dpi" from an ink jet is even close to a 2500 film phototypesetter. You gotta see this stuff.

Now, Sir Tim will have understood all this, he was at CERN at the time, and I happened to have written a program that prints files on either HP or PostScript laser printers. It was the only thing I ever write that I released onto the net (around 1987) and I only got one bug report - from CERN.

At seven thousand grand a pop laser printers wern't common in the mod 1980s. I had an engineering prototype from QMS and used it to typeset the manual for the Amiga program that would eventually morph into Flash.

So I had one and sir Tim had one. Or somebody there did. I bet they had more than one. But the point is although the technology changed it was the same problem Dennis and Ken faced with Unix in 1969 "We need to get a printout" or "we need to send this to the typesetter now" and none of these devices could take plain text.

The major difference between PCL and Postscript is PCL is a markup langauge, the same as Roff and Runoff where you add commands to tell the thing what to do with the text it's getting. Postsctipt on the other hand is a compute language, so you send a postscript program to the printer and text you want to print is part of the data of that program.

The point is there's intelligence there. Consider the case where you want to print a circle. For the HP you send all the dots for the circle, on a serial printer this could take 5 minutes. In postscript you say "circle". So you send 6 letters to the printer and not 6 megabytes of dots; because it's intelligent you can describe the circle and not have to send all the dots that make up the circle to the printer.

HTML is the PCL of display interfaces. Postscript is what should have been used. You can't say it won't work, PDF's are PostScript and they work fine. Actually PDF's are a couple of evolutionary steps above Level 1 Postscript.

Another problem was, at the time, Postscript was covered by patent protection. That expired a couple of years ago, and Adobe has frozen Level 1 PS now at EOL.

This is fine, the language itself is trivially extensible, it could be shipped as a raw interpreter and would still be useful, but I digress.

My guess is patent protection was the biggest reason to reject PS as the language of the web - if it was even considered at all. Patents would have been a show stopper here.

Also the complexity of PostScript - having to write and send a program to a printer as opposed to just sending the text and a few markup codes is overkill.

That's the fatal error.

1) Presently HTML5/CSS3/Javascript - and all three *are required* to come close to what PostScript could do in 1985 - are now more complicated that Postscript ever was.  Plus nobody writes in HTML any more, most is generated by programs - that were generating Postscript a decade prior to doing HTML. Also, any still writing in native HTML (waves, hi) would most appreciate the power and flexibility of it more than anyone.

2) Look at a web page. If more than half the code is for positioning the object than describing the object itself - you're wasting time. While there is always going to be positioning the ratio of positioning goop just to say where stuff should be to line up perfectly is a bloated nightmare in the HTML model and worse than any of the similar things that came before it: GKS, PhIGS, etc. They went away, just as HTML should.

That is HTML stands out where the majority of the language by volume of commands, is for the most minor of tasks: positioning. Half a 300K file may be to get stuff to be in the right place to look right (and god knows it's hard enough to get it there) whereas in the most complex postscript image, positioning is always trivial - x, y in "points" - which works as well at 75 dpi as it does for 5000 dpi or 4K.

I don't buy the separation of markup from content. Because PS is an extensible language you can do anything you bloody well want.

To be honest, after watching this for a few decades I'm not sure what this great separation of content and markup gets us. I suspect most people just don't give a shit that just want to be able to put a box at x% and y% and have it actually goddamn show up. Text flow? Who really gives a shit about that? Who are are you people? Hands up.


So. it's twenty five years after HTML was adopted as THE language for web markup, without discussion and no debate. Do we really not get to talk about this?

It took ten years to ass gradents, box-shadow and text-shadow. Oh and you can sort of draw shapes now by using the rounded corner option and the new transform math stuff nobody understands. Buf if you want to draw anything else you need SVG which is new.

And there is is. HTML was too lame so we needed JavaScript to do ANYTHING and we added CSS after that as it cut down on the amount of JS we need. So now to draw a Bezier spline the answer is... "add another language".

No. Just no. This violates every principle of scalability. Lemme guess, there's a 3D equivalent of SVG lurking in the shadows too now isn't there?

Sun demonstrated a realtime bouncing bezier spline curve in 1986 on a $250,000 sun. I went home and did it on an Amiga. Think you're gonna do that in HTMK or PCL?

Well you might if you use HTML5, CSS3, Javascript and SVG. A good person intimately familiar with 4 of the most complex compute languages every written can probably knock it out in under a week, a couple of days maybe, and on a decent 2+ gigahertz machine can probably hit 100+ frames a second.

In 1986 a $1200 5 megahertz 68000 could do that - with postscript.

How about rendering an outline of an 'A' ? You can fake it with text outline and it's ok but it fails miserably below 30 pixels. the Postscript. NeXT used to do this and was flawless down to about 12 on a crappy display, 9 or 6 on better ones.

So after 25 years of refinements, and throwing more language at it, there are still things you can't do on a screen because the language - languages - can't do it. Gradients in text? Nope, can't do that either.

Both are a one liner in Postscript and have been since 1985. And you can't do it at all in 2015 after 5 generations of HTML refinements and 3 generations of CSS refinements and so on and so forth. This is just fucking embarrassing.


Here are the reasons to use PS instead of HTML:

1. The amount of markup as a percent of payload will shrink. With https being nearly ubiquitous and ubiquitous slow, this would help make things a bit more snappy. You can typically do in a 10K .ps file what it takes several megs of html, and it's not scalable, PS is, infinity. The same icons can work at 100 x 100 displays or on 4K monitors.
2. Native to IOS and Typesetters. This makes the step from web page to print not a step any more. Same file works flawlessly on both devices. One version of one file. How many versions of various language do you want to maintain?
3. Any decnet program has an "output to PostScript" option. Even the Windows printer utility does. It's the industry standard. Yet we ignore it on the web despite Display Postscript shipping o
4. You'll be able to do more things. It'll be easier than now, a LOT easier. 
5. HTML has run out of breath. By the time all the missing features are added (maybe in 3 years from now we'll get text gradients) it'll be obsolete - the entire model is wrong. If we want a new feature in the web we have to get browser authors to add it. If we had postscript - everything's a PostScript program and here are no limitations whatsoever - we can get back to 1986 levels of rapid development.
6. The change can be utterly transparent and can only be done by browser manufacturers and HTML need not stop working. All that's required is to interpret level 1 Postscript inline. That's all ya gotta do. The SVG code probably has all you need and you can modify the V8 interpreter to be a PS interpreter thus adding the async i/o of JS which is a nice touch.
   
   This if one webserver's default for http://example.com is index.ps and not index.html, and doesn't look any different, then who's to know? It's that simple.

So, all Vivaldi has to do it support Level 1 Postscript inline. Don't spawn off an external viewer. Just do what it says and draw. Embedded postscript change publishing, being able to drop a Postscript illustration into a Word document eliminated the need to great extent for Knuth's arcane TeX system and similarly so being able ot say "Garamond demibold findfont setfont 100 scalefont draw" will draw you the outline of a letter 'A' so perfectly even under a microscope that you cannot do at all today in HTML5/CSS3. The radial gradients and gradients that didn't quite make it into Opera 12? Free in PostScript, why worry about that stuff?

A hybrid of the better parts of HTML and Postscript makes sense to me and I can see some combination of <header><article><section> with bits of postscript here and there to do the illustrations - not all the world is a jpg and i you check the fewest bytes you need to send to render a bar chart are a Postscript program - I checked.

So, please add postscript. Or pay me and I'll add it. But the reasons for doing it are manifold: certain intermediate steps in the publishing sector are eliminated. It takes less time to design, code, transmit and render the same thing with Postscript than it does with current web languages - which can't even do what PS did when Reagan was in Office and on a 12 Mhz 68000.

Plus, the most altruistic reason for browser authors - add PS and there's no more debates about language, no more meetings, work groups, standards bodies and their glacial movements. Everything's a PostScript program. You want a feature? Rather than schedule it into browser and standards development bodies, here's the PS code. Done. Ship it. Fini.

It's easy to add, there are no limitations, it's transparent to the user, is of great benefit and not hard to do. The time you save will probably be your own.