Declarations is an ongoing artistic research into the poetic materiality of the CSS web-standard.
An article about an in-progess web-extension called scrapping. It collect and archive elements of a webpage (e.g a searchbar) and store it on another web page to curate collections (e.g a collection of scrollbars). Like the practice of scrapbooking, it allows us to select, "cut" and "glue" elements we see on the web.
Members of OSP and Luuse gathered to develop a web-extension which resulted from several work sessions of Declarations. Declarations is an ongoing artistic research into the poetic materiality of the CSS web-standard. CSS is a coding language used to apply styling (colors, fonts, animations, layout...) to a website when coding it. During the last year, some researchers, artists, developers, designers, gathered and reflected about this web language.
First, what is a web-extension?
A web-extension is a small software one can download on a web browser to add features when browsing the web. For example a popular web-extension called "Add blocker" is used to block adds on websites and videos. It's helpful to customize one's web experience. They are tactical to have a personalized web experienced and reshape the web how we want to. We call them companion tools and it's possible to create your own!
What is the project?
We imagined a web-extension called scrapping which could be used to collect and archive elements of a webpage (e.g a searchbar) and store it on another web page to curate collections (e.g a collection of scrollbars). Like the practice of scrapbooking, it would allow us to select, "cut" and "glue" elements we see on the web.
The track of research around this extension started with those questions:
This extension could serve a professional purpose as well as more artistic one.
The extension is currently in development stage. At this point, a first version of the web-extension is already working but needs improvements.
Here is a short summary of the technicality of the web extension.
So far the browser extension is made to function only on the browser Firefox. The extention is written in JavaScript.
The actions one can execute would be described as:
The extension consists mostly on two seperate things :
As explained just before, the user will press SHIFT when desiring to select an element to scrap. At this moment, all the elements of the page will appear with a cyan border.
After selecting the desired element, a pop-up window will appear.
The pop-up window will include:
The public collection is the website that will gather all the collected scraps, from everyone using the browser extention.
Regarding the collection's interface, we wondered how all the scraps should be displayed. By default the scraps should be shown chronologically (most recent at the top, oldest at the bottom at the page). We would need a pagination system to avoid the webiste needing to load too heavy content (imagine having to load 1000 scraps on one page).
A filtering system would be a helpful tool to browse through the craps, they will be:
We thought of three modes of viewing the scraps in the grid: 3 different ways of visually translating the scraps:
Since we're scrapping bits of HTML and CSS, the materiality of each scrap and all the information they contain (the meta-data) seem vast and ambigious. In order to apprach that, we decided to list everything we could gather around on element, and then see what would be the process of actually getting it. Inspired by the book scrapping analogies we tried to think of each materiality as a different physical tool that would collect something.
The main action that the Javascript does is grabbing information from the scrap's website.
While gathering the URL, or the HTML (bookmark and scissors) can be straight forward, getting the CSS applied to a specific element is a lot order than it seems.
When you right click on a web page, you can "inspect" the current code of that page. It allows you to see the HTML structure and the CSS properties applied to each element of the page. At first glance, the inspector is very easy to use and is a very practical and fast tool. In a way getting the style applied to an element is a bit like re-coding our own inspector. Unfortunately for us, the inspector tool is actually a very complex one, so we need to reproduce its functionality but in an easier way. Reproducing the "inspector" made us understand the CSS ambiguous materiality.
Firstly we had to reflect on the different possibilities of accessing the CSS information of an element using JavaScript. There are different JS ways to access the CSS of an element
The first one is through ´.style´. Using the JS ´.style´ to get the inline style of an element, for example:
element.style.background = "red";
will result in
<p style="background:red;">hello</p>
Limitations: it actually works backwards : we can easily apply a style to an element but we can't actually get a style from an element.
The second one is ´.getComputedStyle()´. We get all possible properties that exists of one element, but it doesn't specify which ones where and wheren't declared. Also, it only gives the resolved value. The resolved value is the value calculated but it's frozen. Think of it as a frozen version of your CSS, no visible intentions through what has been declared, no responsivity, it's like a screenshot but through a huge list of variables. for example if you said in CSS ´width: 50%;´, ´.getComputedStyle´ will give you the actual rendered width, wich depend of your own screen, and can be like 324px.
let compStyles = window.getComputedStyle(element);
compStyles.getPropertyValue("width");
Limitations: we don't get the "real living" value of an element, but instead its calculated final static result. It's not considering an element as a responsive element.
The third one is through the CSSStyleSheet JS API. This native JS API has a different approach, it lists the declarations used on the page per stylesheet, more like the way they were initially declared. It allow to list all stylesheets used in a document (let's say main.css, font.css, color-palettes.css, etc) We can iterate on each one of those, and then iterate on every declarations block!
for (let sheet of document.styleSheets) {
for (let rule of sheet.cssRules) {
if (rule instanceof CSSStyleRule) {
console.log(rule.selectorText);
for (let propName of rule.style) {
let value = rule.style[propName];
console.log(propName, value);
}
}
}
}
Conclusion: This last option is the more promising for what we wanted to achieve, but also the most intensive, as when scrapping an element, it would require to go through all the CSS stylesheets, and all the declarations block on every stylesheet, to see which ones we need to pick (because they're applied to the element we're scrapping) and which ones we don't.
By grabbing one single element and its children, from a webpage and gluing it back to the collection, we remove it from its context. We remove it away from its parent. This can create confusion in the declarations applied to that element. Or simple if we wrote in CSS
main > blockquote {
border: 1px dotted chocolate;
}
If we scrap one of those blockquote to upload it to our collection, it is not inside of a main tag anymore, therefore that rule is not applied anymore... Think of the same problem for selector last ´:nth-of-type(2)´, it's not the second element anymore while cutted from its context.
To deal with that we decided to come up with a system of assigning a new class to every selector, keeping their properties but each have a unique classcontaining thoses properties. They can now be decontextualised with no fear of losing properties.
Sometimes elements have styles attributed by their parent element (their container, or lets say their surrounding) and they "inherit" that style automatically. Certain properties are inherited, others are not. This might sound weird because we don't think about it while writing CSS, we use it as an instinctive language. But when we say ´div{ color: darkorange; }´ what we want is all the text inside of that div being written in dark orange, even childs of childs of childs, color is an inherited property. When we say ´div{ maring: 10px; }´ what we mean is that that div specifically should have margin, we absolutely don't want every of it's children to have the same margins.
The spyglass would be an additionnal tool that zooms out of the pipette, and smartly grab inheritance pattern. We need to work towards listing inherited properties.
How to select a see-through element and select the color in its background as well? The simpliest way we found to explain that obstacle is the following.
<body>
<p>you can see through me</p>
</body>
body {
background: red;
color: grey;
}
What we will see is clear: a grey paragraph inside of a red body. But the subtlety is that the paragraph background is actually transparent, it's the default, only the body has a colored solid red background. We see the red body through the paragraph as if it was another layer floating above. The color is an inherited property though, meaning even though it is defined on the body, it will transfer to the paragraph.
So if we scrap that paragraph it will not look with red background once removed from its context and put inside of the collection. Faking that red background by emulating is a very fragile solution, as you never know if a design can include 12 paragraphs absolutly positioned above each others with games of transparency.
But it can also be interesting to show that ambiguity once the material is collected instead of emulating visually something too complex. We thought allowing the user to change the background color of the whole public collection could render some scrap visible and invisible from time to time. The intial background color of the element would anyways still be screenshoted and visible on the "view mode".
It's important to mention that all those faced difficulties make the scrap extension a bit slow and it can take up to 1 minute to scrap an element at this point.
We looked at collected references, mostly different existing collection, on the web or elsewhere.
Building this extension led us to discover more about the materiality of CSS and its ambiguity, and wonder about collections, web archeology and its cultural meaning. Like mentioned at the top of this article, the scrap extension is still in development mode, but it's already mostly working. It needs improvements but we are working towards a proper version to share.
