The trouble with allowing a procedural language for styling is that all you can do with it is run it. PostScript and PDF work that way, which is why doing anything other than printing those formats,is very tough. Copying text from PDF barely works. It's an output-only format.
I wanted a constraint-type system. A is above B, B is to the left of C, D is below A and B. Something like that. All declarative, handled by a constraint solver. Any serious parametric CAD system has that. Usually with more features than you need for web layout, like the ability to handle curves.
Funnily enough Apple's UI toolkits (both macOS's AppKit and iOS's UIKit) use Cassowary constraint solvers under the hood. There was also a startup a while back (The Grid, I think?) that was trying to use it as the basis of a web design platform. No clue if they ever shipped anything but I remember seeing their source release for the constraint solver and thinking, "Man, if calculating layout in JavaScript wasn't a total jankfest for end-users I'd totally use this".
Cassowary was suggested to w3c in 1999 IIRC, but was rejected. Even though the concerns are understandable at the time (processing requirements), it's still a sad development.
I guess you're talking about GSS, which works fine, but I haven't seen any mention of it on the internets until this. What bugs me most is that we're stuck with what browsers provide, and they not gonna do display: cassowary; or display: kiwi; no matter how loud you cry for something a little more sane than a bunch of css crutches glued together.
Oh, that looks so promising that just glancing over that page and seeing a request/allocate cycle felt like a breath of fresh air (well, good old fresh). Thanks for sharing!
That makes sense for GUI systems. If you have lots of elements with alignment constraints, a constraint solver is the right tool for the job. 20 years ago, they were obscure pieces of software, though, and rather alien to people who were thinking "word processor".
280 North did this with Cappuccino and their Atlas tool (which has unfortunately been swallowed up and forgotten after the company was acquired by Motorola).
Alan Kay always said the web should be rendered by itself, but it seems like it would have been a terrible idea. The transition to tablets using alternate widgets (for selection boxes, etc.), gpu acceleration, and many other things would have been way harder to shoehorn in in something that was rasterizing itself.
Not quite. Flash and Shockwave were centrally controlled systems. What Kay probably had in mind, as you can read in Personal Dynamic Media, is all the GUI object frantically sending messages back and forth and aligning themselves.
You still see that now and then, with things like chat bubbles in 3D worlds maneuvering themselves to get clear of other chat bubbles and such as viewpoints change and characters move. But for more static general layout, no.
there are definitely positives about html and being declarative for sure...at least in the beginning... but looking at the complex beasts that web browsers have become now (maintaining/optimizing js, decades of backwards compatibility etc) it seems in the end, only google and apple can fund them (microsoft throwing in the towel, mozillas recent cutbacks)... im not sure this is what we originally wanted from the web...
as you say though, self rendering pages would need an api to provide accessibility, and also html is much easier to grok than bytecodes (developer accessibility)
Funny you mention that. I'm currently in the process of creating a declarative language specifically for UI designers. The goal is to let them describe interfaces in a platform-agnostic pseudo-ish code, and it's all based on parametric constraints exactly as you described.
> When HTML was announced by Tim Berners-Lee in 1991 there was no method of styling pages. How given HTML tags were rendered was determined by the browser, often with significant input from the user’s preferences.
I almost wished we still lived in this world, where the web pages provides the structure and data, and I as the user get to decide how I want to consume it.
I think trying to cram web applications into the same model as distributed, hyperlinked documents was fundamentally a mistake.
If a browser was just about rendering html, a significant amount of complexity would have disappeared, and you would have a multitude of different browsers, all catering to different preferences in how you wanted to consume html. It is due in large part to the complexity, that we are going towards to monoculture of Chromium/Blink, because only companies with billions of cash in the bank, can afford to dedicate the teams needed to develop a web browser.
>If a browser was just about rendering html, a significant amount of complexity would have disappeared
I don't think this is the right conclusion. I think HTML/rendering engines as described there would have been the thing to disappear. With the smooth user experience of apps & SPAs, a platform with comparable semantics to your nerfed HTML but significantly suped up interactivity features (like not-nerfed HTML) would be all the rage.
Plus, I must say, as a web dev, the public-facing web doesn't really do great justice to what you can do with a browser. There's so many internal tools that are super slick, fast loading, bug-free, rendering complex topics like graphs & workflows in attractive yet interactive ways while also supporting client-side validations & computations, all delivered in HTML/CSS/JS. This really isn't a trivial accomplishment, this was driven by the work of many many engineers writing many different tools with increasing complexity, both on the browser and open source sides.
The march of this progress wouldn't have stopped just because HTML didn't support it, it would've just replaced HTML.
The way things were in the early days is if you wanted rich interactivity you used Flash, or a Java applet. The rather standard and boring 'web page' still hosted it, but the rich features were to be provided by the applet/plugin.
This was both worse and better. Better because it retained the notion of the web as a hypertext system -- not a networked magazine or TV -- worse because what happened in that (usually poorly implemented) little box was its own world outside of the rest of the page.
I don't like the present web stack, but I don't have any particular fondness for the mid-90s one I worked on, either.
To be honest, I perceive the main problems with the present web stack to not be on the consuming developer's end - writing JSX & CSS is honestly a pretty decent representation of what HTML/CSS/JS can actually combine to be. Plus modern JS is a half-decent language, even more so when TypeScript is used.
I perceive the main problem to be how hard it is on the implementing developer's side - only megacorps can make functional web browsers. That's a huge problem.
I absolutely disagree that apps and spas would destroy nerfed HTML, in your example.
The web moved in those directions for a multitude of reasons, but user experience isnt necessarily one of them. Server side rendering and a miniscule amount of js can give a great fast experience, and doesn't require the site to use a proprietary layout toolkit. An HTML SSA app, where the user controlled the UI toolkit in browser would be pleasant and easier to develop.
What you're describing existed. It was called plugins. Back in the Old DaysTM, browsers just rendered documents, and if you wanted whiz-bang interactivity features, you ponied up for a copy of Macromedia Flash. Or Director, if you wanted more features and could tolerate it's long plugin download times. Or, if you were more developer-minded, you wrote Java Applets (or, later on, Silverlight apps).
Things like Flash didn't ultimately supplant the web, but this is primarily due to three forces:
1. Adobe's insistence on new Player features over security
2. Google's insistence on adding new features to HTML5 via Chrome to support internal business goals
3. Apple's insistence on killing plugins dead to keep the iPhone secure (and cut Adobe out of the developer tools market)
The only vestige of plugins that remains are EME implementations (so-called "HTML5 DRM"), but that's purely due to legal reasons.
Had HTML not grown to supplant the use cases of plugins, I think it would have stuck around, if only because all those plugins required significant expense to make use of. I doubt Adobe would have, say, tried to make a web browser in Flash just to cut the HTML middleman out.
Documents web works fine without javascript. There are a lot of browsers - NetSurf, Dillo, console browsers, discontinued open source DOS browsers [3], ed browser [4].
Monoculture stems from the convenience of having both document browser and application platform in one application.
> by ViolaWWW, a graphical browser originally written by Pei-Yuan Wei in just four days.
The simplest (non graphical) browser I can write in just a few minutes
Complexity grows from here - collect links to make it interactive, graphical text, images, tables, forms. Add constraints solver, data extraction tools, query RDF, etc.
Yes, in the beginning the idea was that the browser would be responsible for rendering pages nicely. So you could render them in high quality, like current desktop engines, or very quickly in a mobile environment. But of course, publishers didn't like the loss of control. And now we're stuck with a complex tangle of technologies that keep getting out of control.
That’d work great for many sites, but you’d lose a lot of the dynamism that makes the web so great.
I think a compromise solution would be to extend the ADA to cover websites, so companies have to produce sites that can be understood by screen readers and other assistive devices. That would more or less give you the outcome you want, but without the need for a prescriptive solution.
Technically, there is a native SGML mechanism called link process declaration (without DSSSL) for assigning style properties to document markup. Looks as follows:
<!DOCTYPE html [
<!-- ... declarations
for HTML elements,
attributes ... -->
]>
<!LINKTYPE render
html #IMPLIED [
<!ATTLIST a color
(blue|red) #IMPLIED>
<!LINK #INITIAL
a [ color=blue ]>
]>
<html>
<title>Blue link</title>
<p>this <a href=x.html>
link</a> is rendered
in blue color</p>
</html>
Beyond this trivial example, style properties (link attributes) can be assigned in a context-dependent way for eg even/odd pages in print, or actually capture the largest part of CSS selectors (sans pseudo-attributes such as :hover though which are "magical" in CSS).
I always wondered why people believed we need a distinct property universe for CSS properties when regular HTML attributes are there for this exact purpose (in link processes, attributes reuse regular content attribute declaration syntax).
> Particularly in the early days of the Internet, it was considered critically important that the page be renderable before the document has been fully loaded. In other words, we want to be able to render the beginning of the HTML to the page before the HTML which will form the bottom of the page has been fully downloaded.
It's ironic that nowadays lots of sites completely ignore this guideline and force you to wait several seconds for webfonts/CSS/JS to load before the page is readable at all. We have much faster download speeds now, but this hasn't always translated into proportionately faster perceptual speeds.
It's a shame if this is the reason DSSSL was rejected, because DSSSL looks more elegant than CSS other than this issue.
This is partly a problem with the design trends. There have been an aversion to have a “Flash Of Unstyled Content / Text” (FOUC / FOUT) in designs, especially since the time when image replacements went out of time and dynamic solutions like sIFR and similar techniques to style headers emerged. Now we have the same with web fonts, we prevent display until the right font I loaded. It’s very bad for UX.
> If CSS was designed the way it is just to satisfy the constraints of 1996, then maybe that gives us permission 20 years later to do things a little differently.
Yeah, just like we can choose which side of the road to drive on or pick any arbitrary character encoding for an 8-bit byte.
Driving on one side of the road offers no obvious benefits compared to driving on the other side of the road whereas getting rid of HTML and CSS offers obvious benefits and is long overdue.
Everybody talks about replacing CSS, yet nobody comes up with a feasible solution.
Layouting is hard. Very hard.
I mean, there's a reason why ooxml or docx are so similar to CSS, and why PDF is so broken that it's a candy store for exploits.
Both object and functional oriented replacements always have led to a lot of redundancy compared to their compiled CSS equivalents. And usually you cannot model layouts as flexible as with CSS' different flow models.
Everybody that says CSS can be replaced with something simple usually hasn't even thought of print stylesheets, media queries, or why the box model and flow model got so complicated.
The spec authors had very good reasons to make changes to the CSS spec(s).
Layouting is hard only from a css perspective. We used TFrames and tAligns in delphi, we used (sane!) boxing in gtk, we used apple's constraint system. Entire operating systems and business packs were built exclusively on these for decades. And nothing was as hard as making damn css work on three devices without an explicit role or two to manage that.
Alternative is a king. Leave your css if you like it, but please make it an intermediate layer, not final, and allow more sane primitives on which people could build their ui. People are sick and tired of translating geometric ui layout to allegedly-text layout, when there is not a single character of text until fifteenth level of divs.
Edit: it is not "css as format" that is broken, if that was not clear. Broken is a set of primitives under "display" property.
Any given layout is pretty easy to work. The problem is the sheer number of form factors, flexible resizing, and rendering methods (as you mentioned, print vs AMOLED vs monitors) that make designers and engineers cry.
When I talk to designers, they love love love paper for many reasons, but one of them is the total control they have over the medium and the fact that they only have to deal with one fixed form factor at a time.
Maybe instead of having stylesheets for print and media queries, different versions are just written for each?
I've wondered this about a11y in HTML too. Instead of trying to torment the browser into understanding how a11y should work with a bunch of ARIA properties, what if a simple alternative was offered which was easier to understand for a11y but not for 'normal' users?
ARIA properties are really just the escape hatch. For the most part, people shouldn't be using them except to fill in gaps.
Semantic HTML is the simple alternative. And the reason HTML has worked for accessibility overall is because it forces developers to use the accessible interface.
Compare that with image/video captions/descriptions, where most devs just don't do it. If you have a programming setup where the accessible and visual parts of your interface are two separate things, then by and large you will usually only get software with a visual interface.
The terminal is another good example of this. It turns out that forcing developers to code an interface that can reduce to pure text has some advantages for accessibility, extensibility, and portability.
Those suggestions would probably be better if everyone building a website had infinite man power. But in the real world adoption is going to suffer if you have to make a separate document for web, print, a11y, etc. Then someone will say "Why don't we have a unified markup language that we can use to produce each of these documents for us?" And then XSLT will be invented. And what a mess we've made.
But if people are already putting in extra effort to get these features working in their unified markup language, then it isn't different (from the perspective of effort) to write separate versions. In fact, it might be easier, because at that point you're working in a language custom designed for the task at hand, not trying to shoe horn a spoken-word UI into a visual UI language.
Don't say this. The quotes don't make it any better - this is like outright discrimination to consider that people who need a well designed website are not normal. Every user of your product is a "normal user".
Remember that people's ability doesn't exist at two extremes - Just take eyesight. It is just a fact that people's eyesight starts to deteriorate, especially as you get older. This is incredibly normal, and just because you've gotten a bit older and can't see like a 12 year old doesn't mean you deserve a segregated web experience.
Gtk does use css, but not for the purpose of layout. Their layout rests on the same good, understandable and no-bullshit primitives (GtkContainer subtree) as before the time css-like theming was introduced. Gtk css solved a problem of theme engines (clearlooks, redmond, etc) which had to be done at low-level and thus were less easy to create or modify.
What I honestly didn't understand is why CSS and HTML don't have ui specific namespaces by default that could offer alternatives to div elements that would not be influenced by user agent stylesheets.
I think this was the primary idea behind xhtml back then (when looking at xforms et al) but somehow got lost into some weird hacks to make everything "somehow" run on IE.
Now we have ui and semantics in the same namespace (section, aside, dialog, main, article, footer, header et al) and everybody is just more confused. How should I use dialog, for example? No matter how code turns out, it's always a crappy JS based solution.
To be honest, I love the idea of web components, but I hate that there's no JS free deserialization from html to dom possible.
If you create a solution to advance the semantics of SGML, it's an architecture fail to implement it without the semantic aspects HTML and CSS were designed for.
> Driving on one side of the road offers no obvious benefits compared to driving on the other side
If that were true, then why did Sweden go to the trouble to change in 1967?
The fact that they did so, and that doing so was to improve interoperability with neighboring systems, might give you some clue why getting rid of CSS and HTML requires more than mere 'obvious benefits' to justify it.
You’re being deliberately obtuse. Driving on some side of the road offers no benefit, other than historical concerns arising from one’s neighbors decisions, and likewise with CSS. I’m sure you were aware of this and I’m not sure why you bothered to raise such a pedantic and worthless point.
My experience is that people who tend to disparage web tech don't have much experience building clients in general, so they think building web clients is hard and annoying because it's the web without realizing it's because it's a client.
"My experience is that people who tend to disparage web tech don't have much experience building clients in general"
My mom should be able to build great frontends for Web software, but currently the technology requires her to know much more than she knows. As you say, she "don't have much experience building clients in general." Therefore it's important that we get rid of HTML, CSS, and Javascript.
This is an old debate, but to repeat the highlights:
The benefit would be the productivity gained from specialization. The work could be moved away from computer programmers. Beginners would find beginning as easy as building a HyperCard stack, and specialist UI/UX experts (not computer programmers) could be put in charge of advanced frontends.
The same argument that was made for Web Assembly also applies to the frontend: we now know what we need as a general compilation layer for frontend descriptive languages, things we did not know in 1996 when HTML/CSS/Javascript were coming together.
The crucial thing is to have the kind of serialization formats that software can write, thus opening the door to a version of Dreamweaver that actually works. In other words, something like Adobe InDesign would then be the correct way to create all frontends. I wrote about this in detail here:
HyperCard, Dreamweaver, InDesign, Photoshop, Flash and Illustrator do not use a markup language internally. As with Web Assembly, it's important we have the right primitive that we can compile to. There are configuration languages that can make it easy for beginners to hand edit a frontend, and in my article I mention the configs that Ruby On Rails, Symfony (PHP), and Django (Python) offer to generate simple CRUD interfaces, and I mention that these configs could be much more powerful if they had the correct primitive to compile against, rather rendering to HTML/CSS.
Aside from all that, I would raise the more urgent question for our industry, why did it seem like such an urgent task, all through the 1980s, 1990s, and early 00s, to create visual software that would make it easy for beginners to create software, and yet now this is no longer a priority? Is there some reason why we are moving away from the era when "Empower the masses to create software" seemed like an important goal for the industry?
You can't version control whatever binary format InDesign uses. Markup languages benefit from precision, readability from an editor, easy integration with other tools.
HTML and CSS have been evolving for over two decades (now maybe faster than ever) and have been battle tested by nearly 2 billion websites.
It seems crazy to me to think that we should throw it all out and do something new. I suspect contributing to the improvement of the existing spec is a much more pragmatic endeavor.
I keep wondering how I can Man-in-the-High-Castle my way back to the timeline where Scheme replaces HTML, Javascript, and CSS. Also where Al Gore wins the 2000 election.
Am I the only one, who finds it deeply ironic, that increasingly many modern websites are primarily designed for small screens, effectively giving up on designing for large screens? Presumably because designing for widely diverging screen sizes adds a ton of work.
And the large screen is about to increasingly become just a surface for viewing multiple small screen apps simultaneously (e.g. iOS apps on MacOS). And arguably a lot of that could be done with rather plain HTML.
I went to college for IT in 2000 and got to learn lots of this first hand. One important bit of history following was the introduction of Google Chrome. Up until then IE6 was making our lives quite difficult, and Chrome broke the MS inertia with it's standards support and silent updates in a way Firefox had been unable to achieve.
I wanted a constraint-type system. A is above B, B is to the left of C, D is below A and B. Something like that. All declarative, handled by a constraint solver. Any serious parametric CAD system has that. Usually with more features than you need for web layout, like the ability to handle curves.