- Software Development
- What the Success of CSS Says About Technology Standards – InApps 2022
What the Success of CSS Says About Technology Standards – InApps is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn What the Success of CSS Says About Technology Standards – InApps in today’s post !
Read more about What the Success of CSS Says About Technology Standards – InApps at Wikipedia
You can find content about What the Success of CSS Says About Technology Standards – InApps from the Wikipedia website
Earlier this month developer Zack Bloom wrote a thought-provoking essay that presented a look back in time to the 1990s when new Web content-styling languages were shared and discussed on small and geeky mailing lists. His journey through the past suggests an important lesson about the sometimes almost arbitrary way the world chooses its technology winners and losers.
Through accidents of history, some powerful and promising formatting languages were ultimately passed over in favor of Cascading Style Sheets, which today represents a ubiquitous and entrenched standard. Bloom took one last, lingering look at “the languages that were almost CSS” — and triggered an ongoing discussion about the world we inherited. Bloom’s essay is a “testament to what might have been,” as one Omaha-based developer said.
It was 20 years ago that Håkon Lie published the very first version of the CSS spec — but Bloom cast his sights on the era which preceded it.
“CSS was not usable until 1997, and was not fully supported by any single browser until March of 2000,” Bloom wrote in his essay. “As any developer can tell you, browser support wasn’t anywhere close to standards compliant until just a few years ago, more than fifteen years after CSS’ release.”
So even back when HTML was first announced in 1991, “CSS wouldn’t be introduced for five years, and wouldn’t be fully implemented for ten. This was a period of intense work and innovation which resulted in more than a few competing styling methods which just as easily could have become the standard,” Bloom wrote.
Even before the first rumblings about a thing called the world wide web, there were already discussions about how style information should be conveyed to the browser. Using archived discussions from the “www-talk” mailing list, Bloom can quote a fascinating remark by future Netscape co-founder Marc Andreessen back in 1994. Someone had asked Andreessen “why don’t you just implement one of the many style sheet proposals that are on the table. This would pretty much solve the problem if done correctly.” Andreessen’s response?
“So then I get to tell people, ‘Well, you get to learn this language to write your document, and then you get to learn that language for actually making your document look like you want it to. Oh, they’ll love that.”
Later on Reddit, Bloom weighed in on the personality of Marc Andreessen, even documenting them with vintage videos. The essay, which triggered immense online discussion, began with a remembrance of all those which had also been proposed — RRP, FOSI, DSSSL, PSL96, and the PWP stylesheet language for the Viola browser — as more than a collection of forgotten acronyms.
It’s a fascinating look into a different world. For example, Robert Raisch’s RRP used attribute names with just two characters (like “fa” for font and “si” for size) to minimize the amount of data that would have to be transferred over 28.8 bps modems. And it also reflects a world where style sheets would only “suggest” styles to browsers. Blooms says the “hints” approach — e.g., the absence of a unit of measurement — “was considered necessary because the same stylesheet needed to function for both the common line-mode browsers (like Lynx) and the graphical browsers which were becoming increasingly popular.”
Over the last few weeks Bloom’s essay has produced some thoughtful reconsiderations of the past, and in a heartwarming twist, someone identifying themselves as RPP’s creator Rob Raisch left a comment on Bloom’s blog post. “Dear god…a lot of water over the bridge since those days, eh? Thanks for this.”
“It’s an honor, thanks for reading!” Zack responded, and got him to open up with more memories. “The terseness of the encoding was very much in deference to the paucity of bits on the wire of the day,” Raisch added, and “bandwidth was an enormous concern.”
“I remember commenting several times publicly about how the Internet would never be able to support high-bandwidth applications (like video and audio) due to the meager pipes we all had… The idea that someone would be streaming video on an upstream link was enough to make all of us scream bloody murder about “abuse of the commons.”
Bloom’s essay had described how Pei-Yuan Wei ViolaWWW browser had shipped with its styling language, using parentheses in an “almost LISP-y” syntax to declare “nested” styles — for elements within other elements. Unfortunately, it was targeted at the X Windowing System (which was used mostly on Unix systems), and would eventually be left behind. But just days after the browser’s creator, Pei-Yuan Wei unveiled his suggestion, the mailing list took up the idea of a styling language from the 1980s. “One inviolate rule of the Internet is: more will always get done if you can prove someone wrong in the process,” Bloom joked.
Another alternative proposed for a new styling language was FOSI, which had its origins in the SGML language created by the Department of Defense. Its biggest advantage seemed to be that its styling was enclosed in brackets, just like HTML, making its syntax more familiar to ’90s-era developers.
“This is just proving a testament to the idea that even if you have a terrible standard in place, people are going to propose using it rather than trying to re-invent or create a new, better approach,” observed Matt Steele, in his video summary of the essay. “This has been in our industry’s DNA since Day One.”
At what’s even more impressive is the sheer ambition in some of these style-language proposals, like the 1996 announcement of DSSL — the Document Style and Specification Language. “The long-term plan was to create a language based on the functional programming language Scheme, which could enable the most powerful document transformations you could imagine,” Bloom wrote. Among other things, “DSSSL could treat inherited values as variables, and do math on them.”
Unfortunately, back in the 1990s, HTML pages had to load from top to bottom, which was another compromise made necessary by slow download speeds. “Languages like DSSSL were completely out, as they could perform operations on the document itself, which would not be entirely available when the rendering is to begin.”
In some wry commentary, Bloom added that DSSSL had “the fatal flaw” which would plague all Scheme-like languages: too many parentheses. Additionally, it was arguably too complete of a spec when it was finally published, making it intimidating to browser developers. The DSSSL spec included over 210 separate styleable properties.”
“Things might’ve been completely different… if it wasn’t just for a couple of snarky people on some mailing lists”–Zack Bloom.
While the team went on to create the much more popular XSL style-sheet language, ultimately “it was kind of too complicated,” suggested Steele in his presentation, “either for browser implementers to work into their browsers, or for standard web developers. Folks who were just trying to hand-crank out their HTML didn’t want to think through what the approach to styling in a Turing-complete language was. They wanted something more declarative.”
Bloom’s essay shares one more fascinating might’ve-been stylesheet language. The most intriguing feature of PSL96 — named the Presentation-Specific Language — was that “you could express element position based on not just the sizes specified for them, but the actual (Actual Width) sizes the browser rendered them.” It even included if-then syntax (rather than forcing developers to define a distinct class for every possible scenario — as we do today.)
“Unfortunately, this language was plagued by being a bit too extensible, meaning it would have been very possible for its implementation to vary considerably from browser to browser. Additionally, it was published in a series of papers in the academic world, rather than on the www-talk mailing list where most of the functional work was being done. It was never integrated into a mainstream browser,” Bloom noted.
Steele noted that while PSL96 was a complicated language, its vision was still that elusive “the holy grail of separating out your markup and your content.”
CSS: Pretty Nutty
Finally, Bloom’s history reaches that moment where CSS arrives, joking that “Like most good ideas, the original proposal was pretty nutty.”
For example, “In a somewhat optimistic sci-fi vision of the future, it was believed your browser would know how relevant a given piece of content was to you, allowing it to show it to you at a larger size:
<tt> RELEVANCE > 80 ? h1.font.size *= 1.5 </tt>
Bloom describes a weird tug-of-war between the page’s author, the webmaster, and the browser. And Steele even drew a reaction from his live audience when he described how Netscape ultimately “got cajoled into implementing CSS in Netscape 4.”
Even Microsoft was complaining, with Internet Explorer’s creator Thomas Reardon writing in an e-mail to Netscape that “if you’re going to be proprietary, as recent actions have shown, then please stop the pretense, don’t claim openness and support of standards when you’re refusing to accept standards and just working hard to undermine them.”
Bloom remembers that at the time the developer community “had already rallied around CSS, and Netscape was, at this time, viewed as bullies by much of the standards community. When Netscape did submit JSSS to the standards committee, it fell on deaf ears. Three years later, Netscape 6 dropped support for JSSS, and it died a (mostly) quiet death.”
The idea that our current status quo was, in fact, some inevitable result is called hindsight bias. What the rise of CSS suggests, Bloom suggested, is that many of today’s standards “were just quirks of history,” Bloom wrote. “We’re not necessarily getting better with our standards and specifications over time. A lot of times, we’re just changing.
“Good ideas aren’t always the ones that win… sometimes it’s just the loudest approaches or the ones that are simplest that end up winning,” Bloom wrote. “Just because an approach is popular or has a lot of momentum doesn’t necessarily mean that it’s the one that you should be implementing.”
Feature Image: Main Street, Blackrock, Ireland, 1860-1878, from The National Library of Ireland.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.