Web decoration and web design

Recently I had a great conversation with a local decorator based here in Houston. She conveyed to me fundamental a distinction between design and decoration, namely that the latter is shaped more like a dialogue within a space or spatial constraint; I might even say spatial metaphor. I had mentioned in passing that it seemed relatable to Found Art and much of the dadaist tradition. Misfire. At any rate, it seems pragmatic to introduce the distinction in web science and web anthropology inasmuch as normative patterns of HTML structural and ontological designs will invariably lack accessibility specificity beyond low- grain data lakes.

More readily it is easier to classify a large class of what wound be web design, such that functional requirements are met; namely that CSS semantics, accessibility, HATSOAS, and the rest is satisfied. However, as it is just as plain most developers deviate from standards, despite their merit or lack thereof, or they innovate, imagine, etc. beyond the scope of known non-normative patterns of web development. Crucially, web design is expected to match the functional specificity of a hypermedia web API. Not to concern the styling of a page with such an infocological constraint is to opt out of design and engage in decoration.

While this may seem to sacrifice principles, it introduces reasons to the domain of problem-solving and discovery in the production of healthy stylesheet code. Design seeks to align principles with development; decoration is somewhat orthogonal but at the same point a broad category, perhaps wider than design. Such code focus on existing layout: how can we style, predict, optimize and test without any fundamental change to the HTML structure. In this sense, we are specifying a kind of namespace far-fetching in its effects, animations, responses, idle moments and load times. Our CSS would then be dedicated to addressing the space of possibility given a structure or initiative of structures with transitions. This may include CSS art (which, again, really doesn’t need an API at all or HTTP form interactivity), most patchwork, updates, upgrades, simple, brochure sites with no CMS or CRM capabilities, a lot of #a11y specific problems, responsive, scalable tables, most dipshit UI components you fight your team about re-inventing in the latest framework, and so on.

So there you have it. A new distinction. Fuck you.

--

--