‘CSS X’
w3.org
w3.org
As I was reading through I was worried I was about to read an article about how some big company was going to recreate CSS from the ground up because there's too much cruft or something. A relief!
I live in fear reading through anything new in the frontend space.
Any further developments in this space needs to come full circle with web components. The WASM army have begun marching recently too.
The horror! The horror!
Where in the article does it say anything like that? The article does not present any decision in that regard at all. It summarizes the history of CSS and the discussion about whether or not to (re-)introduce some kind of global CSS versioning. It presents some suggestions and concerns from the community. But it does not introduce anything.
> , a precise definition of ‘CSS X’ isn’t even needed. Every three years of so, some people should pick a couple of interesting new modules that were added in that period and start writing about them, under the heading ‘CSS 4’, then ‘CSS 5’, etc. ‘CSS X’ is defined as those two or so modules, plus whatever was in the previous version and a loosely defined set of other modules.
I said "conceptual" because it's just some person's opinion about versioning, and the article does say the CSS working group doesn't really care for versioning at all. Either way, my opinion was that the article is about 95% too long, I'm making no other claims.
I mean, precise sizing, pixel perfect placement, layouts, etc, that can be printed as PDF pages.
I know there are print related media settings, but they seem overly complex and paid libraries have cropped up, which abstract away the complexity, but charge to provide usability.
HTML & CSS, conceptually, are world class technologies. Separation of content and styling, theoretically, should be able to display / output documents for a wide variety of targets. However, media queries are based on screen pixel sizes. I don't know if its even possible, but I would love to define media for PDF documents, Word documents, etc.
While we're on the subject of print, I am very jealous of the typographic controls that other platforms have. I get that more expensive text-justification algorithms wouldn't work for most apps, but especially for print, there are times that I don't really care about performance, and I would love to have an expensive text-justification algorithm and tools that rivaled something like LaTex.
As it stands, the prevailing advice about how to justify text on the web is, "don't".
I got pretty far! But I gave up working on it when I realized that I was going to be pushing this boulder uphill for years.
So what changed? I picked up Swift and SwiftUI, and it turns out that some of the ideas that I had were the same ones the SwiftUI folks went with!
For all the web has given us, I think its APIs are holding us back now. I still think we need something open and decentralized that competes with the App store and Play store, but one that offers apps that use basically the same APIs and technology that the native apps use.
Last thing: I know Apple cripples browsers on their platforms. I've run into all those issues personally in my work! That still doesn't make the web the right thing. Here's James Mickens telling us how to fix the browser's busted architecture: https://www.youtube.com/watch?v=1uflg7LDmzI
I can put a div in a div, border-radius=50%, position=relative,absolute, add a single event handler and that's a digital joystick. Run a local single-exe websocketify and you can control anything from a CNC router to an army of drones.
I dislike Electron* as much as the next guy and steer clear of npm like my life depends on it, but there's no single thing that's more universal and easy to hack on than a simple HTML file.
Are you implying that this is somehow unique to the web or HTML? Because I can assure you that it is not.
We've got a handful of basic form inputs, incredibly inflexible tables, and some semantic rectangles. That's basically it.
Even the form inputs can be a pain. It's insane to me that the only way to change the background colour of a checkbox is to hide it and build your own with CSS hacks (pseudo-elements etc.).
I guess the fact that any element needs to function purely from markup without any code severely hampers them, but I can't believe how much time we're all wasting having to build things as basic as pop-out menus by hand.
I will die on this hill. HTML is not a UI toolkit or an SDK. It is a user-facing interface.
I know it gets presented as a toolkit, I know that on some level it overlaps with a toolkit/layout language. But the most important thing HTML does is it provides a plain-text user-facing interface for an app.
Complaints like this are kind of like arguing that the terminal is a bad layout tool. I guess? But many of the things that would make the terminal into a better layout tool would get in the way of forcing developers to provide a pure-text interface for their apps.
In the same way, many of the features people want to pull into HTML (data-bindings for tables, content reflow between arbitrary elements, arguably a lot of the custom element/template work that Google is doing) are kind of counterproductive once you start looking at HTML as an interface instead of as a programming tool.
It’s not fit for the purpose of building applications. I strongly support the idea of an alternative.
No, you have to treat it like a render target. You can write your applications with another UI toolkit, you just have to be able to render to DOM.
To go back to the terminal analogy, the terminal is the end-user interface. It's not a framework or a toolkit. What you're complaining about isn't that the terminal is a bad UI toolkit, you're just complaining about supporting the terminal in general.
> I strongly support the idea of an alternative.
The only way that alternative would be easier to work with is if it didn't force you to render your visual state to a pure-text XML-based UI. But getting rid of that requirement would be bad for the end user.
It's annoying on purpose, because the default render target for not just your documents, but also your applications, should mostly be a pure-text XML-based tree representing your current state. It's a user feature, not a developer feature.
I mean, I can think of a lot of ways to make web programming easier if we don't care about the format of the end-user UI. It would simplify things dramatically if we didn't need to care about stuff like responsive design or resizable text. But the beauty of HTML is that by default, the easiest way to build a web application just happens to be the way that supports screenreaders, adblockers, scraping, graceful degradation, responsive layouts, etc...
HTML encourages even junior developers to fall into a pit of success by forcing them to think about the accessible text interface first, before they're allowed to think about what the pixels on the screen will look like.
If I wanted to write something like a high quality drawing tool and my only option was to use the terminal, you’re damn right I would be complaining about it.
Now I understand saying “my only option” is somewhat facetious, as if I care about it so deeply, obviously I should just write native software. But we are clearly moving to a web-first future, and I just don’t think the platform is a good foundation for application UI.
You’re implying that there’s ultimately no difference between a UI library that renders to HTML and one that renders to a grid of pixels in a native app; I am making the argument that HTML is sufficiently poorly suited for non-document purposes that it drags the overall quality of software down.
> The only way that alternative would be easier to work with is if it didn't force you to render your visual state to a pure-text XML-based UI
That is exactly what I’m suggesting.
> It's annoying on purpose, because the default render target for not just your documents, but also your applications, should mostly be a pure-text XML-based tree representing your current state
Why? I am not convinced there are significant benefits to a text-based format over a binary one, other than ease of reverse engineering. I would also argue that HTML doesn’t represent your current state, it represents the state when the page loads. That state is then modified, often in a rather opaque manner, by JavaScript. If we’re going to stick with something text based, clear data binding as part of the markup would be much more beneficial imo. Again: I feel the principle holds just fine for documents, but not application UI.
> But the beauty of HTML is that by default, the easiest way to build a web application just happens to be the way that supports screenreaders, adblockers, scraping, graceful degradation, responsive layouts, etc
It’s the easiest way to build a web app because it’s the only way to build a web app. And while I will grant you that scraping and adblocking is fairly unique to the web, any “native” UI target worth its salt has great accessibility support. As for responsive layout, how long have we had resizable windows where the contents adapt? This is not something the web pioneered.
> HTML encourages even junior developers to fall into a pit of success by forcing them to think about the accessible text interface first
I guarantee you that junior developers are not writing accessible web apps without significant effort. Maybe if they start off with something fairly document-like, sure. But once you start adding modals, popovers, and other controls that the browser doesn’t provide, things get difficult to do right pretty quickly.
Canvas isn't the default because most apps don't need that escape hatch -- I will make a strong claim that the majority of native apps are just interactive documents and could easily represent their states in XML. I will make a stronger claim that the majority of native apps that require pixel-level control workarounds only need them for a couple of sections of the app, and the surrounding interface is just an interactive document. If you're building a drawing app, yes, you need an pixel buffer that you can render to. But the rest of your menus and main interface are probably just XML.
This is another hill I'm willing to die on; application UI isn't special. Yes, having some control over stuff like Canvas is important. And there are categories of apps like games that genuinely don't fit into a document model. But for the most part people should be able to represent their state as a plain-text interface, it's kind of weird to me if they can't. For the most part, most application UI state is not that complicated.
> I would also argue that HTML doesn’t represent your current state, it represents the state when the page loads. That state is then modified, often in a rather opaque manner, by JavaScript.
The Javascript is not important. When that state gets modified, it gets rendered to the DOM. The idea behind the web, even for web-apps, is that if you open the inspector in your browser, that should be the current user-facing state at that specific moment.
> Why? I am not convinced there are significant benefits to a text-based format over a binary one other than ease of reverse engineering
The only way a screenreader works is by reading your interface out loud. If your interface can't be entirely represented as a series of words, then how are you making it accessible?
The browser forcing you to target text (Canvas aside) is important because it means the text interface and visual interface can't be separated. That makes it harder for you to split your app into two separate interfaces that might diverge in features and abilities. By default, the functionality you offer is available to everyone, even users who aren't consuming your app using the visual interface.
As a side note, I think ease of reverse engineering is a big deal that shouldn't be discounted. We should be trying to make it easier to reverse engineer native apps.
> how long have we had resizable windows where the contents adapt?
Then why haven't native developers found out how to do it yet? Why do all of the Linux apps I run have terrible HDPI support? Why has it taken us so long to get something incredibly simple and straightforward like fractional scaling working on the Linux desktop?
> But once you start adding modals, popovers, and other controls that the browser doesn’t provide, things get difficult to do right pretty quickly.
Well... use a framework for that. Use a React modal, they'll be accessible. The point I've been getting at is that you shouldn't think of HTML as the thing you write your app in, you should think of HTML/DOM as the thing your app renders to. It's fine to use a UI toolkit on top of that, in the same way that it's fine to use a framework that runs on top of something like X11.
The browser doesn't provide popovers and modals for the same reason that OpenGL doesn't provide those things. Browser elements are primitives, they just happen to be easy enough to use that you could theoretically target them directly. Junior developers don't need to write advanced popovers, and the goal isn't to force them to do that. It's to provide a common set of user-accessible elements that advanced popovers are built out of, regardless of what UI toolkit you're using.
> The idea behind the web, even for web-apps, is that if you open the inspector in your browser, that should be the current user-facing state at that specific moment.
There's absolutely nothing there that requires UI to be delivered as a textual XML tree to work. The browser will end up rendering a tree of nodes regardless of its representation, and there's no reason that can't be inspected. For example, in Xcode I can pause execution of an iOS app and poke around the view stack to see what's going on.
> The only way a screenreader works is by reading your interface out loud. If your interface can't be entirely represented as a series of words, then how are you making it accessible?
As above. I'm not suggesting we render text by blasting pixels into a bitmap; with this imaginary alternative to HTML we would still tell the browser to render some text, which can then expose the necessary accessibility hooks. Again look to iOS; it has arguably best-in-class accessibility support.
> That makes it harder for you to split your app into two separate interfaces that might diverge in features and abilities. By default, the functionality you offer is available to everyone, even users who aren't consuming your app using the visual interface.
If I'm honest I'm not sure what you mean here, can you clarify?
> As a side note, I think ease of reverse engineering is a big deal that shouldn't be discounted. We should be trying to make it easier to reverse engineer native apps.
Agreed.
> Then why haven't native developers found out how to do it yet? Why do all of the Linux apps I run have terrible HDPI support? Why has it taken us so long to get something incredibly simple and straightforward like fractional scaling working on the Linux desktop?
¯\_(ツ)_/¯ Lack of interest? Lack of commercial incentive? HiDPI works flawlessly on macOS and has for years. Not to mention that the web doesn't really fix that problem. If the browser was poorly written and had bad HiDPI support, then so would all your web apps.
> The point I've been getting at is that you shouldn't think of HTML as the thing you write your app in, you should think of HTML/DOM as the thing your app renders to
Okay, I'm really not disagreeing with you here. My argument is that HTML/DOM as a render target is annoyingly limited in many small ways that waste developer time and create a worse overall product.
> The browser doesn't provide popovers and modals for the same reason that OpenGL doesn't provide those things. Browser elements are primitives, they just happen to be easy enough to use that you could theoretically target them directly
I don't think this argument stands up at all. Does OpenGL provide form inputs? Buttons? Semantic content regions? The crux of my argument is that HTML elements are neither primitive nor flexible enough to be a good basis for UI frameworks, nor rich enough to not require UI toolkits. It's stuck in between, which is why I called it a lame UI toolkit to begin with.
I fear you may think I'm arguing in favour of something I'm not. I don't think we should be replacing web apps with a big list of drawing instructions, I'm merely saying there are a lot of things that have been par for the course in GUIs for 20-30 years that are significantly harder than they should be to achieve with HTML+CSS. I mean hell, I don't really care if some alternative platform is text-based or not, I just think text has minimal benefits and binary would be more efficient.
Well, wait, how much do we disagree here?
When I talk about HTML, the tree representation is the part I care about. I'm not delivering new HTML documents for every change when I write an app, I'm using something like JSX, or Hyperscript, or even in a pinch the core DOM manipulation libraries. I can still define my interface inside JS, and in the future once the bindings get set up I'll be able to define it using WASM in any language.
> I'm not sure what you mean here, can you clarify?
If an app has an accessible view and a visual view, it's possible for the features that each "version" supports to diverge. Blind users will often be given a lower quality alternative as an afterthought rather than a full-featured application.
By forcing the visual representation of the app to be based on top of the accessible (text-based) representation of the app, we can (mostly) force the two experiences to be the same. Escape hatches aside, the developer can't neglect the accessible interface, because adding features to the accessible interface is the only way to get them into the visual interface.
> Not to mention that the web doesn't really fix that problem. If the browser was poorly written and had bad HiDPI support, then so would all your web apps.
Doesn't it? It's not that the browser is scaling the web page, it's that CSS by default handles HDPI and reflow properly. Any browser that implements CSS properly will have good HDPI support, the spec is good at scaling and handling content reflow at its core.
When I call out Linux, I'm specifically calling out the idea that we needed a special Gnome mode that rendered our applications to a separate buffer, resized that buffer, and then printed it to the screen. To me, that means the GUI toolkits these apps were based on aren't being used in a way that can handle multiple font sizes, device orientations, input methods.
> I fear you may think I'm arguing in favour of something I'm not.
Maybe I do?
You bring up Swift UI, but Swift UI is a declarative, tree-based user interface that's accessible by default. Part of the reason accessibility works on iOS is because of the design patterns that I'm talking about above; design patterns that came from the web.
Swift exposes a set of common semantic components that developers are forced to use, those components have common controls built into all of them like standard ways to adjust sliders. And what limited styling options that Swift offers look a heck of lot like CSS -- just a bit more limited and managed through attributes. I'm immediately reminded of something like D3 when I look at example Swift UI code.
So when you look at Swift's declarative UI vs something like the DOM/CSS, what's the core difference that you see? What's the thing that you wish the DOM was copying from Swift?
To me, the big difference between Swift and the DOM is just the abstraction level. Swift's declarative UI is a higher-level framework that forces more visual consistency and provides more high-level tools, at the cost of being much less customizable. But one of the big ideas behind systems like React and Components is that you can write interfaces using high-level components that conform to a specific style guide -- you don't have to work directly with divs.
So if the problem just boils down to "HTML should have more high-level components like modals and popups", that's something that we try to handle in userspace, because (frankly) the web has a much wider reach and platform support than Swift does, and standardization of how everything looks and acts is a harder problem to solve on the web for high-level components than it is on iOS.
That being said, the tree-based, semantic, final interface is the part of HTML I care about. If someone thinks we can do better, and they think there are better primitives we could expose, I'm not opposed to that. I don't think HTML is perfect, and I certainly don't think CSS is perfect.
If the disagreement boils down to that, then... I dunno, maybe there's not as much disagreement then. Typically when I talk to people about this, they are arguing that we should be replacing web apps with drawing instructions. Look at the linked talk from maxharris you originally applied to -- it's explicitly talking about getting rid of a standardized, semantic tree-based text representation of the current state and handling interfaces by pushing pixel buffers.
But it kind of sounds like that's not what you want, it seems like you want a different set of HTML tags and a different document reflow model in CSS? If so, that's a position that I'm much more sympathetic towards, even if I would want to hear more details before jumping on board.
...sincere question, have you ever actually used a native UI SDK?
Now, I have not used Flutter in specific, but from what I can see from its documentation, it doesn't support `em` units, so I can't base widths off of the current font size. The recommendations I'm seeing online for doing responsive design are to do device queries for the layout or to do percentage-based box sizes.
Again, I haven't used Flutter, so maybe it's better than the online tutorials I'm looking at give the impression of. But I'm having a real hard time imagining how I would recreate the functionality of CSS Grids or Flexbox using that kind of system.
Some native frameworks do a much better job. I think GTK is pretty good (although, suspiciously, GTK has ended up copying a lot of CSS features, so take from that what you will). But even there, it's worth noting that the developers behind most of the apps I'm familiar with aren't really taking advantage of modern GTK features.
I have an Arch install with the desktop split between a 4K monitor and a normal 1920x1080. I also maintain a Manjaro install on an HDPI Surface laptop with an odd aspect ratio. By and large, the native apps I use are mostly terrible at handling these scenarios. In comparison, most websites I visit are handling weird aspect ratios and 2x scaling pretty well.
I'll also give a shoutout to Mac, which I'm not familiar with a developer platform because heck that, but I assume has decent UI frameworks because more of the apps I use on Mac actually handle resizing nicely.
In any case, the point I was making was not just that the web is uniquely good at responsive design. Responsive design is one of the easiest problems that the web is solving. Now show me a native toolkit that can match the web at allowing users to override styles or block/replace UI elements. The significant problem that the web is solving is forcing state to be represented in an XML tree. That's the important part, responsive design is just one of the advantages that come from that.
Can't you just use the fontSize property and multiply it by whatever number you were going to use for ems (or maybe multiply fontSize by textScaleFactor first, depending on how rigorously you want to lock to text.)
But it would be a weird argument to say that Flutter represents an evolution over CSS if right from the start I'm being forced to manually reinvent a core UI primitive.
Take a look at Flutter(which is similar to swiftUI). I know Google is behind it but it's so damn good. The JS community spends so much time creating new tools on top of older tools to achieve simple things that should be trivial in 2020. Meanwhile, flutter is typescript+react+webpack+component library + a bunch of npm dependencies(because dart has a proper standard library) + advanced styling/layout and animation primitives inside the programming language + amazing IDE support + compiler that generates optimized AOT native code.
Flutter Web is a huge bet though because it completely throws away every web tech and builds UIs on top of <canvas>. That way you get the same API's you get on mobiles. The results are not good right now but alongside Microsoft's Blazor they are the only technologies competing with the broken web landscape.
Now the CSS progress is more driven by the browsers than the W3C committee. Also, CSS does not affect the competition between browsers as much as before. So, as the flashy tech gets stable and boring, the need to give it marketable names goes away.
Meanwhile, that W3C logo is sporting a radial gradient + inner shadow + drop shadow combination straight out of 2004!