And we need to stop relying on JS so much.
> We spent a decade rebuilding the browser by hijacking routing, manually syncing state, rebuilding forms and transitions in JavaScript to match native app expectations. Now the browser has caught up. It's time to stop the hacks and build on the web again, but properly.
We've been "holding the browser wrong" for the past 10 years.
Unless you're arguing that we should stop cramming app-like behaviour into a system that doesn't support it. Then I'm with you.
Given that even newspaper websites are now built as applications, we should accept that the web is an application platform (with one of those applications being displaying articles) and rework HTML as an application display language. And we need to start relying on JS more.
(Specifically, we should reimplement most traditional HTML elements and CSS as web components on top of a basic core web runtime. Then we could have a small standard for the core web that was practical to implement - just a very minimal layout engine and a JS interpreter - and everything else could be in the "component library" rather than something browser makers had to implement by hand. And then pages that want to use their own components or some other third-party components - which is most pages these days - could skip all that cruft)
The users want to get a document, not an app. That's what the web was made for, documents.
Admittedly even with .war format and other attempts, this was possible only for a brief time. Now we have a crop of readability converters because even print to pdf is useless most of the time.
The apps are mire likely used to hinder ad blockers than benefit the reader.
What feature of an article needs an app?
This could be what we want, but I can't help but think about what we've lost.
The web is getting smaller and smaller, being dominated by the bigger players (Google, Microsoft, Apple, et. al) for whom pushing opaque web standards and "applications" benefit only them as gatekeepers.
While it's still entirely possible for people to still build websites, search engines like Google don't prioritize them - leading them to never being discovered. 90% of the web is still the 'small' web and we can't ever discover them because they're not being indexed by Google (why should they? Most of them don't include Google's tracking js scripts ['analytics']).
The web was never supposed to be like this. It's turned into a massive surveillance engine for the big corporations.
I'll leave this here: https://wiby.me
I’m still not entirely sure what this is, but I visited, hit “Surprise Me”, and then spent a couple hours listening to/enjoying the retro-looking pirate radio site I got sent to, so, thanks
It's a completely valid view, and none of it is backwards.
What's backwards is trying to bend a system barely capable of displaying static content to create apps.
So because some websites do shitty things, we should all throw out the standard way of displaying information on the web? Guide me through that line of reasoning. Why are newspaper websites, out of all the websites, the ones which should determine how we do things?
My point is that if there was any category of websites for which a "document" model would work, it would be newspaper websites. When even those take an "application" approach, it's time to admit that the "document" model is a failure.
News sites are meant to be read, therefore they are "documents." They are also applications, because all websites, even static ones, are also applications. Once you add hyperlinks and external resources, it ceases to be purely a document.
Adding a script tag to an HTML page doesn't transform it from one to the other.
I remember the older days (2005-8) when we would dump a load of HTML from the server-side and kept javascript (for the most part) managing the layout and, not to mention, coding the painful differences between browsers.. even IE6 to IE7.
As Javascript (likely thanks to jQuery for starters) got better with AJAX and supporting different browsers with less code, it seems Javascript transitioned to be a owner of data with events and triggers. As for the serverside, transitioned away from returning HTML but XML or the common Json data.
Away from jQuery (or alongside it) we ended up with Javascript frameworks leading to bindings or automated refresh of data with template views, etc. Things like mustache.js to knockoutjs to angularjs.
Now - its React, with node package managers, even grunt... to name a few... appear to be needed tools for web development these days. Its like we are just HIDING web development to an application. Underneath it all still remains the basics of HTML, CSS, Javascript -- and its relationship with the serverside language.
I will admit. In the early days of HTML development.. I hated it! Its not the HTML side of things, but the tools I had to use like Classic ASP or supporting different browsers. If we do web development today like its 2005... with modern programming languages and web browsers, "old school" web development is a joy.
In the last few years, I jumped back to the serverside generating the HTML again. I can still do "simple page" applications with AJAX returning a portion of HTML, etc.
When I explain this reasoning with other developers, I get a confused look on their face. I try to explain to them that the backend code has not changed. Its just an extra layer of returning the data back as HTML, rather than Json. It sounds like more but all it does it organise your HTML templates on the serverside, rather than just having it all done on the clientside.
Since then I have added htmx to the mix, which IMO compliments this original approach. I have made successful projects with it though I dont think I have won the co-workers. I dont think its because its the old school way or htmx -- its just they are so accustomed to the modern approach of web development.
This is what I always bring up to web devs who think theyve captured the "write once, run anywhere" dragon
I was on the mobile app side, as possible way to turn the balance around, but then everyone started shipping Cordova and Ionic apps.
We can complain how much we want, but the stream of shit, web-shit included, cannot be stopped or reversed. Brace yourself for more.
I hate to say it, but perhaps the browser needs a completely new standard designed for shipping applications? Something akin to what's discussed in the article - a simple but robust layout system built with a flexbox-like API and let us bind shaders to elements. We don't need css if we have shaders. And I don't think adding more and more features to current api's is gonna solve problems long term.
Flexbox also isn't great at all for many, many use cases - its performance absolutely tanks outside of the use case it was designed for, specifically a 1D flow of blocks along an axis. If you want a grid layout, choose the grid layout algorithm.
Any system here must accommodate extremely heterogeneous requirements, so it will inevitably become "bloat". One alternative future you could envision is based on WASM and WebGPU, where each site is essentially an app that pulls in whatever libraries and frameworks it needs to do its work, but that's also pretty far off, since there is not sufficient standardization of the protocols used by WASM UI frameworks.
Not only that, a new system will get completely coopted by the likes of Google for their own purposes. The result of what is built is in large parts a function of the culture that builds it. And I for one have zero interest in the current tech culture building a DOM 2.
Yes, I am generally weary of rewrites.
In all seriousness, isnt this what Java is for? Why would you need to treat a web browser like a virtual machine?
There are many reasons. Performance, ability to bring concepts from other domains, ability to do things browser has no api for, ability to provide controlled experience and behaviour that goes beyond common browser usage.
We can. Just every now and then some new way of working becomes popular, and at some point combining them with older ones will become undefined or unsupported.
He probably means will-change.
So maybe we can have <!DOCTYPE app>, which lets you use a new set of APIs focussed on applications, but is otherwise in the same "shape". JSX type syntax.
This way it's easy for say newspapers to offer both an app format as well as a "lite" document format. Instead of their current offering which is a app shoehorned into a document and then a messy lite version.
Users who use noscript can, instead of blocking scripts wholesale and then whitelisting the good ones, request by default the lite document format. i.e <!DOCTYPE html>.
We don't have to force a round peg into the square hole <!DOCTYPE html>. Let's make a new round hole <!DOCTYPE app> but keep using the amazing deployment platform.
edit: if you can program
It also makes the conversation about WASM even more bizarre. Most college educated developers are scared of the DOM. Yes, it’s fear the emotion and it’s completely irrational. Trust me on this as I have watched it as a prior full time JS dev for over 15 years. Developers are continuously trying to hide from the thing with layers of unnecessary abstractions and often don’t know why because they have invested so much energy in masking their irrational nonsense.
Other developers that have not embraced this nightmare of emotions just simply wish WASM would replace JS so they don’t have touch any of this. This is problematic because you don’t need anything to do with JS or the DOM to deploy WASM, but it’s a sandbox that ignores the containing web page, which is absolutely not a replacement. For WASM to become a replacement it would have to gain full DOM access to the containing page. Browser makers have refused to do that for clear security reasons.
So you get people investing their entire careers trying to hide from the DOM with unnecessary abstractions and then other developers that want bypass the nonsense by embracing that thing they don’t know they are yet afraid of it.
That is super fucking weird, but it makes for fun stories to nondevelopers that wonder why software is the way it is.
Because only javascript should be allowed to screw up that badly.
The entire point of frameworks like React is to avoid the problem, by automatically creating and applying the patch for you.
It's not irrational; quite the contrary.
Storing the diffs to local storage is an interesting idea though.
Another issue is people basing their fears of things in the past. Yes, the web was more difficult to do fancy things but often they're trying to push the web to do things it just couldn't do back then. Now you can using basic, built-in functionality and it's often easier that way.
To become a total replacement, as in no-JavaScript-at-all-needed, sure, WASM would need to be able to access the DOM. But to to replace JavaScript as the language you’re writing, you can easily generate DOM bindings so you trampoline via JavaScript, and people have been doing this for as long as WASM has been around.
Giving WASM direct DOM access does not enable anything new: it merely lets you slim down your JS bindings and potentially improve time or memory performance.
> Browser makers have refused to do that for clear security reasons.
Actually, they’re a long way down the path of doing it. They’ve just been taking their time to make sure it’s done right—they’ve headed in at least three different directions so far. But it’s been clear from just about the start that it was an eventual goal.
What is the point of WASM if it introduces substantially increased overhead instead of reduced? If you cannot talk to the DOM without full round tripping then you should just cross compile to JavaScript.
Very few people are "scared" of tree models.
The problem of working with the DOM is that it's:
- 90s JAVA-like verbose unwieldy API that requires tons of boilerplate to do the simplest things
- Extremely anemic API that is neither low-level enough to let you do your own stuff easily, nor high-level enough to just create what you need out of existing building blocks
- An API that is completely non-composable
- A rendering system that is actively getting in the way of doing things, and where you have to be acutely aware of all the hundreds of pitfalls and corner cases when you so much as change an element border (which may trigger a full re-layout of the entire page)
- A rendering system which is extremely non-performant for anything more complex than a static web page (and it barely manages to do even that). Any "amazing feats of performance" that people may demonstrate are either very carefully coded, use the exact same techniques as other toolkits (e.g. canvas or webgl), or are absolute table stakes for anything else under the sun. I mean, an frontpage article last week was how it needed 60% CPU and 25% GPU to animate three rectangles: https://www.granola.ai/blog/dont-animate-height
> So you get people investing their entire careers trying to hide from the DOM with unnecessary abstractions
The abstractions of the past 15 or so years have been trying to hide from the DOM only because the DOM is both extremely non-performant and has an API even a mother wouldn't love.
DOM access is not quite as fast now as it was 10 years ago. In Firefox I was getting just under a billion operations per second when perf testing on hardware with slow DDR3 memory. People with more modern hardware were getting closer to 5 billion ops/second. That isn’t slow.
Chrome has always been much slower. Back then I was getting closer to a max of 50 million ops/second perf testing the DOM. Now Chrome is about half that fast, but their string interpolation of query strings is about 10x faster.
The only real performance problem is the JS developer doing stupid shit.
1. These are not excuses, these are facts of life
2. No idea where you got vanity from
> DOM access is not quite as fast now as it was 10 years ago. I was getting just under a billion operations per second
Who said anything about DOM access?
> The only real performance problem is the JS developer doing stupid shit.
Ah yes. I didn't know that "animating a simple rectangle requires 60% CPU" is "developers doing stupid shit" and not DOM being slow because you could do meaningless "DOM access" billions time a second.
Please re-read what I wrote and make a good faith attempt to understand it. Overcome your bias and foregone conclusions.
If it was a result of a single very well thought through vision and developers were expected to be committed to conforming to the latest API (think Apple’s iOS runtime or the like), we could maybe expect the <thread> and <comment> tags, we could demand there to be The One Correct Way of doing anything, that the “fat” is trimmed quickly and features go from deprecated to gone in a year. However, it is a product designed by committee (in fact, by multitudes of various committees) that has largely maintained backwards compatibility for decades, it is a free runtime that grew organically from what was supposed to be a basic hyperlinked document layout engine but now powers fully dynamic applications rivaling their native equivalents yet still has a pretty low barrier to entry for new developers, and as such it’s remarkably robust.
Yes, some applications tend to have a large amount of markup for what seems like simple features (the Slack’s input box example). However, the alternative is that browser vendors bake it all in, and then every app is stuck with the opinionated way they think is right. Perhaps some amount of chaos is healthy.
Pretty easy, we should have had 2 standards, one being "Web for applications", built on a VM, stdlib, bytecode, RPC, UI framework and standard library of controls, ... And "Web for web pages" which was a solved problem pre-HTML5 days.
Java and Flash (although very problematic from a security point of view) were probably better bases on which to build "Web for applications" than HTML5+/CSS3+/JS/WASM will ever be, but it was intolerable for Google/Microsoft/Mozilla to hand the keys to Oracle/Adobe for that. It's all politics, and it's all worse and more complicated and more inefficient as a result.
Contrary to what was stated in the suggestion, it’s hardly a solved problem—improvements are being made at a steady pace (grids or { text-wrap: pretty } come to mind)—but it is interesting to imagine, especially if there were extra compelling reasons for engineers to restrict themselves to purer hypertext document API if possible (for example, it could be much more stable, while the app part could be unlocked to evolve more quickly but would be more demanding to developers keeping their webapps up-to-date; search engines could prioritize it; there could be hosting services specializing in it; and so on).
One counter-argument is that you can’t neatly separate the two and engineers will definitely want to use both; one way around it I can see is if hypertext document functionality was possible to use from within the webapp somehow, but I haven’t given it that much thought obviously.
That's essentially where the web was at before the HTML5 days: you could already go as fancy as you wanted, at the cost of pushing your users into a java/flash applet (and through longer loading times, high CPU/Memory requirements, …), and that clearly wasn't the norm.
Was Java any worse from a security point of view than what we have now?
The browser is really just a cross-platform platform for building applications.
There should be a singlular framework for creating desktop apps.
You'd never design from the start the bonkers HTML/CSS, box model, and other junk we are stuck with, but browsers have a number of good aspects that you'd probably end up with in a complete redesign.
The problem is multifaceted. UI toolkits are very hard to do well (I have a lot of opinions on this, and my own crossplatform toolkit), even on a single platform. Just that alone is huge. There are basically no overall great UI toolkits, even if some have good parts. Even a theoretical great UI toolkit will have quite a task to achieve parity with what browser UIs can do.
If we could get past that (spoiler: we can't, no way in hell) then we'd also have to be willing to ditch all the legacy browser stuff to switch billions of users and devices to something new AND we'd still have many other big problems to deal with: getting the committee/everyone to agree without ruining it, security, privacy, etc.
We've accepted we can't really fix it, so the only thing we can do is keep extending it. That's how we got here.
I’m sure the person you were referring to doesn’t want to make the web shit for the blind. Calm down
We already have similar sofware development patterns, but I wonder what a Web API surface would look like when fully embracing a similar modular mindset.
We have <!doctype html> but why not add other doc types as time goes on? Instead of shoehorning features you could have a <!doctype new-html> which would opt a web page into the ability to use newer features like newer elements or cleaner APIs
There is also the “use strict” directive in JS (which any script tag with type=“module” runs in now, slowly eliminating this need) that would opt your script into a stricter form of JS. You could even do it on a per function basis. We could have something like that for other features or stricter qualifiers etc.
We have done this before successfully and broadly, I think it’s time we revisit the usefulness of doing this again
Or, you know, provide a set of usable controls that provide useful functionality out of the box and provide a set of useful APIs so that people can either extend those controls or create their own.
Web Platform provides neither. Compare that to literally every other UI toolkit under the sun. Turbo Vision from 1990s was a better toolkit than anything the web has to offer.
...hell, native apps are still more likely to be crap than not. Good UIs are hard and programmers are lazy; the big advantage of web apps remains the difficulty of an app completely crashing the browser due to sheer developer apathy.
I’m not at all a frontend person, I just think flex is one of the best systems I have ever used. It usually gets the job done in a way that I expected to work (and that bar is pretty low lol)
<table width="100%" height="100%">
<tr>
<td colspan="2" height="50"> header </td>
</tr>
<tr>
<td width="200" valign="top"> sidebar </td>
<td valign="middle"> content </td>
</tr>
</table>I believe that some sort of a constraints language would've been a lot better at describing page layout. And stuff like Web applications simply shouldn't exist. These should be applications that use native UI toolkits while relying on Internet for moving data, not presentation.
Users are usually unhappy with Web applications because of the way browsers restrict useful functionality and programmers struggle with workarounds and bloat of browsers to accomplish simple things.
I AM SOLD
HTML5 input and form validation are still a broken nightmare that can barely be patched by adding copious amounts of JavaScript.
The browser should be doing most of the heavy lifting by providing a full suite of minimally themed but capable widgets that require little to no JavaScript and can be skinned entirely with CSS. That alone would wipe out an incredible amount of complexity and if done right would make web dev as an experience vastly more pleasant.
Still, it's quite sad how long we had to wait for stylable checkboxes.
The problem is that there aren’t even really any attempts out there. The closest as you say are web components, but they’re still extremely primitive relative to something like AppKit or win32.
My guess is that would put the burden of keeping up with evolving APIs on web developers and web companies. And there is a huge and very diverse ecosystem out there.
Native app developers seem to be burning resources trying to stay in stores and working on modern devices.
Staying in app stores in my experience has not been particularly difficult or resource intensive. If you stick to first party toolkits and don’t go nuts with custom widgets, maintenance is minimal and often you only need to compile against a newer SDK every few years. The horror stories are generally coming from projects with severe NIH syndrome and sometimes of users of cross platform frameworks.
Surely the "loose" standards encouraged neat hacks that at some point were encoded as best practices and then standardized. Maybe that would tempt us to want to "cut the cruft" but a) people probably thought that many times previously and b) backwards compatibility is probably more valuable than one would think.
I think that scale of "silent" users compared to proactive devs would be the most surprising number. Like for anyone who is "Rethinking DOM from first principles" there is probably like 10000s of randos editing ecommerce html templates, exporting results into tables and dataviz or making small uis for some internal system.
Yes it can. clip-path does just that.
In the real world though, backwards compatibility reigns supreme. Even if you do go and make a better thing, nobody will use it until it can do the vast majority of what the old thing did. Even then, switching is costly, so a huge chunk of people just won't. Now you have two systems to maintain and arguably an even bigger mess. See Win32 vs. WinRT vs. Windows App SDK or however many else there are now.
So if you're serious about improving big mature platforms, you need a very good plan for how you will handle the transition. Perhaps a new API with a compatibility layer on top is a good approach, but the compatibility layer has to have exactly 100% fidelity, and you can never get rid of it. At the scale of these platforms, that is extremely hard. Even at the end of the day, with a huge compatibility layer like that, have you really made a better and less bloated system? This is why we tend to just muddle along - as much as we all like to dream, it's probably actually the best approach.
I also think that if we could roll back time and had the knowledge of today, instead of fixed elements with user-agent styling and hard-coded restrictions, I would've crafted a system of arbitrary nodes that can have modifiers stacked on them.
So instead of
<ul> you could use <Features list>. This would minimize the very different but basically same CSS properties as well and trim out A LOT of HTML tags. Think <Comment collapsible link> instead of wrapping a <details> in an <a>.
That's basically how React and Vue started out with the component system, but I'm thinking more of a GameObject & Component system like with Unity.
This might in fact be a valuable insight, I never thought of it.
To this I say: go away and leave HTML alone if you want to build some application from first principles. The web's first principle is that HTML should have text. Hyper TEXT MARK-UP language.
Web devs have moved the state out of the document into JS variables and have been piling bloated, short-lived crap on top of those variables ever since.
If you actually keep state in the document things become rather simple. Scripts themselves become stateless and do not require direct dependencies on one another. Data can be queried across the page with CSS selectors. Many visual transformations on data can be handled in CSS as well. There is a well-developed system of events to handle interactions, which removes the need to handle user changes, AJAX and WebSockets separately. You gain the ability to dynamically examine and modify the state of your "application" simply by pressing F12 and changing things in the elements tab.
While it's definitely possible to imagine better ways of dealing with documents, layouts and so on, seeing how JS frameworks handle state makes me fear any "improvements" on this front.
<button i-was-clicked="false">
<button i-count-clicks>
It's like writing an entire diatribe about how it sucks that people can insult you online, and how that should change ... and not even mentioning the benefits of freedom of speech.
They'll make you a minister in the UK for that.
I don't think what the author is talking about is necessarily against either. HTML5 can continue its evolutions while "HTML6" (or something completely separate) exists alongside the traditional DOM, like the <canvas> example they reference or like WASM exists alongside JS. From this perspective, the article is about why it's a worthwhile time to make the new thing rather than why the new thing won't also have baggage in 20 years or why we should just throw everything current out the window as part of supporting the new thing.
That said, if you want a non-DOM framework, surprisingly Google already provides it. It's called Flutter and it has the option to use a canvas, no DOM. You can see a large complex example at
Go there and type in NYC. You'll see text and images popup over the earth, etc. You'll see a toolbar and menus and a status bar etc... Click settings. The stuff that appears is all canvas. Click the Data Layers icon. The stuff that appears as all canvas. I think they finally made the search input box an input element for the reasons above but the rest is canvas.
Also note that canvas based input is also why Google Docs has so much trouble with emoji and non-English input.
It's probably safe to say that the majority of the dev workforce in the last 2 decades started their career with learning HTML/JS/CSS stack, and it's understandable why they like it. It doesn't make this stack any better for creating apps, no matter how many abstractions on top we place.
It's true, what people think of as native on the web are merely incidental from its history, not some ironclad law of how to make interfaces.
It is so bad that one of the most impressive operating system features to be added in recent years is the ability to select and copy arbitrary text from app UIs, using either accessibility APIs or (more recently) straight-up OCR (because of course accessibility is another thing UI designers forget).
It's not like adding text selection in native apps is even hard; it's just not on the radar, and never has been. The number of old-school apps that added some form of "open log file" to either support instructions or as an actual function in the UI instead of making error messages selectable / copyable is depressing; I've seen programmers spend more time mocking end users for not knowing how to take proper screenshots than it would have taken to implement selectable UIs.
...and by historical accident, this problem is now solved in the vast majority of new applications. A small mercy!
It's far from the only thing it has issues with; I've found obviously broken UI patterns within a couple clicks of opening Earth's map view:
- right click doesn't appear to work anywhere (except input boxes), even on elements that have direct equivalents in other Google sites (like the account switcher),
- when you click the account switcher, as long as its open, the rest of the site ignores the mouse events; attempting to drag the map screen doesn't close the switcher, hovering over buttons doesn't change the cursor etc.
> right click doesn't appear to work anywhere
I hate this and it's the default for a canvas app since the app would have to implement doing something on right click where as in the browser it's the default. Unfortunately, an HTML app can disable right click too :(
In fact, I hate that issue on all native apps. Things I want to select/copy/lookup are not selectable/copyable/lookup-able. As an example, Sublime Merge, a native app, quite often I want to copy a path but there is no option to do so. Every place that displays a path would need custom code (or a shared control) to make the path copyable. HTML doesn't generally have this issue as it's opt-out not opt-in for being copyable.
I'm not a fan of Flutter or other canvas bases sites. Emoji didn't work for like 3 years in google docs after their canvas change. It works now but not always.
It's worse too in that it doesn't matter if flutter eventually fixes these issues. Every app needs to be update. That's not true with HTML where the browser updates to support "insert password into input type=password" and it just works. Even better, an extension (1 password) can insert the password but it can't on a canvas based app.
If finally WASM gets a cheap and easy way to manipulate DOM, I think even more stuff will move towards web tech like Electron and hopefully Tauri in the future.
That is to say, you aren't necessarily simplifying things. You are throwing away some of the things that somebody needs for what they do.
It may, in fact, be time to do this. I can't say. Odds are very high that you should, instead of throwing out some stakeholders as you try to shift something, you should invite the stakeholders you think you can more effectively serve to a new thing.
Alan Kay on web browsers, document viewers, Smalltalk, NeWS and HyperCard (2021) (donhopkins.medium.com)
234 points by gjvc on Jan 8, 2023 | hide | past | favorite | 272 comments
https://donhopkins.medium.com/alan-kay-on-should-web-browser...
Alan Kay on “Should web browsers have stuck to being document viewers?” and a discussion of Smalltalk, HyperCard, NeWS, and HyperLook
Alan Kay Wrote: Actually quite the opposite, if “document” means an imitation of old static text media (and later including pictures, and audio and video recordings).
It was being willing to settle for an overly simple text format and formatting scheme — “for convenience” — that started the web media architecture off in entirely the wrong direction (including the too simple reference scheme c.f. Doug Engelbart and Ted Nelson). Circa early 90s, it had the look and feel of an atavistic hack. I expected that Netscape would fix this rather than just try to dominate what was there (I expected a better architecture both for “thinking about media in the age of computing” and also something not like “an app” but more like an operating system to deal with the actual systems requirements, demands, and scalings of the world-wide Internet-in-progress).
[...]
Their API is probably the problem. Not modular so makes the mess.
Options to modularize them:
DOM, concept of interfaces/behaviors rather than inheritance leading to huge maps. Let say for <textarea> we may have separate "textarea" interface:
element.tagName
... and the rest of DOM-as-a-tree methods ...
element.textarea // <textarea> specific interface of its behavior
element.textarea.select(startEnd) // interface method
element.textarea.selectionStart // interface prop
element.textarea.selectionEnd // interface prop
element.textarea.rows // interface prop
element.textarea.columns // interface prop
...
section {
color: red;
// ... and other basic CSS 2.1 props
display: grid(
rows: ...;
columns: ...;
align-items: center;
justify-items: start
);
}
As sooner we will do that - the better. API is on the brink of collapsing / combinatorial explosion, indeed.
But you can’t fix that by adding new APIs with plenty of new concepts. You’re just making things larger and more complex. A few things may be able to live entirely inside the new, clean, modern API, but everything else (including practically everything that came before), will either need to ignore the new thing, or incorporate it (and pay the costs of bridging/composing things that weren’t necessarily designed to work together.
I say figure out how to actually remove old, bad stuff before adding a bunch of new stuff.
Also, didn’t they effectively invent rendering in canvas (for sheets) about 10 years ago? If they did that, but they still didn’t abandon the DOM, they might have their reasons.
lhmiles•17h ago