A major part of our engineering culture is to take an active part in the global developers’ community by sharing the best of our technical expertise.
In our new podcast you will hear the stories and insights from our very own, alongside some of the most prominent voices in the tech community.
In our first episode, “Stand Up and Fight”, we hear it directly from Håkon Wium Lie, the mind behind the Cascading Style Sheets (CSS), about his own story of one developer’s willingness to fight for the principles he believes in, even against the biggest technology company in the world at the time: Microsoft.
In this episode we will also hear it from Gilad Segal on how Wix Engineering is taking CSS to the next level:
You can also listen to this episode on Apple podcast, Spotify, Google or on Wix Engineering site. And you can also read the full interview here:
Hi and welcome back to The Wix Engineering Podcast. My name is Ran Levi.
We left our last episode with a conundrum. Håkon Lie was trying to convince two powerful internet companies to fully, equally implement his Cascading Style Sheets format into their browsers. Neither was keen on the idea. Then one of those companies--Microsoft--subsumed the other--Netscape--which solved the problem. But it also introduced a whole new, even more difficult problem. Microsoft now possessed, essentially, a monopoly in the internet browsing market. They controlled everything--they didn’t have to listen to anyone, let alone a little developer like Håkon preaching interoperability and cooperation.
Håkon Wium Lie: So all eyes were really on Microsoft and unless Microsoft fixed the problems in CSS, it didn’t really matter that Opera had a much better implementation because nobody could use it. You were limited by what the dominant browser had in their code.
Having nearly 100 percent market share, Internet Explorer became, for most of the world, synonymous with internet browsing. Microsoft had a huge, powerful monopoly. They didn’t have to listen to some small group of developers calling for a language uniformity across all browsers. In fact, they could ignore everyone, build their own CSS-type language, make it purposely incompatible with other browsers, and it would only further their dominance.
In fact, Microsoft was already vertically integrating just about every aspect of the internet experience.
Håkon Wium Lie: Well, there was the DOM. There was HTML, JavaScript. Basically Microsoft had their own implementation of all of these and I’m not a specialist on anything outside of CSS.
There’s no company today so thoroughly dominant as Microsoft in the early 2000s, but the closest equivalent may be Apple. Apple deliberately designs Apple products to work with other Apple products, and not other products. The devices, the apps, even their own Swift programming language. It’s how we got to a world where “PC” is one category and “Mac” is another.
Still, you can use Internet Explorer on a Mac if you want and CSS works on Safari. This wasn’t always a given, most notably in the early 2000s.
Håkon Wium Lie: If we don’t have that on the web, we don’t really have the web. We don’t have a web where everyone can contribute. You don’t want to have a web where you had to speak the Microsoft dialect.
I understand from Microsoft’s point of view. Why should they add key programmers around when they have 90 percent of the market? Then basically you can do a lot of cool stuff if you speak the Microsoft dialect. There is little incentive for them to fix those bugs.
So from a kind of management perspective, I can see why they did what they did, which was basically to close down the IE team. But from a specifications end, from a web developer’s point of view, it’s totally, totally madness and it keeps you lying awake at night to think about those bugs in IE and that’s not really a world we want to live in.
So that’s why I had to start kind of a battle against Microsoft and against the people that I had worked with in the past.
Håkon was about to take on the world’s biggest company, and their CEO, the world’s richest man. The company which supported him from the very beginning, and employed many of his friends and colleagues. It would be the defining fight of his career. An uphill slog. But, listening to him tell it, it wasn’t all bad.
It has some entertainment value to fight with Microsoft. I can’t say I hated all aspects of that.
On February 3rd, 2005, Bill Gates published an “Executive E-Mail.” It began, quote:
Every day, businesses face an ongoing challenge of making a wide variety of software from many different vendors work together. It’s crucial to success in streamlining business processes, getting closer to customers and partners, or making mergers and acquisitions successful. Whether you are connecting with partners’ systems, accessing data from a mainframe, connecting applications written in different programming languages or trying to log on across multiple systems, bringing heterogeneous technologies together while reducing costs is today a challenge that touches every part of the organization.
Over the years, our industry has tried many approaches to come to grips with the heterogeneity of software. But the solution that has proven consistently effective – and the one that yields the greatest success for developers today – is a strong commitment to interoperability.
End quote.
Håkon Wium Lie: Well, my life was centered around the un-interoperability in Microsoft’s product.
Håkon was going about his daily life. Then Bill Gates published his “Building Software that is Interoperable by Design” letter. It wasn’t just a slap in the face, it was as if the richest, most powerful man in the world was teasing him.
Håkon Wium Lie: Basically the bugs in IE kept me awake at night and when he’s bragging about the interoperability of Microsoft products, that was totally madness. To me that was so clear that he – either he doesn’t have a clue about what’s going on on the web, or he’s basically just disregarding it, just to create a marketing speech.
Gates wrote that, quote, “Simply put, interoperability is a proven approach for dealing with the diversity and heterogeneity of the marketplace.” And, quote, “Microsoft offers a comprehensive portfolio of interoperability software capabilities.”, e nd quote. He described the many ways his company promoted, and participated in the development of interoperable technologies across the industry, in collaboration with outside developers and companies.
In response, Håkon devised his own letter, aimed directly at Bill Gates.
So I knew to some very exact detail what was wrong in their product, in the IE browser. So I could sit down and write that – you know, a little cheeky letter, perhaps. But I had all the facts right. I knew what I was talking about, and there was also an audience there.
“So Mr. Gates,” it begins, “you say you believe in interoperability.” Håkon then listed out all the ways in which Microsoft was shorting on their commitment--not just CSS, but HTML4, Web Core Fonts and so on--and the ways they could improve.
The letter ended, quote: “Convince us. Deliver on your promises.”
Håkon Wium Lie: There were a lot of people in the web development community who were cheering, who were seeing the problems caused by Microsoft’s lack of interoperability.
So I think I had a lot of support for doing that and The Register wrote articles about it and there was a lot of buzz in the community, which of course egged me on a bit too.
Unfortunately, no matter his support in the development community, Microsoft’s profit-making interests were still stacked against him.
Håkon Wium Lie: They didn’t fix the bugs in IE and I think I know why. It was a very comfortable position for them. They had established kind of a Microsoft dialect of HTML and CSS and for them fixing that so that they conform to the standards instead of their own dialect meant A, they had to invest in programmers, and B, they had to risk that some of the pages that their customers were currently using, that they ended up looking differently.
That’s of course a business cost when you change a product and something turns out to not look the same. So for them it would have been better if the world had adapted to their dialect, their versions of the standards.
It was clear that no letter was going to change anything. The small community of developers in the know may have supported Håkon, but the rest of the world didn’t care, and was probably more likely to side with Bill Gates over a lesser-known adversary, anyway.
Håkon Wium Lie: So it was clear that some people would read my letter, my article, but most wouldn’t. But if we could make a test that would showcase, highlight the fact that IE was quite terrible as a browser, that would have more impact.
Microsoft would have to be exposed somehow, in a way that was clear enough for anyone to see.
Inspiration came in the form of what’s called the “Acid1 Test.”
Håkon Wium Lie: The first Acid Test was written by Todd Fahrner. He was an early participant in the CSS work and he saw some problems in early implementation of forms and HTML elements, basic things that were part of the CSS 1 specification. And the test was mostly done within the working group, it wasn’t widely published outside. But he was able to take some early problems with that relatively simple test.
The Acid1 Test was designed to determine whether browsers were fully compatible with CSS1. It consisted of a collection of boxes--orange, red and black, against a white background--of different sizes and dimensions, some inside one another, each containing little text phrases like “Toggle” and “sing to me.” A fully CSS1-compatible browser would render all of these boxes--their colors, sizes, orientation, and text--correctly. A browser with zero or incomplete compatibility would not, and its failure would be immediately obvious to any observer.
We refer to it as the “Acid1 Test” today only because there was an Acid2 test, co-created by Håkon Lie.
Håkon Wium Lie: In order to write that test, I enlisted Ian Hickson of later HTML 5 fame. He’s an incredible hacker and incredible spec writer as well, and he knew the CSS specification to some detail and he also knew the browser implementations to some detail.
So we worked together. We shared a hotel room in Boston for a week for one of the World Wide Web conferences, we shared that room so that we could really work hard on the test. I think I had – my main contribution was that smiley face. The smiley face is good. It’s very easy to see when it’s right. It’s obvious when something isn’t right there.
But Ian was the one who wrote the underlying code. He’s really good at it and we were very pleased with the results. We had some other contributors as well.
The Acid2 test was a pixelated smiley face--green eyes, a big smile and a square nose. I guess their intention was to make it fun but, if I’m being honest, it looks kind of creepy. Like if you fail the Acid2 test it’s going to kill you.
Ian and Håkon wrote in that if a browser failed the test, the smiley face would become distorted and leave red streaks along the page.
Håkon Wium Lie: I have to admit here that we added some of that red background to make the face, the smiley face look kind of bloody. I think we chose that color to make it look like blood. So we made it a little worse than it seemed perhaps.
With this creepy smiley face, any browser could be easily, unambiguously tested for CSS2 compatibility. It could be tried on any browser, but, obviously, the main target was Internet Explorer.
Håkon Wium Lie: I think now, many years later, I think CSS would have been very different if we hadn’t had that Acid Test. It was a very important part of making sure that CSS could be used for real by real developers on real webpages.
A lot of people started asking Microsoft questions about this. One thing were the newspaper articles that were written, but also the people – you know, developers who were very conscious of their trade. They wanted to do right code, do it the correct way. They started asking Microsoft questions. So when there was a Microsoft talk at a conference and they opened up for questions afterwards, somebody would raise their hand and said, “When are you going to do the Acid 2 Test?” and then the next version of IE came out. That was IE 7. So then we were very hopeful that they had fixed these problems.
Despite the promise of Internet Explorer 7, the results of the test were not good. In fact, they were really, really bad.
Håkon Wium Lie: When it was out, you know, it kind of struck as a lighting. It was like, “Wow! Is IE really that bad?”. The page was still bloody. The nose and the ears and the eyes were in the wrong places.
To say the ears and eyes were in the wrong places is an understatement. Other browsers, like Opera 8.54 and Firefox 2.0 had eyes and ears in the wrong places. The IE7 Acid2 test looked more like the flag of the Soviet Union--all red across the page, with some remnants of the dismembered yellow smiley face off to the left side. A gruesome murder.
Håkon Wium Lie: So they tried initially to say that this is not something we care so much about. I remember distinctly one Microsoft person saying, “We have bigger fish to fry.” That was the term he used.
“Bigger fish to fry” was, really, one of the nicer things Microsoft said about the Acid2 test during that time. In July 2005, IE’s Platform Architect referred to Acid2 as not a proper compliance test, but a quote, “wish list” of features. Their General Manager referred to it as quote, “torture test,” and? quote, “what one set of people feels very strongly about.”
Håkon Wium Lie: So I thought OK, this is not good news. From looking at the test, it’s obvious that Microsoft doesn’t comply. We can all see this in the web standards community. But if Microsoft chooses to disregard it, we can’t really do anything about it. I mean we can’t really sue them, can we?
All we could do was to raise awareness in the community and that’s that we did.
Slowly, the smaller players in the industry began fixing their browsers to comply with CSS2. Six and a half months after the test was first published, Safari was the first to release a fully-compliant browser, on Halloween, 2005. Opera passed in June, 2006, and Firefox two years after that.
But the browser that really mattered remained unfixed.
In one sense, Internet Explorer actually didn’t matter quite as much as it once had. When Acid2 was created, they’d controlled nearly 90 percent of the browser market. By 2008, Firefox had taken a good chunk out of Internet Explorer’s market share, with around 30 percent of all internet users favoring their browser. With major companies like Apple and, soon, Google, competing for the same customers, the reign of Internet Explorer was soon to be over.
Perhaps this softened Microsoft to the idea of cooperation.
Håkon Wium Lie: I thought maybe this wouldn’t work at all. But then at some point, Microsoft, the pressure on Microsoft must have gotten too high internally.
Somebody must have decided that guys, we’re going to have to do this. This is going to be a problem for us. If we keep on ignoring these guys, they’re not going to give up.
So they just decided to fix it. And when IE 8 came out, it was perfect. That was one of the true moments of joy in my life - was testing IE 8 to see how they performed with the Acid Test and seeing that, wow, it passes. They’ve done it.
March 19, 2009: 15 years after first proposing his new paradigm for internet styling, four years after releasing the Acid2 test, the battle was over. Håkon Lie had stood up to the world’s biggest company, in defiance of the world’s most powerful man, and won.
Håkon Wium Lie: That was pure victory. A very good day.
The story of CSS isn’t just about CSS, or how a developer stood up to an internet giant. It’s about how the internet should be. How we build a better future. How Håkon and a community of developers stood up to the powers that be, and didn’t accept an internet that wouldn’t work equally well for all.
We take interoperability for granted these days. It just seems implicit to how the internet is. But it’s not. A lot of people worked hard to make it that way. And if we don’t continue to promote open-source projects, open and equal dialogue in the development community, and interoperable software across all our digital platforms, the internet is still very much capable of change. For the worse.
Following the 2016 U.S. presidential elections, Facebook was accused of abetting, or, at least, turning a blind eye towards a proliferate fake news campaign carried out by far-right political groups and the Russian government.
In September, 2018, The Intercept published an internal Google memorandum outlining the company’s plans to develop a China-based search engine, which would censor all anti-government content.
In December of 2018, in a party-line vote, the Federal Communications Commission repealed 2015 net neutrality legislation, thereby opening the door for telecommunications companies to block, throttle and create prioritization structures according to which companies could pay more for their broadband access.
In 2005, Håkon Lie stood up to the most powerful company in the world, and its CEO, the most powerful man in the world, to demand a free and equal internet.
As a handful of powerful corporations vie for the kind of internet monopoly Microsoft possessed two decades ago, we’re left wondering: who, today, has the courage to stand up and fight?
That’s it for the story of how the CSS standard came to be universally adopted by all the major internet technology companies. And now, as an epilog of sorts, here’s a short interview with Gilad Segal, our front-end developer team-lead at Wix, will describe to us how developers in Wix are pushing CSS technology forward.
Gilad Segal: I think of CSS as a tool in my toolkit. And in order to be able to provide the best user experience for my users I need to master all the tools I’m using. I see Javascript as important as CSS. I want to use the latest, most modern Javascript features, I want to use the best most modern CSS features as well.
CSS can have an impact on many aspects of any website. For example, accessibility. What CSS does is separate the concerns. So you have the HTML for the semantics and markup and you have CSS for stylings. Like in the past we might use a table, an HTML table to create the website layout and a skin reader interpreting – the markup might think of the layout as tabular data which might get the user using the skin reader confused. And about performance, CSS can offload work to the GPU, it can reduce the time to the first render using the font display property, it can make buttons react faster using the touch-action property, the list goes on.
So in the past, while we were designing a website, there were a few static layouts. But we had to deal a lot with browser quirks, non-standard implementations and requirements that couldn’t be properly expressed using CSS- like border radius. Before we had “border-radius” we had to use images to create [that effect] around these borders, which is kind of funny.
Nowadays the web has matured a lot. We have more standouts, more cross-browser consistency and capabilities, but the features we are required to develop are rich and more complex layouts and we have to support any viewport no matter how small it is. So it’s more dynamic than what it used to be.
Another point is that not so long ago we had to support all the browsers that didn’t update automatically, and as a result, they weren’t aligned with the modern CSS spec. So we could use only small common subsets of all the available CSS features. And this is the mindset of many developers still today.
But, as a matter of fact, we know that this is not what happens today because browsers do update automatically and are aligned with the spec so we can use modern CSS. And this brings me to my challenges. First of all just keeping up with the spec, which updates rapidly, is quite a task. And also to be a CSS advocate, which means I need to challenge all the colleagues around me to learn and implement their tasks using modern CSS.
Generally when we use something new we want to gain something - like more performant code, simpler code, better user experience. So I’ll split my answer into two parts. First of all we have the optimal environments, we have dropped support for legacy browsers completely. In those environments we can use new CSS features to be more effective without worrying about backwards compatibility. In those environments we can use sticky positioning and logical properties, implementing those kinds of features without CSS would require a lot of Javascript.
Then we have the more demanding environments, like the user websites, where we want to support legacy browsers to give better user support. There we need to usually pick between one of two approaches - either graceful degradation or progressive enhancement, and I and to explain what those terms mean. So graceful degradation means that we build our code for modern browsers and provide a lesser but functional experience for users with old browsers. Progressive enhancement means that we provide a very basic user experience and make it better if the user is using a modern browser.
An example of graceful degradation is a page that we built using the new grid layout for modern browsers and we fell back to an older and less capable version of the grid for specifically IE11. And regarding progressive enhancement, I think we’ve reached a turning point, because we are discussing it in our day-to-day features. And implementing it is easier than what it used to be, using the “@” rule, this all allows us to conditionally apply a set of CSS declarations based on browser support. The good news is that old browsers don’t recognize this rule at all and don’t apply any declarations contained within it.
Many people don’t know that the representatives of the browsers are in the standard committees and they are helping to create the standards. Usually people get pissed when some browser does not support this standard or that standard, but actually the browsers are creating the standards for themselves and they partake in the committees. Which is nice and something to think about. And in regards to IE, way before CSS, even 10 years ago when I was developing stuff for IE6, I remember it was very difficult because you had to write specific code for Firefox, specific code for IE6, specific code for IE7. So it was very repetitive and very tricky. You had to know a lot of stuff, very broad or specific stuff.
That’s it for this episode. Thank you for listening!
Want more engineering insights? don't miss our upcoming meetup: A Change-Data-Capture use-case: Designing an Evergreen Cache