Re: web UI in general is an industrial dumpster fire...

I should have qualified that. It has done a great job of sharing textual information. However, it provides convoluted, unnatural, and inconsistent control over format, graphics, and screen real-estate. We should not have extended it for tasks that need graphic-intensive control, but instead provide an alternative to the standard. At least explore alternatives as an industry.

> I'm of the strong opinion the "layout engine" should be on the server and that the browser should be a dumb x,y,z coordinate polygon plotter.

OK...so if you search for something on google you need to know the coordinates for every pixel in the rendering of the text you are looking for?

Who is "you" in your scenario? It would be similar to printer formatting languages. The printer driver translates a document into lines, vectors, and polygons, and sends those to the printer as page coordinates, except the page length is not limited to paper's limit. (We'd probably have to add event triggers on designated polygons to handle UI interaction.)

The equivalent of the "printer driver" is the rendering engine on the server that takes your document or data and formats it using whatever formatting/layout engine YOU choose. The "input document" could be HTML even. We don't have to toss away HTML to use it. The difference is it doesn't have to be HTML.

In some ways it would be closer to working with PDF documents, except it wouldn't be based on "paper" conventions. The width would typically be dictated (or requested) by a particular device (client), and the length would be whatever the renderer decides is needed, typically based on the content being rendered.

Office workers love PDF because it's WYSIWYG. Browsers don't butcher their original vision. But, keep in mind the layout engine does not have to be WYSIWYG. The key point is your shop decides, NOT a standards committee. Layout engine FREEDOM! Hallelujah!

My question was, how would Google index pages and make them searchable in this system?

My main focus is on "productivity" applications and CRUD, not so much documents. One doesn't typically index applications in a Google-esque way. I don't propose we throw out all the Web, but rather create (or extend?) standards for the things HTML/DOM/CSS do poorly. My apologies for not making the scope clearer. (Maybe that's why I got a "-1" score.)

And, there may still be a markup language with text as text and other semantic info. The new standard may be able to use existing HTML tags, but add supplement attributes to control precise placement, and other features HTML/CSS lacks.

By the way, Google can index PDF documents reasonably well, depending on how the PDF was created. This is evidence that precise control over layout doesn't necessarily prevent indexing and summarizing of text and content.

I will also point out that many graphic designers are frustrated with CSS also because they envision a concept, but have a hard time getting web pages to do what precisely what they envision. It's why Flash was popular with them: the proverbial paint strokes wind up exactly where you put the brush down on the canvas. The artists may still want their work to adjust to the end-user screen size, but they want to control precisely HOW it adjusts: they want to write the size adjustment formulas themselves (or select among multiple API's), not rely on browser programmers and their variation on the CSS engine, which often differ across browser brands and versions.

Can't you already do everything you propose with the HTML canvas element then?

But I can't see why you would want to render something as mundane as a CRUD UI through such a complex and slow scheme. For perhaps a game or some truly unconventional UI, it makes sense to use SVG or canvas to render it. But then you also want the rendering logic on the client (in JavaScript) because it would be far too slow to round-trip to the server for each mouse movement.

Btw. Google can index PDF files only because the PDF format contain text in the form of character strings, not as drawings or bitmaps, as you suggest.

I haven't seen a good realistic example of the canvas element doing what I expect. Didn't you even admit "canvas" is overly complex and slow, or did I interpret that wrong? I'm not sure what you mean about JavaScript either. Perhaps an example?

As far as character strings, I don't propose rendering text via vectors. But PDF's do control text position far better than HTML/CSS can or does. I realize there's a lot of details to define and work out, but HN is probably not the place to iron all that out.

No I don't think canvas itself is overly complex and slow. Canvas is fine when you need to go beyond what is possible with HTML and CSS.

I'm saying your proposal to perform rendering on the server and just stream pixels to the client is going to be overly complex and slow. Just imagine how you would implement a hover effect using this scheme. Or screen resizing. Or scrolling...

> But PDF's do control text position far better than HTML/CSS can or does.

You can place text precisely using absolute positioning in CSS. It is just rarely a desirable approach since the layout will not adapt to screen size.

It would generally be vectors sent, not pixels. If the kit or standard came with decent and common GUI/CRUD widgets and related attributes, then one would not typically need to re-implement hover indicators etc. on the client. (There might be a "hoverbordercolor=blue" attribute, for example to override the default hover color. And normally you wouldn't mess with the default.)

It shouldn't be slow and bandwidth intensive if you stick with typical and common stuff for productivity applications. If one values eye-candy and fancy animation above productivity and reliability, then they can use the existing standards. I don't propose replacing everything, just supplementing and/or extending for work-oriented stuff.

And CSS's existing absolute positioning is not absolute in my experience. I get different results in diff browser brands/versions/OS-settings. Screen size adapting was covered in another sub-thread. People are so used to thinking in terms of HTML/CSS that I have a hard time explaining what I have in mind. I may need to make a more thorough write-up.

You can already send vector graphics to the browser in the form of SVG.

I've yet to see it used effective to give us desktop-like GUI's. My experience is SVG lacks common GUI widgets, and text positioning is still inconsistent across browser brand/versions/OS-settings. Downloading tons of JavaScript to emulate typical GUI's gets right back to fat-client problems created by current browser "standards". Maybe someday these weak points will be solved, but so far it doesn't seem ready. SVG is meant to draw pictures, not manage GUI's.

(There is no "reply" under your comments, so I had to put the reply on the prior level.)

Goto11, you are correct that I was ambiguous. I was mostly talking about positioning and sizing itself when I said, "browser should be a dumb x,y,z coordinate polygon plotter." I should have said, "browser should use absolute x,y,z coordinates for sizing and positioning objects....". By "dumb" I meant the layout & sizing engine is "dumb", not every UI object. No more client-side auto-flow nor auto-size. Good catch. I'll hire you to debug the wording of my Next Great Write-up :-)

It is rather unclear what you want. First you state you want the client to be a dumb plotter and fully generate the layout on the server. Now you want everything we already have, and in addition a set of common GUI widgets in SVG. These seem to be opposite ideas?

So I need to wait for a network roundtrip for all tabs if I resize my browser? So sites can freely ignore my styling settings (it's bad enough already)? ...

I'll agree that resizing delay is probably a weakness. But I'd gladly trade that away for simplicity everywhere else. Also, because it wouldn't need gobs of CSS and JS for formatting, the re-render code (vectors) would not be that big and thus transfer relatively quickly. Remember, we are simplifying what the client needs to do and know. Excellent observation, by the way.