Earlier quoted context omitted.
Fixed, thanks!
While you're there: "fatal flaw which would plauge" -> plague Great article!
Got it, thanks!
Languages Which Almost Became CSS
21–30 of 136 posts
Re: Languages Which Almost Became CSS
#22DSSSL looks amazing. Truly a shame it didn't catch on. Maybe we'd have a client-side Lisp instead of Javascript too.
Can we have a do-over on the web? I've seen (and even nominally participated) in something of a resurgence of Gopher as something of a shadow web for nostalgia-addled geeks. Gopher isn't an awesome protocol, but I love anything that recaptures the spirit and decentralized nature of the old web.
At my curmudgeon-iest I like to imagine we carve off our own web where S-expressions reign, there is no Google, and a million timecubes bloom.
Re: Languages Which Almost Became CSS
#23"HTML is the kind of thing that can only be loved by a computer scientist. Yes, it expresses the underlying structure of a document, but documents are more than just structured text databases; they have visual impact. HTML totally eliminates any visual creativity that a document’s designer might have. — Roy Smith, 1993" Seems like an odd request in 1993. Sure, Prodigy had visual impact, but it was pretty hard to read…
oh man...Prodigy. I remember using my ole 1200 bps modem to load up those .. EGA? VGA graphics? I can't even remember. I do remember my prodigy user ID though.
Re: Languages Which Almost Became CSS
#24Earlier quoted context omitted.
When I die, my first question to god will be 'sir, why the hate on lisp?'. I expect the answer to involve testing of some kind.
My take is that metaprogramming does not scale to teams. Or maybe it's just the historical artifact that everybody claims to be, and if the PDP-10 supported a lisp environment, things would be different. But if I had to bet, I'd bet on metaprogramming not scaling.
Possible that most people really like to have distinct level encoded as syntax.
Re: Languages Which Almost Became CSS
#25DSSSL looks amazing. Truly a shame it didn't catch on. Maybe we'd have a client-side Lisp instead of Javascript too.
Maybe not such a shame. Having something (mostly) static like CSS has lots of performance advantages. Imagine the web being even slower than it already is, that's what DSSSL probably would have resulted in.
Re: Languages Which Almost Became CSS
#26> Contrary to popular perception, Mosaic was not the first graphical browser. It was predated by ViolaWWW
Neither was ViolaWWW the first grahical browser.
In fact the very first browser by Sir Tim Berners-Lee was already a graphical browser (even with WYSIWYG edit mode later known from Frontpage/Dreamweaver) - made possible by thr advanced NeXTSTEP operating system and its window builder IDE (nowadays known as OSX/macOS and XCode respectively): https://en.wikipedia.org/wiki/WorldWideWeb and https://en.wikipedia.org/wiki/NeXTSTEP
Re: Languages Which Almost Became CSS
#27Layout should have been constraint-oriented, not procedural. You should be able to express "Bottom of this box is adjacent to top of that box", and such. All those constraints go into a constraint engine, and a layout is generated. This is something a WYSIWYG editor can generate.
To get a sense of how this could work, try sketch mode in Autodesk Inventor (there's a free 30 day demo) You can specify that a point must be coincident to an edge, that an edge must be coincident to an edge, that something must have specified dimensions, that some dimension must have a numerical relationship with another dimension, etc. Inventor goes further, supporting constraints on diagonal lines, circles, arcs, ellipses, etc. Whether layout should support curves is an interesting question, but the technology exists to make that work.
The people who designed HTML5 and CSS thought procedurally, not geometrically. It shows. Designers think geometrically, and a geometric constraint system would make sense to designers.
Re: Languages Which Almost Became CSS
#28DSSSL looks amazing. Truly a shame it didn't catch on. Maybe we'd have a client-side Lisp instead of Javascript too.
Maybe not such a shame. Having something (mostly) static like CSS has lots of performance advantages. Imagine the web being even slower than it already is, that's what DSSSL probably would have resulted in.
Well, slower and then faster. Virtual selectors mean that CSS is now also Turing-complete (in a horrible, horrible way). And DSSSL would've been able to handle much or maybe even all of what's currently handled by Javascript.
Re: Languages Which Almost Became CSS
#29Layout should have been constraint-oriented, not procedural. You should be able to express "Bottom of this box is adjacent to top of that box", and such. All those constraints go into a constraint engine, and a layout is generated. This is something a WYSIWYG editor can generate. To get a sense of how this could work, try sketch mode in Autodesk Inventor (there's a free 30 day demo) You can specify that a point must…
There is always Grid Style Sheets[1] if you want to try it out. It is based on the same algorithms as iOS constraint engine[2] AFAIK. Unfortunately it has to compute the constraints using javascript as its not native.
Re: Languages Which Almost Became CSS
#30As a web developer, I see two main issues with web styling:
First, the web was built around sharing technical papers. That means HTML structure focuses on those elements that are relevant to papers (outline layout via H* tags, tables of data, not much else), and not the sort of things that marketing and sales want to push. (ads, rails/gutters, etc). Those of use that suffered through the early "slice-and-dice" method of making web pages are painfully aware of that. I'm a big fan of technical papers, and my expectations of flash and glitz are minimal (I, for example, hate the modern trend of not using the full width of my window.). Despite this, I feel we keep trying to stay true to the origins of the Web rather than allowing for the actual USE of the web.
Second, in an effort to keep the content machine-parseable as well as allow for agents of different devices, CSS is applied separately from content/structure (theoretically). Specifically, the concepts used DO NOT MATCH the concepts used in developing desktop applications. Even Flexbox, the most recent attempt to fix this, only loosely relates to the way desktop applications would layout the content.
I'm a huge fan of the GOALS involved in HTML/CSS, but after working on web stuff for over 20 years (not using CSS quite that long), I feel I can say it's been a failure. We've spent that all or most of that time with painful workarounds for basic tasks like: center content (particularly vertically!), Adding a left rail/right rail, filling the height of a container, matching the height of the visible window, making sure layered content is zindexed properly, and those are just the ones off the top of my head. We've invented and reinvented ways to do things like drop down menus, toggleable buttons, modal windows. Heck, from the very start people implemented their own authentication windows because the appearance and capabilities of the browser-based solutions didn't match the demands.
After 20 years, and with the benefit of all the experience of desktop development to add in, I feel like we shouldn't be fighting to manage such basic requests, that we shouldn't be reimplementing field validation and error messages YET AGAIN because even the latest advanced offerings just don't cut it.
We should be able to have:
* "flexible" content (appearances adjusts to visible space)
* machine parseable content
* attractive UI
...without it requiring the dramatic hoop-jumping we have today.