osp blog

In 2013, in the middle of W3C discussion threads around Paged Media features of the web, browsers engine shifts and partially implemented CSS standards, OSP started to use HTML and CSS to make books and publications.

While figuring out what impact it would have on their practice to make printed matter with web technologies, OSP listed their issues to solve. At the top of this list we find the issue of flowing text on a page. Which is marked as resolved with an "ok", thanks to the presence of a specific CSS property: CSS Regions.

Slide made for a lightning talk during the 2013 edition of the LGM (Libre Graphics Meeting) in Madrid, found in the Balsamine 2013-2014 repository: https://gitlab.constantvzw.org/osp/work.balsamine.2013-2014/-/blob/68417b61b23a73a9c6807d6265d4385964bad195/lgm-talk/

The Mmmmmm at the right bottom of the slide might already indicate a gut feeling and awareness of the always-changing dynamics of the web. In the same year, in 2013, Chromium announced that they will switch browser engine, from WebKit to Blink, and that they will drop the support of CSS Regions. Since then, it has become increasingly hard to still use CSS Regions on Linux machines. But not impossible.

The story around OSP's work with CSS Regions introduces a particular example of a dependency relation that is entangled with a complex configuration of software timelines, web standards, layout traditions, commissioned work and excitement to explore book making with HTML and CSS.

Why did OSP choose to stay with a never fully implemented CSS standard? Why are the CSS Regions important for OSP? Which workarounds are needed to keep working with CSS Regions today?

{ OSP CSS Regions W3C } -> { OSP -> CSS Regions -> W3C } [label=" ? "]

---

Alex Leray, Amélie Dumont, Gijs de Heij and Doriane Timmermans (OSP) in conversation with Simon Browne and Manetta Berends (Varia) at the OSP studio, in the late afternoon of Wednesday the 7th of September 2022.
Initially broadcasted in the context of the Publishing Partyline, a two day event in October 2022. The full conversation can be accessed and listened to here: https://cc.vvvvvvaria.org/wiki/Standards_and_work_arounds

Manetta: Can you maybe explain what CSS Regions are and how it works?

Doriane: Yeah. [laughter] So CSS Regions is mainly a set of CSS properties. And the way it works, is that's it separates a bit the content from the layout, in the sense that you still have all your <div>'s and paragraphs in one content <div>, but then you're able to let all your content flow in another set of <div>'s. Which are basically kind of empty <div>'s, because when you inspect them there is not the real content in them, but the browser renders it as such that the text is inside of it.

So what it allows you to do is that you have one big flow of content, and to divide it into seperate content flows, and to place each of these flows into a different <div>. So it's helpful to make magazine layouts and printed media in general.

How you work with CSS Regions in HTML and CSS: you copy your content in the <article> element, which is flowed into the <div class="region">.

Manetta: Why was it important to use CSS Regions in your work?

Alex: I think the first reason was to do a multi-paged document. Because if you have a printed booklet, it might be as simple as you want, like one column of text. But you might have a footer, or you might have an image on the right page, and then you want to continue the text on the page after. So at some point it was kind of the solution to that, within this kind of broken environment of web-to-print at the time. So it was not so much... because then it's funny to say where the CSS Regions came in, but was not so much about... It was a little bit like problem solving for this multi-paged output. That's the way that we found to do more fragmented layouts, and also to go away a bit from the linearity from the web. But it also was at some costs in a way.

Manetta: We'll get to the costs in a bit. [laughter]

Because in 2013 the CSS Regions functionality was removed from the browser you are using in your practice, which is Chromium, a version of Chrome that is part of the Linux operating system that you are running on your computers.

It would be great to dive into this moment together and speak about what happened and why. This is going to be a bit of a technical part of the story, to which you are much more closer to, so please feel free to interrupt...

Simon: Yes please correct our research. [laughter]

Manetta: So in 2013 Google made a big change to Chrome and Chromium: they switched to a different browser engine. Google forked Apple's browser engine WebKit and started Blink, a new browser engine. And as part of this change, they also decided to remove the support for CSS Regions from Blink.

Maybe we should start with explaining what a browser engine is, before we continue? Because that is quite important.

Gijs: So a browser engine is a piece of software that translates the code of a web page into pixels, or the code into an image. So it combines the content together with the rules for the layout and the constraints that are there, for example the width of your browser window, and then calculates or determines what the layout should be.

