4 ms·
HTML and CSS are a bad fit for rendering heavy graphical interfaces because they fundamentally follow a document flow rather than grid-based layouts. Flexbox an
by yumaikas 10y ago
HTML and CSS are a bad fit for rendering heavy graphical interfaces because they fundamentally follow a document flow rather than grid-based layouts. Flexbox and css-grid are helping some in this area, but they are not used very often.
(not to say that HTML and CSS aren't useful, but they are far from the idea means of rendering a UI).
HTML does work fine when you use it for mostly document focused work, and I enjoy the interactivity and connectivity that web browsers have brought to the web, but I'd love to see an improvement on it all.
- pcwalton 10y agoFlexbox is that improvement. If you discount flexbox due to "not [being] used very often", then you can't logically argue for burning down the HTML and CSS stack and replacing it with something else that has zero market share.
- dheera 10y agoQ: How do you make a video maintain an aspect ratio and fill up the width of a parent? A: Nested div hell. Q: How do you make an image maintain an aspect ratio and fill up the width or height of the screen, whichever comes first? A: Nested div hell and JavaScript. Q: How do you make a scaled background image stay put even when the keyboard input pops up on a phone? A: Supreme JavaScript, CSS, and div hell. Q: How do you center a paragraph of text vertically in a div? A: Nested div hell. I'd say FlexBox is pretty inadequate. Why can't we have things like: #my-video {width:80%;height:calc(width*2/3);}
- pcwalton 10y agoCSS object-fit handles your first two complaints, and CSS Variables handles your last one.
- Dylan16807 10y agoAren't CSS Variables just constants you can reuse? How are they going to let you set width to 80% and height to 2/3 of whatever that ends up being?
- pcwalton 10y agoBecause percentages in heights are usually relative to the width of the containing block.
- yumaikas 10y agoMy point wasn't so much that Flexbox isn't that improvement, but that I haven't yet had a chance to fully learn it, and I suspect that a lot of front-end developers are in a similar space. I plan on rectifying that soon, but it is yet another thing to add atop the large number of other things that comprise understanding modern web browsers. I'm not saying that we should burn the HTML and CSS stack. It has served the web very well and will continue to do so, but until the last few years, it's been a document focused stack that's been twisted into doing app development, and in some sense, it still is. HTML and CSS are not the best tool for heavy GUI development, a la Photoshop, Visual Studio (not VS Code) or other large GUI intensive things. Most web apps have yet to replicate the combination of features and/or performance of those types native applications. Flexbox is an improvement there that helps with layout, but that doesn't change the fact that we are working with the DOM under the hood, with all of its various quirks and performance issues. (Not to say other GUI frameworks/APIs are perfect, or necessarily better. Some of them just allow you to optimize a little closer to the metal). One can point out that large GUI tools like Photoshop aren't being created as much these days, outside of AAA game dev, CAD, or the like, or that many large GUI's use web views to help display documents, a la Steam. I sincerely hope that Servo's "Web Browsers are essentially AAA game engines" approach catches on. I'd be interested to see how an event-based html5 canvas GUI library would compare to DOM.