3 ms·

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

by 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.
  - goto11 8y ago
    You can already send vector graphics to the browser in the form of SVG.
    - tabtab 8y ago
      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.
      - goto11 8y ago
        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?
      - tabtab 8y ago
        (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 :-)

by tabtab 8y ago

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.
- goto11 8y ago
  You can already send vector graphics to the browser in the form of SVG.
  - tabtab 8y ago
    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.
    - goto11 8y ago
      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?
    - tabtab 8y ago
      (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 :-)