terribleMia’s avatarterribleMia’s Twitter Archive—№ 8,512

      1. We spend so much time dealing with the practicals of specificity, we often forget where it comes from – or how all these pieces fit together, to try & reflect the concerns of design on the web. Maybe worth a thread? 👇🏼 TerribleMia/1293605433148506114
    1. …in reply to @TerribleMia
      The original WWW proposal is clear that the web must always be device-agnostic: "This implies no device-specific markup, or anything which requires control over fonts or colors, for example." Design on the web seems impossible. info.cern.ch/hypertext/WWW/MarkUp/HTMLConstraints.html
  1. …in reply to @TerribleMia
    The Cascade is a way around that. We provide the browser with "an ordered list (cascade) of style sheets" – presentational "hints and suggestions" that browsers can choose to ignore. CSS is designed to *expect* bugs & implementation differences from the start. That's the point.
    1. …in reply to @TerribleMia
      In order for this to work, browsers need a way to: 1. Resolve conflicts between styles 2. Fill in the gaps when a style is missing In the end, every single HTML element on a page needs to end up with ONE & ONLY ONE VALUE for every supported CSS property.
      1. …in reply to @TerribleMia
        We now use "cascade" to talk about that first step, and "inheritance" (along with "defaulting") to talk about step two. Cascade no longer refers to the list of stylesheets, but the rules we use to merge them. And those rules intentionally represent a series of design concerns:
        1. …in reply to @TerribleMia
          First Concern: Browsers, Users, & Authors all have a stake in the final design, so all are allowed to contribute styles. Cascade "Origins": - Browsers provide readable defaults, & device limitations - Users have preferences & a11y concerns - Authors want unique styles & branding
          1. …in reply to @TerribleMia
            We start by allowing those to build: - Browser defaults as the base - User preferences next - Author styles on top But that's too lopsided. Users should have more control over their experience. We need a way for both Browsers & Users to _insist_ on their most important styles…
            1. …in reply to @TerribleMia
              So second concern, is mixed with the first: "Importance" allows Users & Browsers to override authors in a reversed set of Origins. Enter !important: - !Authors go first here, "snake-draft" style - !Users can override us if they want - !Browsers finally limit what's allowed
              1. …in reply to @TerribleMia
                Second concern: We're able to embed pages inside of pages – iframes, SVGs, web components, anything with a Shadow DOM – and each "Context" is allowed to provide new styles. This is a more recent addition to the cascade, allowing inner-context to override bleed from outer rules.
                1. …in reply to @TerribleMia
                  We've balanced power between styles, so we're ready to focus on the concerns of designers. This is where we propose inserting a "Layer" system that mimics "Origins" – because designers need to balance similar conflicts between resets, defaults, libraries, components, & overrides.
                  1. …in reply to @TerribleMia
                    (and I need a short lunch break…)
                    1. …in reply to @TerribleMia
                      Concern #3: As designers, we often create general patterns, & then override them in context. We need *instance* styles to override *class* styles. All design tools (InDesign, XD, Figma, Sketch, etc) provide some form of this pattern/override "Specificity" under the hood.
                      1. …in reply to @TerribleMia
                        In graphic tools, that looks like some form of style palette with presets we can apply broadly – but if we select just one item, we can override aspects of the pattern! Ideally without losing all connection to the broader pattern. CSS represents that with different selectors…
                        1. …in reply to @TerribleMia
                          - Element types establishing very basic/broad defaults. A heading & a paragraph deserve different starting styles. - We can override that with custom, reusable classes & attributes: our style palette. - Finally IDs give us direct access to a single instance. Three layers…
                          1. …in reply to @TerribleMia
                            We can mix & match how we use them to describe complex ways of selecting, but the Cascade takes each one at a time. 1. Selector with the most IDs will always win 2. If there's a tie, we look at classes/attrs 3. Still a tie? Count the element types No need for complex math…
                            1. …in reply to @TerribleMia
                              We don't need to assign number values & compile a total. We can count each category individually: - One ID overrides *any* number of classes. - One class overrides any number of elements Like software versioning: 2.1.0 is always greater than 1.32.350
                              1. …in reply to @TerribleMia
                                Concern #4: We need a way to provide device-agnostic fallbacks, & the browser needs a final definitive rule. For both, "source order" provides a great final step. We can say: grid-template: inherit; grid-template: subgrid; Allowing browsers to use the last one they understand.
                                1. …in reply to @TerribleMia
                                  These tools that we use every day – SPECIFICITY & IMPORTANCE & ORDER – aren't arbitrary rules to make CSS confusing. They are direct & meaningful encapsulation of real open-platform design concerns. They're also the only tools we have, so we hack them to address other goals…
                                  1. …in reply to @TerribleMia
                                    That's where things get frustrating. The cascade sucks when we need a wire-clippers, & we're stuck with a hammer & ratchet set. Specificity is trying to do too much at once, & it wasn't designed for that. We don't need to ditch the whole toolbox, we just need a few more tools.
                                    1. …in reply to @TerribleMia
                                      I think Cascade Layers solve one small part of that problem. We also need a meaningful way to represent Component ("Block»Element") Ownership – what we often call "scoped" styles. People are working on that as well. Modernizing the cascade is a big project.
                                      1. …in reply to @TerribleMia
                                        </thread> Hope that's useful to someone! 😅 CSS is out here doing the impossible: collaborative design of unknown content on an unknown canvas, across languages & platforms. There is no other language even making the attempt. CSS is one-of-a-kind & deserves its own paradigms.
                                        1. …in reply to @TerribleMia
                                          Addendum: If "the cascade" is about describing explicit "architecture" of our design, "inheritance" fills in the gaps with _atmosphere_. The cascade builds our house, inheritance makes it a home? Or it's the color wash we paint our subsect over. Or… ???