From 24dd932defb17ad9f93ccf62b7c8b110ed9b1832 Mon Sep 17 00:00:00 2001 From: mb <mail@manettaberends.nl> Date: Fri, 23 Jun 2023 16:18:16 +0200 Subject: [PATCH] deleting drafts --- content/news/css-regions-timelines.md | 79 ----- content/news/css-regions.md | 425 -------------------------- content/news/gutenbergs-legacy.md | 60 ---- content/news/medor-tools.md | 11 - content/news/visiting-medor.md | 283 ----------------- 5 files changed, 858 deletions(-) delete mode 100644 content/news/css-regions-timelines.md delete mode 100644 content/news/css-regions.md delete mode 100644 content/news/gutenbergs-legacy.md delete mode 100644 content/news/medor-tools.md delete mode 100644 content/news/visiting-medor.md diff --git a/content/news/css-regions-timelines.md b/content/news/css-regions-timelines.md deleted file mode 100644 index 2ad60c5..0000000 --- a/content/news/css-regions-timelines.md +++ /dev/null @@ -1,79 +0,0 @@ ---- -Title: CSS Regions quirky timelines -Date: 2023-06-07 17:00 -Author: Manetta Berends -Tags: residency, shoulder-to-shoulder, css-regions, html2print, web-to-print -Slug: css-regions-timelines -Status: draft ---- - -Nieuwe CSS functies worden niet door browsers geimplementeerd, als zij niet door de W3C officieel worden voorgesteld. Ze kunnen alsnog geimplementeerd worden, als “experimentele en onstabiele†functie, als tenminste [drie browsers het initiatief nemen om een functie te implementeren](https://www.w3.org/TR/CSS/#de-facto). - -De CSSWG benoemt dat het implementeren van experimentele onstabiele functies het risico in zich heeft om een [“lock inâ€](https://www.w3.org/TR/CSS/#experimental) te vormen, wanneer gebruikers op de nieuwe functie gaan leunen. - -*“generative entrenchmentâ€/“generatieve ingravingâ€* - -Voor OSP was het belangrijk om de mogelijkheid te hebben om complexe layouts te ontwerpen. De CSS Regions worden gebruikt om layouts te maken met tekstvakken van verschillende maten die vrij geplaatst kunnen worden op de pagina, wat een hoeveelheid aan extra opties voor het plaatsen van tekst. Ook kunnen meerdere tekstverlopen geplaatst worden op één pagina, wat bijvoorbeeld de mogelijkheid geeft om een tekst in meerdere talen naast elkaar te zetten. De CSS Regions maken dat mogelijk dankzij het introduceren van **fragmentatie**. - -Door het werken met F/LOSS heeft OSP ook een praktijk ontwikkelt van het aan elkaar knopen van tools, om zo eigen productie omgevingen vorm te geven. Etherpads worden PDFs, wiki’s worden boeken, plotters maken omslagen, etc. In dit proces liggen altijd onverwachte disconnecties op de loer, die vragen om een hack of inventieve oplossing. - -Toen de CSS Regions niet gebruikt konden worden in de reguliere browsers, was het voor OSP dan ook geen onbekend terrein om na te denken over een omweg en te kiezen voor het ontwikkelen van scripts om verschillende tools aan elkaar te knopen. De praktijkervaring van zowel het maken van complexe layouts en het intiem werken met ontwerptools, was sterker dan de keuze van Chromium om de CSS Regions niet meer te ondersteunen. De jaren van ervaring van OSP zijn ook een vorm van “generatieve ingravingâ€. - -Chromium heeft zichzelf ingegraven in de ontwikkelen van het web en zag in de CSS Regions geen gezond collectief innovatietempo. OSP heeft zichzelf ingegraven in de gewoonte dat een pagina met fragmentatie visueel interessanter is, betere vormen van lezen mogelijk maakt, en speelser is. - -*“scaffoldingâ€/“in de steigers zettenâ€* - -OSPKit zet CSS standaarden en mondiale browser ontwikkelingen in de steigers, om toegang te houden tot de CSS Regions. Al leunend op Qt-WebKit 5.212 uit 2016, worden de CSS Regions nog steeds gebruikt tijdens het maken van Médor. - -Komen de CSS Regions nog terug? - -SilentImp vraagt het zich af op [8 augustus 2016](https://github.com/w3c/csswg-drafts/issues/389): - -> Also is there any plans for moving spec forward? -> It marked as depricated [here](https://chromestatus.com/features/5655612935372800) - -Niemand reageert. - -Ook Jens Oliver Meiert vraagt op [28 juni 2016](https://lists.w3.org/Archives/Public/www-style/2018Jun/0033.html): - -> From what I understand CSS Regions aren’t pursued anymore, but is this actually true? -> -> Probably thanks to the W3C process, the draft at <https://www.w3.org/TR/css-regions-1/> looks way too much like it could raise from the dead at any time—or is there (work on) a Working Group -Note?†- -En een week later: - -<br> - -> Is it? - -<br> -<br> - ------------ - - - - ------------ - - - ------------ - - - ------------ - - - ------------ - - - ------------ - - - - - diff --git a/content/news/css-regions.md b/content/news/css-regions.md deleted file mode 100644 index 55e5d46..0000000 --- a/content/news/css-regions.md +++ /dev/null @@ -1,425 +0,0 @@ ---- -Title: CSS Regions -Date: 2023-05-18 17:00 -Author: Manetta Berends -Tags: residency, shoulder-to-shoulder, css-regions, html2print, web-to-print -Slug: css-regions -Status: draft ---- - -<small>This blog post is based on a longer conversation with OSP broadcasted by Varia in the context of the Publishing Partyline in 2022, which can you access here: <https://cc.vvvvvvaria.org/wiki/Sometimes_this_approach_can_materialize_itself></small> - -As with any particular way of working, also html2print comes with its possible constraints and constraint-based possibilities. - -An important software bottleneck in this practice is the browser, which come with many built-in ideas, legacies, values and priorities. Something that has a direct impact on web-to-print practices is, for example, the limited understanding of a browser regarding what a document can be: modern browsers can only render a web page as a single flow document. When you press CTRL+P to print a web page, the browser assumes the document that you would like to print only contains one running text. And on top of that, it also assumes that this text is written in only one language. This might sound innocent, but it actually blocks a whole range of possibilities when it comes to layout making. Possibilities which have been ubiquitous on in the tradition of book making practices, where it has been very common to let multiple types of content run across pages in parallel. - -To add more flexibility to layout making, OSP has been working with a never officially supported CSS standard since 2013, called *CSS Regions*. Ten years might not sound like a long time, but it is when you think about the short period of time in which this standard was implemented by (some) browsers. Chrome for example, only supported CSS Regions between 2011 and 2012, with an extention to 2014 if you enabled a specific setting. Ever since CSS Regions have been absent in so-called modern browsers. - -OSP decided to remain firm and chose to explore the possibilities of producing a workaround. Working around the changes that were made to CSS standards in general and to browsers in particular. 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 timelines, expectations and durabilities. - -What brought OSP to the CSS Regions? -Which workarounds are needed to work with this never fully implemented CSS standard? -How does a practice based on hacks and workarounds trigger different attitudes? - -**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. - -------------- - -![screenshot or diagram to demonstrate how CSS Regions work]() - -------------- - -**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. - ----------- - -![diagram to demonstrate what a browser engine does]() - ----------- - -**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. - ----------- - -![screenshot of blog post? or diagram to show how many lines could be removed...]() - ----------- - -**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. - -**Alex**: But I also remember using another browser for a while: Epiphany. - -**Manetta**: Which also uses WebKit? - -**Alex**: Yes at least at that time it was using WebKit. - -**Gijs**: They stayed with WebKit, right? In the sense that -Chrome was using WebKit, and shifted to Blink. And then Epiphany as a -browser remained using WebKit, or maybe even qt-WebKit. - -**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. - ----------- - -![timeline of browsers and browser engines?]() - ----------- - -**Manetta**: 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. - -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. - ----------- - -![illustration of a polyfill as a filler of a crack in the wall]() - ----------- - -**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 mentioned one already, Ephiphany on Linux. 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. - -**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](https://wiki.qt.io/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](http://osp.kitchen/tools/ospkit/), which is part of our html2print workflows. - ----------- - -![screenshot of OSPKit]() - ----------- - -**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. - ----------- - -![illustration of browsers following each other?]() - ----------- - -**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, the 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\] - -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. - - - diff --git a/content/news/gutenbergs-legacy.md b/content/news/gutenbergs-legacy.md deleted file mode 100644 index 6e5eb1c..0000000 --- a/content/news/gutenbergs-legacy.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -Title: Gutenberg's legacy of the page -Date: 2023-06-08 17:00 -Author: Manetta Berends -Tags: residency, shoulder-to-shoulder, gutenberg -Slug: gutenbergs-legacy -Status: draft ---- - -# Gutenberg's legacy of the page - -- template -- fixed margins -- grid -- columns - -What is Gutenberg's legacy? -How did it evolve over time? -Why is it still around so much? - -# A page as a flow - -![Balsamine 2013-2014]() - -# Other paradigms? - - - - - -------------- - -# Drie verschillende layout generatiesystemen: Paged.js en OSPKit en CTRL+P. - -## Paged.js - -- nieuwste versie van CSS + toekomstfuncties -- toegankelijk voor veel mensen om mee te werken -- enkelvoudig tekstverloop -- is afhankelijk van: ? -- volgt W3C -- volgt Gutenberg - -## OSPKit - -- versie van CSS uit 2016 -- compileren van software is nodig voordat OSPKit gebruikt kan worden -- flexibele tekst fragmentatie -- is afhankelijk van: Qt-WebKit 5.212 -- volgt eigen (zij)pad -- volgt Gutenberg deels: CSS Regions maakt fragmentatie mogelijk, wat het mogelijk maakt om een pagina te maken met voetnoten, running headers en pagina nummers - -## CTRL+P - -- nieuwste versie van CSS -- toegankelijk voor veel mensen om mee te werken -- enkelvoudig tekstverloop -- is afhankelijk van: ? -- volgt W3C -- volgt Gutenberg niet diff --git a/content/news/medor-tools.md b/content/news/medor-tools.md deleted file mode 100644 index c84d5a4..0000000 --- a/content/news/medor-tools.md +++ /dev/null @@ -1,11 +0,0 @@ ---- -Title: Médor tools -Date: 2023-05-18 17:00 -Author: Manetta Berends -Tags: residency, shoulder-to-shoulder -Slug: medor-tools -Status: draft ---- - - - diff --git a/content/news/visiting-medor.md b/content/news/visiting-medor.md deleted file mode 100644 index 9281460..0000000 --- a/content/news/visiting-medor.md +++ /dev/null @@ -1,283 +0,0 @@ ---- -Title: Visiting Médor -Date: 2023-05-18 17:00 -Author: Manetta Berends -Tags: residency, shoulder-to-shoulder -Slug: visiting-medor -Status: draft ---- - -Two weeks ago I visited the Médor office during one of the production weeks of Médor n°31, to get an impression of how the magazine is made. - -OSP has been working on [Médor](https://medor.coop/) since the magazine started in 2015. Some of the OSP members are actually co-founders of the magazine. Together they set up a magazine for Belgian investigative journalism, which is independent, inclusive and participatory. - - - -The magazine started as a printed magazine, but later also became available in an online form. Médor works with a membership model, the layout is made with free software, illustrations are often released under open licenses and there is a rotating editorial team. Médor currently has 2872 members and 1766 associates. If you are curious to know more, there is [a nice page on their website with a description of how Médor was founded](https://medor.coop/medor-cest-quoi-cest-qui/notre-histoire/). - -In 2015, OSP worked with a range of tools: Scribus, Inkscape, ConTeXt, Gimp, Graphviz, FontForge, Libre Office, amongst other scripts and *magicks*. Alongside, they also started to work with html2print, for example in the work for the Balsamine theather. Making printed matter with html2print continued with Médor: the magazine is made with html2print from the very beginning. But! Not only. Some of the pages in the magazine are made in Scribus and Inkscape, which was an interesting discovery. - - - -The image above is a slide that was made in 2015, when OSP was thinking about the implications of working with html2print on Médor. - -As you can see, CSS Regions were already on the table, listed as the first *issue to solve*. Today, 8 years later, CSS Regions are still used to make Médor, but the situation radically changed. Different workarounds and software patches were needed to make sure that CSS Regions could still be used to make the layout of the magazine. - -What happened? The browser Chromium, the only suitable browser on Linux machines supporting CSS Regions, decided to switch its browser engine –from WebKit to Blink– and dropped its support for CSS Regions. - -This caused panick. To be able to work with CSS Regions, OSP looked for workarounds. And after a few different attempts, they initiated OSPKit. A simplified browser that runs on a version of WebKit released in 2016, with the concequence that all HTML, CSS and Javascript versions that are used in OSPKit are so-called "outdated" and stuck in that year. - -The work on Médor has been the trigger to make OSPKit. And the CSS Regions play a crucial role in the making of the layouts. I am curious to dive into the editorial workflow of this project and to hear more about the role of the CSS regions and how they are used in relation to the workflow as a whole. - -Why are the CSS Regions important for making Médor? - -How is the html2print workflow connected to the Scribus and Inkscape workflows? - -What made it possible to work with multiple tools on one magazine? - ---------- - -<small>Alex Leray & Manetta Berends in conversation at the OSP studio, in the morning of Friday the 26th of May 2023.<br></small> - -There is this schematic that I just showed you, that Ludi and Louis made for this Toulouse presentation. - -XXX [add: the part about the consideration of a custom toolset workflow at first] - - - -There is the cloud first, it's basically nextcloud, but I remember that there were a lot of questions at the beginning. Like wheter we should make our own writing and ask everyone to work in that tool, whether it's a pad or a CMS or whatever. And there were already issues with that, because Médor is not only the team of Médor but also external journalists that they work with, or the proof reader. If we take for instance the proof reader, he has its own tools and methodologies and for instance a plugin for Microsoft Word, to check spelling errors and micro typography and stuff. And tracking changes is used a lot too. - -And also because they often collaborate with journalists, some are recurring and come back, but some just work with them for one artice. So it was really too much to ask everyone to work with the same set of tools. And also it is very intimate to work with specific tools. - -So in the end that was also why we work with a cloud. The cloud is a nextcloud installation that we have. We have this repository of files online, where everyone can drop all the kind of documents that they want, wheter it is odt, docx, jpg, tiff, whatever is good for the articles. - -Basically the journalists and proof reader work with the odt or docx documents. And once it has gone through the proof reading and the text content is validated, only then we switch to the CMS where we encode the articles. - -**What do you mean with "encoding"** - -Encoding is copy-pasting the content into the CMS. The docx or odt's are mainly text and a bit of structure, but we have some additional structures in the CMS that can be used. For example, if you want to encode a portfolio, you have to use a gallery block. And then it also can be translated into the web version of the article, so it is displayed as a gallery. - -And once we went through the whole process of writing the articles and proof reading, we create an article page in the CMS, inside of an issue page. - -**Do you do this, or do the journalists make a new page in the CMS?** - -We do it. - -**So the journalists only upload their odt or docx documents to the nextcloud?** - -Yes, and then they come back for minor edits and stuff. - -But yes when we do this, the article is supposed to be finished, but that's not always the case of course. - -**Are there other tools used to organise the collaboration between the designers, the editors and the journalists?** - -We always needed to make a flatplan of the magazine, to see if there was no conflict between let's say two articles. Or just to see how we want to spread the content. To, for example, not have too much depressing investigations around corruption at the same place in the magazine. The journalists came up with a simple solution that we still use actually, which is a simple spreadsheet with 128 cells to dispatch the pages of the magazine. - - - -The problem with this spreadsheet based flatplan is that it is not so practical, because let's say you have an eight paged article that is spread between booklet one and two... It's not really practical to move things from one place to the other. So you have to use extra cells on the side of the spreadsheet as extra space to park an article, and so one. - -At some point we came up with this idea to make a tool to fetch from the website the list of articles in order, to generate some kind of automatic flatplan in HTML, to be able to move things around and push the new order back to the website. And this was working for a while, but then we switched CMS and it did not work anymore. - -**And now you're back to the spreadsheet.** - -Yes back to the spreadsheet. - -**Is such a flatplan an important tool for the overall workflow? Is it important for you for example to know on which page an article starts?** - -XXX - - -**Coming back to the CMS, which software is used?** - -The first website was plain Django. For which we made a few modules. So for instance an article module, or an person module. So you can put the article in the article module and connect it to persons, and so one. We remade the website a few years later, I think it was 4 years or something. We switched to Wagtail CMS. - - - -The old website needed to be ugraded, and we started to look for Django developers. And in the end it's always the same story, when you ask someone else to work on the website, usually their answer is not to take what is there, but to restart from scratch. And so yes, this person advised to use Wagtail. The CMS was pretty much following the structure that we were already using on the old website. The main structure is the article. - -I think the main feature is the text editor of Wagtail, which allows you to construct an article with blocks. And each block can have a different kind of type. So if you have a piece of text you can just use the rich text block. If you want an image, an image block and so on. But you can also make your own blocks, like the gallery block, for instance. And also, at some point there was the need for an article to make a kind of simulation of a messenger conversation so we made a special block for that. - - - -**How do you connect the articles with OSPKit?** - -There is an API. In the former website it used to be a simple HTML output. We were just taking the article from the CMS and it almost had not structure, just a few classes. - -And now it's a json API. You can see it raw there. - - - -**Did you prefer the HTML output?** - -Yes the HTML output was very nice, it was much more simpler. - -**It was one step less?** - -Yes. I know that Doriane reminded me that the HTML output is way simpler, and she suggested to go back to that. - -It was a choice to switch to JSON, because usually all the article follow the same structure, but sometimes we have a special need for the layout. A simple example is the use of subhead. We have a specific CSS class for that. But sometimes you want this subhead to be... eh... wait, what is the contrary of subhead? When something is below a header, but you want it to be above? Adove-head? - -When you want to change the order, it is an issue with HTML output, because we had to go through Javascript to reorder things. We could also have made two divs and two different CSS flows, but it's extra work, when you just want something to be in a different order. - -**So it is about the seperation between content and form?** - -Exactly. - -**Because in the HTML output you could not change the content.** - -Yes you would have to manipulate it with Javascript basically. - -But in the case of the JSON API, since we get the "raw" data, I thought that we could have the freedom to change the template. - -**So to have access to both content and form again?** - -Yes. - -The set of tools that we made to connect to this API, retrieve the JSON content and turns it into a HTML chunk through templating. This is done in Javascript with Vue.js. - -So we have a setting.js file. And it contains a token to connect to the API. And if we look at one of the articles that is in the layout directory, let's say the *Edito*. So what happens is that at the end of the file you have a kind of HTML tag, it's a custom one: <art>. - - - -It's a kind of tag, it's more a directive actually. Vue.js is looking for this directive and then looks at the src attribute that points to the API. And then with this directive there is some Javascript that fetches the URL of this article, retreive the JSON and turns the JSON content into an HTML fragment with some templating, to just put the title as a h2 and so on. And then it replaces the <art> directive with the HTML. I think Vue.js calls it a component. So it replaces the component with the HTML fragment. - -So in the end it's the same as just writing our content in the HTML document, except that we don't have to and we can retreive it from somewhere else. - -**So you can for each article generate different layouts?** - -Yes. - -**So the content is structured in one way but it does not mean that the layout is always following the same structure? Which creates more possibilities?** - -Yes, so at the moment the content is usually quite simple. It's made out of a title, paragraph, a couple of images and quotes. It's almost the same for all the articles. And we change the appearance with CSS classes. - -But we can potentially do different kind of HTML formatting according to the kind of content. - -**Do you make a custom template for each article?** - -It's very much a division between content and form actually. The HTML is usually pretty much the same. And then we apply different kind of styling depending of the type of article. If it is an editorial, the body gets this style. If it is an investigation it gets this style. - -And we have a base stylesheet and another one. Basically we have two styles: the global styles who are applied by default and the article styles, which allows us to override the global styles. - -**So in the end, the switch to the JSON API, did not bring a different way of working. It is only used for exceptions?** - -Yes. - -**So structure is kept the same as much as possible, unless you really need to change something?** - -Yes. - -**Is it more difficult for you to work with html2print when there is a strict seperation between content and form?** - -Yes but since we have the CSS Regions we can still move things around. - -Let's say we have a sidenote in an article, this sidenote does not have to be encoded at this specific place in the CMS. - -**Do CSS Regions bring back, in a way, the ability to work with both content and form at the same time?** - -Yes it allows to move things around and change the structure that is hardcoded and very linear in HTML. Sometimes it is more practical that a text flows in order, but this order does not be the final order in the layout. - -**Do you have an example in which we can see the CSS Regions at work?** - -For this article [on the screenshot below] there was a mix of images that should appear inside the body text, in the columns, and others were placed on specific positions. - -This image for example is placed at a specific position, at the bottom of the page. - - - -And if you go to "computed" you have a very feature to see from which region it is flowing. So if I click there, it will bring me to the div element that contains the flow. Not from where it originates but to where it flows. - - - -**Ah nice you see the text flowing from one page to the other here, nice!** - -Maybe in another article. - - - -**Ah you can see the different articles in html2print? That is really useful.** - -Yes in the script... "make json" probably, yes. You see all the pages inside the layout document, and it will generate all these pages. - - - -The list of article names is made manually. We actually don't use the CMS API to retreive information about an issue. This was done in the old website, but not anymore. And you see that this list is just in alphabetical order, not in the order of the magazine. - -**So later you reshuffle the articles in the right order?** - -Yes. - -And the version of html2print that we use for Médor is actually a page with a big iframe in which we load the different layouts. And at the bottom there is a small toolbar that allows to change zoom, change articles and a couple of other things. - - - -**And this is an html2print version made for Médor?** - -Yes, adjusted to Médor. But for me there is no official version of html2print, so yes. It's one of the many versions that is around. - -I can't remember who made this version. Probably there was already the preview option. This was probably a CSS class that we used to write by hand in our HTML, and then we thought oke, we can turn this into a button. - -(...) - -Something else, and you're going to like it... - - - -The table of content is the only place where we use CSS grid. I think CSS grid is really nice. But we had a nasty little issue. For some reason it cut the descendant of the text in italics on the left side of the text box. Is it clear? Let me draw you the situation... - - - -Let's say we have a big piece of text, like a big J, I don't know how to draw a J, let's say it looks like this. And the J is in italic. And for some reason with CSS grid it would just cut the J on the left. It was quite disturbing, it was not overflowing. - -We didn't manage to solve this thing, so we kept our own CSS grid in which the elements are actually absolute positioned, and we have different classes to position them in different steps in the grid, in our grid. - -**The grid was too rigid.** - -Yes. - -And because we're stuck with an old version of WebKit and CSS, it is this kind of bug that is not really solvable. - -**What is the difference between CSS Regions and CSS grid? Both of them can be used to flow content into a template, right?** - -XXX - -**What are the limits of CSS Regions? When do you switch to another tool, like Scribus?** - -XXX - -**It's interesting that the workflow enables you to work with different tools. Was it a concious choice to do it in this way?** -(You could also have tried to stretch html2print toward its limits and make all the pages with HTML and CSS perhaps?) - -XXX - - - - - - - - -<!--, and the relation to OSP's work on OSPKit and html2print. It has been 8 years now since Médor started and 4 issues are made every year. The Médor project. I'm curious what has changed over the years and what stayed the same. - -The layout of each issue is made by a group of 3 or 4 designers in the timeframe of 3 weeks, in which they closely work together with the editors and illustrators. The group of designers who works on Médor rotates, every issue is made by a different constallation of people, of which some are members of OSP and others not. - -I was wondering how these production weeks are organised. - -Is the layout being made in one big document which everyone works on all together? Or is it done in another way? ---> - -<!-- ![announcement page explaining how someone can become a member of Médor]() --> - -<!--It turned out that the final PDF of a Médor issue is not rendered from one document. Instead, a workflow is set up that makes it possible to produce the final PDF in chunks, and each chunk is produced by a different person and also with different tools. Most of the article pages are made with html2print for example, but a special page like the announcement page (see above) explaining how someone can become a member of Médor, is made with Scribus. Each chunk is saved as a PDF and collected in a shared Nextcloud folder. --> - -<!--An important detail that makes it possible to work in this way, is the fact that the production of content and layout is closely linked to each other: the total number of pages of the magazine is fixed from the beginning. A shared spreadsheet is used at the very start of a new issue, where authors can "sign up" for an amount of pages in the issue. The editors use this spreadsheet to decide where each article will be placed. Thanks to this, [ASSUMPTIONS] the design work does not have to wait for the final content to be ready to know if an article will start on the left or right page. This seems not a super important factor perhaps, but pages positioned on the right side have a special function in publications, they usually feel more pleasurable for the beginning of a new section or article. [/ASSUMPTIONS] --> - -<!-- -How does the workflow shape the collaboration? - -How is content provided by the authors and illustrators? Can it be edited in parallel of the design work? - -What would be layout-wise impossible to do without CSS Regions? ---> - -- GitLab