Maybe a clear example is to think about an image with a width of 50% and a text flowing next to it. If your screen is very wide, the image will become bigger, but also more text fits next to it. So that needs to be calculated. And if your screen is smaller, then the image is smaller as well and the text has to flow differently.

So that's what this engine does. It takes the instructions or the limitations set in CSS and combines it with the content that it finds in the HTML, and it determines what is looks like on your screen.

A browser engine renders the HTML + CSS into a web page, taking the size and resolution of your screen into account.

Manetta: And you could work with CSS Regions because they were implemented in the WebKit browser engine, right? Can you say a bit more about WebKit? What made you aware that you were reyling on this particular browser engine?

Gijs: Well WebKit is a fork of KHTML. Apple introduced its own browser as a competition with I think Firefox. And at that moment also Internet Explorer was also still working on Mac. So Apple took an existing open source project, KHTML, and brought other engineers into the project and turned it into WebKit eventually. So they took over the project in a way. And because WebKit was an open source project, it was also implemented in other browsers that you could use on Linux.

Manetta: What happened when Chrome switched from using WebKit to Blink?

Gijs: I don't know exactly, but...

Alex: First Chrome was running on Blink...

Gijs: No WebKit.

Alex: On WebKit, sorry. And they were sharing the same web rendering...

Gijs: Engine.

Alex: ...engine –thank you– with Safari basically. And Chrome took some shares on the market. At some point they decided that they wanted to continue the development of the browser, they probably disagreed with something, I don't know the story, but I think there was some kind of disagreement.

Gijs: I think, in my mind, CSS Regions was the reason for the split. In the sense that there were blog posts about the enormity of... Let's say, there were a lot of lines of code that were there specifically to support CSS Regions. And the developers wanted to decrease the size of Blink.

And also, which is something else, CSS Regions has been proposed as a standard by Adobe. It very closely imitates the idea that Adobe has about layout, where you draw boxes on a page and there's content flowing into the boxes. Very much like how their tool InDesign works. And there's also kind of a clear relationship between Adobe and Apple. As in, I think at that moment, the most important reason for people to use Apple computers was because Adobe software was running on it. So I also think that that heavily influenced Adobe's proposal and their interest in the WebKit project.

And Google wanted to remove CSS Regions, or at least that is my understanding of the story. They wanted to remove the CSS Regions functionality, because it would make the browser faster.

Manetta: Yes that is what we also read. That CSS Regions occupied 10.000 lines of code, which could be removed from the browser engine basically, which was written in 350.0000 lines of C++ code in total.

Manetta: Did you heavily rely on Chrome in your practice actually?

Alex: I think when we discovered CSS Regions, I think we used Chromium. Which is an open source... it is a version of the Chrome browser on Linux. But we used it only for a very brief time, if I remember it correctly, because right after Chrome and thus also Chromium decided to remove the CSS Regions functionality.

Gijs: Safari does not run on Linux. So at that moment Chromium was the biggest browser on the Linux platform that used the WebKit rendering engine.

Manetta: Just to clarify, you all the using Linux in your practice? That is an important detail.

Together: Yes.

Manetta: So the browser you were using to produce your work in, stopped supporting the CSS Regions.

Alex: Exactly.

Manetta: Which meant that the way in which you were producing layouts with HTML and CSS was not working anymore, thanks to switch of Chrome from WebKit to Blink in 2013. That must have been quite scary. How did you respond to it?

Alex: I think we, we tried..., I mean... we started a bit panicking I think. Not because we liked so much this CSS Regions functionality, because like I said, it was our only way at the time, or the only way how you could think about multi-page layout in the web browser. And we were not so much enthusiastic to come back to the former tools, such as Scribus. We liked working with the web so much that we wanted to continue like that, even though we had some reservations about CSS Regions itself.

Chrome switching its browser engine in 2013 caused a bit of panick, as other WebKit-based browsers did not fulfill the needs of OSP, or could not be used on a Linux machine which was the case for Safari.

Alex: What we tried was to use a polyfill, that was developed by a student at Adobe, actually, to circumvent or to re-implement in a way this idea of CSS Regions.

What we found was that it was very nice to have this code around, but it was also very difficult to work with the Javascript implementations of it. Because first of all, it was written in Javascript which is not a low level programming language and it made it very very slow when working on large documents. And second, it was breaking some nice CSS features, like selectors, which you use for instance if you want to select the first paragraph of your document. And when using the polyfill, it will suddenly select the first paragraph of every page, because the content is literally broken into chunks.

