4 ms·

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,

by tabtab 8y ago

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!

goto11 8y ago
My question was, how would Google index pages and make them searchable in this system?
- tabtab 8y ago
  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.
  - goto11 8y ago
    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.
    - tabtab 8y ago
      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.
      - goto11 8y ago
        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.
        tabtab 8y ago
        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.

by tabtab 8y ago

goto11 8y ago

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

tabtab 8y ago
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.
- goto11 8y ago
  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.
  - tabtab 8y ago
    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.
    - goto11 8y ago
      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.
      - tabtab 8y ago
        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.