Earlier quoted context omitted.
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 fa…
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 intens…
Ask HN: Is it just me, or is CSS too damn hard?
351–358 of 358 posts
Re: Ask HN: Is it just me, or is CSS too damn hard?
#352> Is it common for other developers to have issues with it, or is it just me? Is there any material out there that made CSS "click" for you? If you're coming from an application development background, you will hate CSS layouting. It's the most ass-backwards way of structuring a UI that you will ever encounter. A lot of web people who never used stuff like Qt, Swing, Winforms (etc) just don't realize this. They think…
Re: Ask HN: Is it just me, or is CSS too damn hard?
#353Earlier quoted context omitted.
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 intens…
You can already send vector graphics to the browser in the form of SVG.
Re: Ask HN: Is it just me, or is CSS too damn hard?
#354Earlier quoted context omitted.
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 i…
Re: Ask HN: Is it just me, or is CSS too damn hard?
#355Earlier quoted context omitted.
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 i…
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 :-)
Re: Ask HN: Is it just me, or is CSS too damn hard?
#356Re: Ask HN: Is it just me, or is CSS too damn hard?
#357what helped me is understanding flexbox and realizing you can use negative margins.
Re: Ask HN: Is it just me, or is CSS too damn hard?
#358Sorry, but web UI in general is an industrial dumpster fire. 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. The layout "math" should all be on a server. That way we could pick and choose layout/style engines that fit our domain and shop preferences: OOP, FP, set-theory, declarative, whatever you wish; NOT the viewpoint of T…
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.