Manetta: Can you say maybe more about this notion of a "polyfill"?

Alex: I think the name comes from polyfilla. The thing you put in the wall, no?

Simon: Oh like when you get a crack in the wall? Polyfill, yes, it's a brand. Yes it's a brand for fixing cracks in the wall.

Alex: So it's exactly that, this idea to fix cracks in the wall.

Simon: Never thought about that.

Alex: Yes the idea is that, correct me if I'm wrong but, so like... you write your code as if you were using natively the functionality, but in the background there is some Javascript or a set of assets, that kind of turn it into a compatible mode for you.

Chrome stopped supporting CSS Regions, but with the use of a polyfill made by a student at Adobe, the CSS Regions could be used again.

Manetta: And this brought the CSS Regions back?

Alex: Briefly, but then, like I said, there was this speed issue. It was really a mess to layout the magazine we were working on, Médor, with this polyfill. It was really really slow. It was kind of breaking this interactivity we had with the browser.

Doriane: And also, there is an important difference with the polyfill. It tries to replace the way how CSS Regions work, but in doing so it totally changes the way that CSS Regions are working. Because CSS Regions is this kind of illusion, that is rendering content like it was inside the document. And the polyfill is actually breaking up the content and actually putting it into the <div>. So there is this confusion where you can see how CSS Regions was removed, because it was confusing how you could target a specific element. Because for example, if you wanted to target the first element of the column, there is no first element of this column, because it is just rendered as an illusion through the property of the CSS Regions.

But also, if you use the polyfill, then you can actually do this, because the paragraph becomes the first element of the column. But you cannot do the old approach, which is the native approach of CSS Regions, which is for example able to select the 5th paragraph of my text.

I think this is an interesting approach. This is also one of the expressed arguments why CSS Regions was removed. But at the same time, in Médor when we started to use the polyfill, the polyfill was not right, because we were used to the reason why it was removed.

[laughter]

Manetta: Did you work with the polyfill for a while, or what happened?

Alex: In my case for a couple of weeks. And then I gave up and we tried to look for other WebKit engines, because actually there were some. I remember using another browser for a while: Epiphany.

Manetta: Which also uses WebKit?

Alex: Yes at least at that time it was using WebKit. And there were some others. But the problem was that the projects were not so active. And sometimes they lack very much on the trunk of the WebKit engine.

Gijs: Yes so there's the difference between the browser and the engine, the browser being the interface and the engine translating the instructions. Just to explain what you said about the trunk and lagging behind.

So what it means to lag behind, is that you work with an old version of the engine. Meanwhile time goes on and new exciting CSS properties emerge, that you cannot use, because the engine is too old, in the sense that it is not updated. So when an engine is lagging behind for a year, you can bump into unexpected surprises, which force you to think why some specific CSS properties are suddenly not working.

From WebKit to OSPKit!

Manetta: In the end you forked a browser engine yourself, right?

Alex: Not a browser engine, but... So actually when we did this review of all the browsers using the WebKit engine, at some point we found one, but it was not a browser. It was a wrapper around the WebKit engine, that allowed you to insert a kind of widget into your program, with a web view.

The project we found is called Qt-WebKit. And at some point we got enthusiastic about it and started to make a "web browser" –I'm using quotes because it's a very very minimal one. It is basically a software that has a big web view and a small URL bar. And you click OK and then you can see the page inside the web view. And that is what we called OSPKit, which is part of our html2print workflows.

Manetta: And because OSPKit is based on WebKit, it brought the CSS Regions back?

Alex: Yes. And the developer of Qt-WebKit was still trying to keep the thing updated. And it also was someone who we could reach on IRC and discuss with. I remember once I asked him if there was a specific property available in the browser, and he said no. And 3 minutes later he implemented it for me. So it was a very nice experience, to be so close to the developer and his project.

Manetta: And why was it important to keep working with CSS Regions?

Gijs: So we had developed more and more projects around using CSS Regions, or that were depending on CSS Regions.

Manetta: One of the recurrent projects in which you worked with CSS Regions was Médor, right?

Amélie: Yes so Médor is a Belgian magazine, that is about... I'm not sure how to say it in English. It's journalism and a news magazine, doing deep investigation. There is an issue every three months and it has been laid out with html2print since the beginning.

Manetta: So it was an important project for which you needed OSPKit?

Alex: Yes. I think the first issue was in 2015, so it was really at the time when we were very active about building our toolset. The Médor project both benefited from our research and also was a drive to conduct more research. And because it was ambitious, not in the sense of aesthetics or whatever –it was that as well I hope– but it was ambitious in the sense that the magazine was broadly distributed and reaching a lot of people. So there was a lot of pressure to make sure that we have a correct PDF at the printer in time. Because in journalism the release is a very important milestone that you cannot really miss.

Manetta: Do you want to say more about that question why it was then important to develop OSPKit?

Gijs: If we hadn't done that it wouldn't have been possible to continue working with our workflow. It would have fallen apart and we would have had to rethink completely how we would make the layout for Médor. The layout of Médor is very much based on a grid, using all the boxes and all the space that is available on the page. And without CSS Regions it would not have been possible to produce such layout at that moment. We would have only been able to work with a single flow. You can maybe float elements to the left and right, but that is it. State of the art at that moment were multi-column layouts, and this was often not supported in html2print. Which means that you're left with a very impoverished experience.

And there's also something about... it being possible. Like you're also maybe clinging on to the possibilities of the moment. In the sense that... I think it's important to mention that there is this promise of open source, that you are able to influence or control your tool. But here it became very clear that a browser engine is such a complex piece of software, and so many people are working on it, and if those people decide to take a different direction, that they don't care about the things that you care about, for whatever reason. This might feel very foreign or might also feel wrong. But it sort of leaves you in the dark. You're there, and the browser caravan is carrying on, following their own path. And you try everything you can to keep on working with it, as long as you can. Also from the hope that, you know... that in WebKit, the CSS Regions remain supported.

Manetta: So did the maintainance work of OSPKit become part of your practice? Next to producing the layout for the magazine, or other projects that you were working on, you also needed to maintain a browser.

I'm curious to understand the impact of such workarounds on a design practice like yours. Because in the end OSPKit is a workaround, no? A work around the main direction of the development of the web. A work around the decisions that the makers of browsers make.

What happens when you introduce such workarounds into a design practice? Because it is quite something. Can we unpack that?

Doriane: Yes, maybe. One of the things is that it creates a bit of an alternate reality. Because you're suddenly living in your own browser. The path is split in two. And the current status of web-to-print goes further and new things are happening there. But in the world of this OSPKit browser, things are a bit stuck in time. And okey you have this work around that allows you to use a magic property that you want to keep close to yourself. But then you have to live in your own reality, that is a bit outside of the evolution and the tendency of the rest of the designer practice in web-to-print specifically.

Alex: Yes exactly... Because now OSPKit is kind of fixed in time, and it's already static since 2016 or something. It's getting very old, especially in this world.

[laughter]

The versions of HTML, CSS and Javascript that can be used in OSPKit are stuck in 2016.

Alex: It was a way to keep a feature feature alive, a very nice feature, or at least a work around that allowed us to stay with our practice. But at the same time it's also, like you said, it is cutting us from new practices that could arise, with new web CSS properties and developments of the web. So yes, it's a bit, I don't know how to say it, but it's doing good and bad at the same time.

Amélie: Just a few hours before the interview we were chatting and Gijs used the word technological archeology, and I think it fits to the way I feel as I'm coming back on Médor and I didn't especially follow the development of html2print. Yes that's it. I'm using that tool, that's using old technologies, and we cannot use more recent CSS properties. And so yes, we have to work in other ways and find other ways of doing.

Sometimes I'm trying to do something, and then I realise, oh I cannot use the recent CSS, so let's try to find another way to do it otherwise. It's another mindset.

Doriane: Yeah and it's a weird feeling. Like when you're used to moments when you think, oh I don't know how to do this thing, then you're looking at the docs online, and then you're doing it. And of course it's working, because you copy paste the example from the doc. But then you cannot just look at the doc, you need to test everything and if something is not working you're not sure what exactly is working and what not.

I remember that especially when working with Javascript, realising that yes, we're stuck with using a version of Javascript of 2016, which has evolved a lot since. And it's also different to work with HTML and CSS from 2016.

For example, when you want to make a border around a font, and the border does not show, you know that this CSS property was not supported in 2016. But if you're writing Javascript it becomes super hard to debug, because you have no idea which line is supported and which one not.