[HN Gopher] CSS Zen Garden
___________________________________________________________________
CSS Zen Garden
Author : onat1
Score : 299 points
Date : 2025-04-27 04:44 UTC (1 days ago)
(HTM) web link (csszengarden.com)
(TXT) w3m dump (csszengarden.com)
| voidfunc wrote:
| Blast from the past... I loved the CSS Zen Garden but it's goals
| and philosophy were oriented to a world where the primary purpose
| of a website was to serve documents. Our rich media world sort of
| left this vision of the web in the dust sometime in the mid
| 2000s.
| bigbuppo wrote:
| I wouldn't say it's rich media, but the conversion of the web
| to be 100% marketing-driven. It's ads all the way down.
| kome wrote:
| "a world where the primary purpose of a website was to serve
| documents"
|
| we are still living in this world. and i don't mean it
| snarkily. beside some maps application, most of the web is
| still about reading stuff, and it doesn't need so much cruft.
| it's getting more complex just because developers prefer
| complexity over simplicity.
| switch007 wrote:
| De facto it's a web app, not a document, world. Have you
| tried browsing without JavaScript recently? It's even worse
| in this AI era when content sites want proof of work, only
| available via JavaScript.
| nathell wrote:
| That's a serious downgrade.
|
| https://blog.danieljanus.pl/2019/10/07/web-of-documents/
| est wrote:
| Is "modern media" really rich? I think information density and
| signal-noise actually degrades
| alxmdev wrote:
| Glad to see the Garden is back! This and Spoono were some of my
| favorite websites back when CSS-driven web design was bleeding
| edge and people were just starting to use lots of nested divs
| instead of lots of nested tables. The book was nice too.
| pier25 wrote:
| A bit of light in the dark ages of Tailwind and CSS-in-JS.
|
| It's difficult to realize how significant CSS Zen Garden was 20
| years ago or so.
| memonkey wrote:
| They published a book that I purchased when I was first
| learning CSS. Truly a different era.
| spiderfarmer wrote:
| It made me fall in love CSS for sure. But it didn't prevent me
| from understanding the appeal of Tailwind for large scale
| projects.
| nuw wrote:
| Please enlighten me of the benefits of using tailwind in
| large projects as opposed to using inline styles.
| ookblah wrote:
| mobile selectors, "group" selectors, hover styles... the
| list goes on and on. like all things, it depends on how
| your workflow. if you have a super defined hierarchy and
| naming scheme you can reference then sure, centralize all
| your CSS. if you have many components and multiple people
| working on them sometimes it's better to separate
| everything out and enforce with a guide.
|
| i can't tell you how frustrating it is to open a component
| and have no idea what you're looking at because you worked
| on the thing months ago, or you change one thing in your
| centralized CSS and have no idea what the side effect are.
| with tailwind i can see exactly the styles i'm looking for.
|
| FOR ME, works better to have a core style file and then
| move everything to something like tailwind per component
| for maintenance.
|
| tired of seeing the same simplistic arguments against
| utility frameworks. if you can't see the merits of it then
| you obviously aren't working on projects that need that,
| but don't criticize it blindly. it's not for lack of CSS
| knowledge.
| zelphirkalt wrote:
| The thing is, when you are doing CSS properly, you will
| "anchor" your selectors appropriately. What I mean is the
| following: Ltes say you got some "component" or whatever
| you want to call it, and have a button in it, that is
| special in some way. Of course you are not gonna write
| "button a {someproperty: specialvalue}". You should be
| writing the selector as specific for that component in
| this case, for example "my-special-component button a
| {...}". If the design is implemented thoughtfully, then
| most of the problems people claim to have with CSS are
| simply non-existent.
|
| Like "side-effect" you mention. That can only happen, if
| the design is implemented reusing parts of other design
| definitions, where they are not meant to be reused. Any
| other side effect would be intentional. For example
| button text color and paragraph text color. If one wants
| them both to change, when one of them is changed, then
| one reuses the style definition, but probably in most
| cases one does not, and therefore has separate
| definitions and therefore has no silly side effects, even
| after a few months not looking at the project.
| ookblah wrote:
| yeah i'm just tired of making the same argument over and
| over. for what it's worth i've been doing CSS "properly"
| since the time when that site was a thing.
|
| back in the backbone days, now vue/react and before
| tailwind this is EXACTLY what we did, scope the styles
| down to the component, then layer it on top of the global
| styles. so sure, .my-selector a is specific to that
| component.
|
| the "side effect" happens when your app starts to span
| 100s of components and you need slight variations for
| everything. you're telling me you can assure me that none
| of your master global classes contain any design
| definitions that could not possibly be reused? i'm
| calling bullshit. it's like saying your backend 100%
| never has any duplicated functions.
|
| so with that out of the way, let's say you do get your
| global styles like 90% of the way there. so in each
| component you scoped it down. now lets say for one button
| you had to adjust the margin a bit, or another the
| styling is somewhat diff. multiply this by 100s of
| different components.
|
| tell me now how me opening a file, seeing "button
| variation-class-1 variation-class-2", then going down
| into the component <style> section and looking up exactly
| what the variation and what properties were used is in
| anyway "better" than just seeing some super powered
| inline style directly in the button. it's the same
| complexity and now you've gotten rid of the prime benefit
| of CSS hierarchy and split the "style and structure" in
| just one independent component.
|
| at some point you can't possibly create the number
| variations you need and you can't extract out "reusable"
| parts. maybe you have 5 buttons and only 2 need the 20px
| margin. do you create a "button 20px" class and do that
| in each component? no. at some point you will just inline
| it because it's easy, or you will create your utility
| class except it will be worse than tailwind.
| skydhash wrote:
| Or you can just just ".special-component .button"
| selector adapting the selector to be more specific as
| needed. Most code reuse in CSS is bad, because they break
| when the design changes. You don't DRY just because the
| code are the same.
| ookblah wrote:
| yeah and when you do that for 100s of components i'd
| rather just see a utility class on the button itself vs
| hunting down its meaning in the related section of the
| component.
|
| this is exactly the shit i was annoyed by when scaling,
| having to scope a .my-component-X section for literally
| every component and then grokking it later. you're
| basically taking the worst part of CSS (hunting down the
| meaning of a selector) and duplicating it for every
| component.
|
| now maybe you say name it better or more semantically?
| congrats you recreated BEM lol. literally all the
| arguments used against it are purists for purity sake or
| thinking people haven't gone through this same thought
| exercise.
|
| just use whatever is best for the task. i still use css
| the "traditional" way.
|
| /rant
| skydhash wrote:
| Why the hyperbolic about 100s of components? Because if
| that exists somewhere, then it's just plain bad design to
| me.
|
| Let's say you writing templates for a website and you
| have a partial named "main-navbar", it has a search input
| field that looks like the other input, but needs some
| alteration. Are you going to name all these alteration
| like "margin-x-2px", "font-small". Or just add a new
| style block with ".main-navbar .search-input" as the
| selector.
|
| > _you 're basically taking the worst part of CSS
| (hunting down the meaning of a selector) and duplicating
| it for every component._
|
| Why are you hunting it down? If I need to find the styles
| that are applied to an element, I just open the web
| inspector. More often than not, from bottom to top, it's
| the reset style, the component style, the variant style,
| and the styles derived from its relation with its parent
| and siblings.
|
| With tailwind <div class="mx-auto flex
| max-w-sm items-center gap-x-4 rounded-xl bg-white p-6
| shadow-lg outline outline-black/5 dark:bg-slate-800
| dark:shadow-none dark:-outline-offset-1 dark:outline-
| white/10"> <img class="size-12 shrink-0"
| src="/img/logo.svg" alt="ChitChat Logo" /> <div>
| <div class="text-xl font-medium text-black dark:text-
| white">ChitChat</div> <p class="text-gray-500
| dark:text-gray-400">You have a new message!</p>
| </div> </div>
|
| With "traditional css" <div
| class="alert"> <img class="alert-icon"
| src="/img/logo.svg" alt="ChitChat Logo" /> <div>
| <div class="alert-title">ChitChat</div> <p
| class="alert-message">You have a new message!</p>
| </div> </div>
| zelphirkalt wrote:
| I would add, that usually also I would not hunt things
| down, because I put styling for a navigation into a
| stylesheet file called "navigation.css". Not much hunting
| to do there. Sounds crazy, but actually works.
| zelphirkalt wrote:
| > the "side effect" happens when your app starts to span
| 100s of components and you need slight variations for
| everything. you're telling me you can assure me that none
| of your master global classes contain any design
| definitions that could not possibly be reused? i'm
| calling bullshit. it's like saying your backend 100%
| never has any duplicated functions.
|
| At that point the design department of your business has
| failed its job. Case closed. If everything is slightly
| varied, then there is no coherent design. Not even my
| backend-dev developed "designs" are that bad.
|
| > tell me now how me opening a file, seeing "button
| variation-class-1 variation-class-2", then going down
| into the component <style> section and looking up exactly
| what the variation and what properties were used is in
| anyway "better" than just seeing some super powered
| inline style directly in the button. it's the same
| complexity and now you've gotten rid of the prime benefit
| of CSS hierarchy and split the "style and structure" in
| just one independent component.
|
| I also care about what soup I deliver to any visiting
| browser. So I care about not having a thousand repeated
| inline styles, that make it harder to write user CSS for
| example. Visitors of my site can very easily adapt the
| styling, by simply changing the styling of 1 class or
| even 1 CSS variable that I defined in a theme.css.
|
| But you are also making a general mistake. You are
| letting perfect be the enemy of good. Even if one only
| succeeds 90% at what I described, this is still great and
| simple to maintain in 90% of the cases. I doubt tailwind
| is a big win over that.
| parrit wrote:
| Even on one element you can combine tailwind classes. With
| styles you need to write out the final result.
|
| Then you can also use @apply if you wish but leave that out
| of the argument as it is considered unidiomatic.
|
| Of course if using React you can also use styles directly
| and then create your own utilities to determine how they
| compose. Which might give you much of the Tailwind edge
| without needing the compile step.
| zelphirkalt wrote:
| Even on one element you can combine CSS classes. Easily.
| halflife wrote:
| Configuration. Inline styles are direct style
| Implementations in your html, tailwind is an abstraction
| that lets your configure and refactor easily. I can say
| from experience, being in charge of developing a large
| product that was bought and merged into a larger
| corporation, using tailwind from the start allowed us a
| refactor our app's design within 1 day instead of it being
| several weeks worth of work.
|
| And as a bonus it provides best practices in css
| scaffolding of a product design (typography, grid, colors)
| croes wrote:
| So how does that work exactly?
|
| For instance now I have class some-button to make the
| button blue. Next week I'm told make them yellow.
|
| It's a change in one class
|
| What would be the equivalent in Tailwind?
| K0nserv wrote:
| You use components, e.g. react, and replace the `bg-
| blue-500` class with `bg-yellow-500` in your button
| component.
| moron4hire wrote:
| HTML already has a button component. How is this better
| than creating a root CSS style for buttons using CSS
| variables to abstract the colors?
| K0nserv wrote:
| For this contrived example it isn't better. I was very
| sceptical of tailwind before I tried it, but in certain
| scenarios it's nice. I think it shines if you are already
| using a component focused development process. As others
| have said you don't need to come up with class names for
| every thing you want to style. Rather than cross-
| reference between js/html files and css files everything
| (structure, style, and interactivity) is in one place.
| You also don't need to care about specificity.
|
| Personally I think it gets a bit mad when you start
| wanting to do :hover, :active and media queries, but you
| can still use classes (using the @apply directive) for
| that if you wish.
| Scarblac wrote:
| The root style is global to one app, the component may be
| used in many different apps.
| moron4hire wrote:
| But you can use CSS rules to override variable values for
| more specific selections. So you can define a global
| --primary-button-color at the root, apply it to every
| button, then override --primary-button-color in, say,
| `tool-container`.
| croes wrote:
| So tailwind needs to be used with some kind of library or
| framework and not vanilla HTML and JS?
| K0nserv wrote:
| It's possible to use with vanilla, but probably not a
| good experience. You want either components or at least a
| templating system where you can break things down into
| reusable parts.
|
| It's somewhat similar to raw HTML vs something like PHP,
| you can have thousand of HTML files, but if you wanna
| change something common (say the header) it's not fun
| with thousands of individual files.
|
| Lastly you can combine Tailwind with regular css classes
| .btn-primary { @apply bg-blue-500 px-2 py-1;
| }
|
| but at that point I'm not sure how much you are gaining
| by using Tailwind
| immibis wrote:
| So that's exactly the same as using the CSS style
| directly. The way you've described it, Tailwind provides
| no benefit whatsoever.
| halflife wrote:
| It's less about replacing blue with yellow, which means
| overhauling design. My example was when your style system
| includes several color spectrums - primary, secondary,
| accent, grey, dark, light.
|
| Your components are styled using these spectrums -
| button.color-primary-500.bg-grey-300
|
| When you want to change the colors globally it's
| extremely simple.
|
| Same with paddings and margins.
| 9dev wrote:
| Not having to name a myriad of things! Sure, things like
| BEM can help you at least avoid naming conflicts, but you
| still have to decide a few thousand times what something is
| called semantically correct, in a way that you and your
| French colleagues and the intern of next year are going to
| understand it.
|
| When I got productive with Tailscale, I finally realised
| how many brain cycles I wasted on this. I'm, like, a
| programmer; _of course_ I'll obsess over picking the
| perfect name. _Of course_ I will not be happy with the
| names my junior picked, and _of course_ I will constantly
| be unhappy with some of them. This game of self-inflicted
| bike shedding is just a trap for people that like logic and
| order, and it's... wholly irrelevant.
|
| With tailwind, you just declare how something is supposed
| to look and feel like, at the place where it is, in the
| context of your configurable design system. No names, no
| bike shedding. Okay, that's not a hundred percent true; you
| can name group selectors, because as opposed to plain
| inline styles, Tailwind can target children, siblings,
| pseudo elements--there are no restrictions.
|
| It's a truly elegant solution for authoring web pages.
| ardleon wrote:
| Using webcomponents there is no problem with identifiers,
| you can repeat the same identifier as many times as you
| need.
| the_other wrote:
| Do you treat your JS and TS the same way, eschewing
| semantic clarity?
| troupo wrote:
| Why do you assume there's no semantic clarity?
|
| Tailwind is made for the age of apps and components. The
| semantics are on component level.
| skydhash wrote:
| So you can name a component, but you cannot name the
| styles attached to that component?
| 9dev wrote:
| It's naming one component, perhaps a sidebar, versus
| naming the fifteen children of the sidebar and their
| state transitions, in a way that's consistent with the
| other 137 components that comprise your app.
|
| It's not about not being able to name all these things,
| it's that it's pointless to do so.
| jaggederest wrote:
| You don't need to name subcomponents in a way that is
| consistent with the rest of the app, or even at all.
| That's what nesting is for. You can use simple names, or
| anonymous tags, that don't overlap because they live in a
| top level component with its own class/id.
| skydhash wrote:
| Isnt that what scoping is for? So you name you conponent
| and use selectors for styling sub components.
|
| My issue with most styling is that they want to use
| composition when it does not make any sense. Like
| spliting styles and using the pieces on things that has
| no relation to each other. If two things are not likely
| to change together, you shouldn't use the same class for
| them, unless you consider the class as primitive.
|
| Tailwind is an extreme case of this, and like all extreme
| things, it's a path to ruin.
| 9dev wrote:
| > If two things are not likely to change together, you
| shouldn't use the same class for them, unless you
| consider the class as primitive.
|
| That is exactly the kind of dogma that I'm referring to--
| Tailwind makes thinking about that pointless. You apply
| style composition to achieve the result you want to
| achieve; not more, not less.
|
| > Tailwind [is] a path to ruin.
|
| Well, I can only speak from the experience of quite a few
| _very_ successful projects relying on Tailwind: They look
| consistent, development is easy, style bundling an issue
| unheard of, and making changes to the design system
| requires a single line in the config file. New developers
| are productive from day one, there 's no bike-shedding
| over the styles, and nobody adds ad-hoc colors they just
| pulled out of their hat.
|
| For me, styling on the web is solved.
| skydhash wrote:
| I get your point, but isn't this contingent on the colors
| and other properties being stable? I don't see why this
| can't be achieved with pure CSS instead of adding a (big)
| set of names as a layer of abstraction and then
| optionally pruning the build for performance.
|
| Because consistency is achieved only at UI design time
| (see design system). Unless you're prototyping your
| design at development time, I don't really see the
| improvements compared with Pure CSS.
|
| > _style bundling an issue unheard of_
|
| But then you need to have a component system to have any
| benefit from that (if you're using the raw classes name
| from Tailwind). Which was easily done with just naming
| the component (class or ID) either automatically or not.
| troupo wrote:
| > Because consistency is achieved only at UI design time
| (see design system). Unless you're prototyping your
| design at development time, I don't really see the
| improvements compared with Pure CSS.
|
| So, every class now repeats the same properties and
| values (because CSS has no mixins or composition), there
| are dozens of classes that try to replicate scoping and
| nesting through BEM or similar, styles are completely
| divorced from actual components where they are used...
| skydhash wrote:
| This is what I highlighted in a previous comment. If you
| have a drop shadow or some padding on a component, that
| does not mean another component which have the same
| values automatically have a relation between them. So
| it's mostly a syntactic shortcut at this point. And the
| end result has no semantics.
| troupo wrote:
| > Isnt that what scoping is for?
|
| The one that hasn't been available in CSS until 2023?
|
| > So you name you conponent and use selectors for styling
| sub components.
|
| So how can you do that with CSS?
| skydhash wrote:
| > _So how can you do that with CSS?_
|
| The old: .card > .card-header
|
| > _The one that hasn 't been available in CSS until
| 2023?_
|
| That was nesting, IIRC. Sugar syntax, so you don't have
| to fully specified the whole selector.
| troupo wrote:
| > .card > .card-header
|
| And we know that it never worked well. That's why BEM and
| many other naming strategies exist: to try and replicate
| scoping purely through naming discipline.
|
| > That was nesting, IIRC. Sugar syntax, so you don't have
| to fully specified the whole selector.
|
| Nesting partly solves the naming and the "keep all of a
| component's style close together".
|
| The other partial solution is CSS Scoping:
| https://developer.mozilla.org/en-US/docs/Web/CSS/@scope
|
| And this still doesn't solve the issue of repetition
| where every component has to spell out the margins, the
| paddings, the borders, the...
| troupo wrote:
| Because you honestly don't need to, and shouldn't need
| to.
|
| CSS missed out on scoping, nesting, and composition even
| though most of these things have been available elsewhere
| (notably, SASS) for 20 or more years.
|
| What you really want is to have a component and all
| styles scoped to it. In the absence of that you want as
| few names replicating scoping, nesting, and composition,
| as possible. _And_ you want to compose repeatable
| patterns across all of your components (something that is
| possible with mixins, and is impossible with vanilla
| CSS). So you cut down on repetition across class names
| until you 're left with utility classes and a separation
| of concerns that cuts a different way:
| https://x.com/simonswiss/status/1664736786671869952
|
| Note: no one is stopping you from having your own
| arbitrary classes when you need to. See e.g. Cube CSS
| approach https://piccalil.li/blog/cube-css/
| skydhash wrote:
| What I'm arguing about is that composition isn't
| necessary in most cases. Because all components evolve
| independently. Also nesting is syntactic sugar, nice, but
| orthogonal to these discussions. And scoping is done with
| selectors.
|
| CSS isn't an imperative language. It's a declarative one.
| And what's most important is understanding what it is
| trying to solve (mostly not styling elements with tag's
| style). Which is what Tailwind is replicating.
|
| Tailwind may help you in some cases, but not because of a
| defect in CSS. It's like using an ORM, then past a
| certain treshold, you find yourself doing (badly) SQL but
| in $language.
| troupo wrote:
| > Also nesting is syntactic sugar, nice, but orthogonal
| to these discussions.
|
| What is it with you and nesting? We were talking about
| _scoping styles to a component_.
|
| > CSS isn't an imperative language. It's a declarative
| one.
|
| So what? Doesn't mean you can't provide nice declarative
| ways of doing things. Like SASS has provided for 20+
| years.
|
| > Which is what Tailwind is replicating.
|
| I fail to see the logic or, indeed, the meaning of your
| assertion.
| skydhash wrote:
| > _What is it with you and nesting? We were talking about
| scoping styles to a component._
|
| I get where you coming for. But the issue that the
| scoping[0] you're referring to on your other comment is
| something I've never encountered or heard someone
| complain about.
|
| In my mental model, an element owns it subtree in terms
| of styling. Meaning that, if I a component can be placed
| either statically or dynamically, then it belongs to all
| the elements that may be its parent. And if it want
| independent styles, then I reset it at the root of the
| component. So I assumes, any style property that is not
| set at the root of any element is inherited from the
| parent.
|
| No need for elaborate syntax and mechanisms that just
| drive up the complexity of the code.
|
| [0]: https://developer.mozilla.org/en-
| US/docs/Web/CSS/CSS_scoping
| troupo wrote:
| > But the issue that the scoping[0] you're referring to
| on your other comment is something I've never encountered
| or heard someone complain about.
|
| Why do you think BEM exists? Or CSS-inJS? Why do you
| think web components exist?
|
| All these are attempts to actually do what you claim css
| is already doing: to make sure that the element owns its
| subtree in terms of styling.
|
| CSS is _global_.
|
| > So I assumes, any style property that is not set at the
| root of any element is inherited from the parent.
|
| Of course not. The hint is in the name: _Cascading_
| stylesheets. Your "owned" subtree is owned by every
| single element above up to and including document root.
|
| > No need for elaborate syntax and mechanisms that just
| drive up the complexity of the code.
|
| There's nothing complex about Tailwind. It actually
| reduces all the complexity to a set of small primitives.
| And since it's still CSS, you can write your own CSS as
| you wish.
|
| Here's a good overview of how and why you would use it:
| https://piccalil.li/blog/cube-css/
| JimDabell wrote:
| How do you cope with page URLs, with JavaScript classes,
| variables, methods, Git branches, CSS filenames, image
| filenames, directory structure, etc.?
|
| I know the joke is that naming things is hard, but it
| really isn't and every web developer successfully and
| effortlessly names things all day long without even
| thinking about it.
|
| If I have a sidebar, coming up with the name "sidebar"
| for a CSS class is not a serious problem I need Tailwind
| to help me avoid. I don't find it plausible that other
| people genuinely feel pain over this _one particular
| instance_ of naming things without demanding solutions
| for all the other things they have to name. Can you point
| to many Tailwind advocates who complain about how
| difficult it is to pick filenames, or page URLs?
|
| I think it's really strange Tailwind advocates latch onto
| this one particular thing - naming things is a problem -
| when they seem to successfully name things all day long
| in every other context. It doesn't feel like a real
| problem. What happens when you need to create a file? Do
| you get paralysed by the myriad choices of filenames
| available? Or do you just pick a name and move on?
| 9dev wrote:
| Naming things involves creating an ontology that makes
| sense. In the context of URLs, that's an hierarchical
| structure of things that's self-describing; in the
| context of code, it's a direct model of the domain logic
| underlying the problem, at least for the most part:
| There's lots of code involving "managers" and
| "containers" and "controllers" and "factories". That's
| where it starts to get murky. Meanwhile, CSS classes
| require creating an ontology of things that's both
| reusable, and at the same time referring to small or
| partial aspects of a thing, sometimes a thing that shows
| up in other parts of the code, sometimes as a variation,
| or just a one-off occurrence. If you do it properly, that
| means you'll need to find a shared vocabulary for button
| attachments, centered max width wrappers, field hints,
| list items, and so on. It's draining, because it's not
| productive. The end result is just hopefully maintainable
| style sheets.
| skydhash wrote:
| It's draining because you're over-complicating things.
| CSS is for styling HTML. So however you structure your
| HTML, CSS closely follows (hierarchy of
| components/partials). Then you consider variants. After
| that, parents influencing children styles. Then on top of
| that, you add a reset (because small browser
| incompatibilities) and maybe a grid utility.
| IggleSniggle wrote:
| I don't do front end these days and don't really have a
| dog in this fight, but most code is nouns and verbs,
| while design choices are adjectives and adverbs. When the
| business decides that we need to run, not walk, you can
| just change the name of the function from walk to run
| instead while changing the code, if that seems
| appropriate. With CSS selectors, when the business
| decides we need to change the "feel" of the page from
| "spiky" to "gentle," you might only want to change some
| subset of the design that was built up around the "spiky"
| concept, while leaving others as they are. There is not a
| comprehensiveness and absoluteness to the changes, and
| it's a lot harder to reason about "pure functions".
|
| Add to this that CSS is like a codebase built on
| try/catch and throwing errors for its primary control
| flow mechanism, where the only thing that tames this is
| the naming conventions employed, and you've got a
| situation where the names really matter in a way that
| they don't when we're doing other programming, because
| the names are the only connective tissue to help you
| reason about the "control flow" once your css starts
| getting complex.
| immibis wrote:
| I still don't understand how not naming things is a
| benefit over inline styles? With inline styles, instead
| of class="bg-blue" you'd write style="background-
| color:blue" and then you could remove an entire build
| step and an entire dependency because the browser already
| supports this.
| chuckadams wrote:
| You can override bg-blue with a more specific selector or
| a user stylesheet, which you cannot do with inline
| styles.
| 9dev wrote:
| That; and also adjacent selectors, pseudo elements, media
| queries, variants, dark mode handling, state handling
| (hover, focus, etc.), and much more.
| immibis wrote:
| So you make the bg-blue style make things yellow?
| 9dev wrote:
| No, but your designers have decided instead of cornflower
| blue, they want it to be aqua instead. Have fun searching
| for all variants of the color in your stylesheets--
| including CSS varsity, hex codes and rgba variants. In
| Tailwind, all you need to do is update the config file,
| and it'll apply to backgrounds, text, shadows, anything.
| spiderfarmer wrote:
| Tailwind makes things like dark mode and group hover/focus
| states dead simple with modifiers (dark:, group-hover:),
| keeping all your logic in your HTML. With inline CSS, you'd
| need messy JS, extra classes, or bloated style tags to
| handle the same.
|
| It also enforces a design system (spacing, colors, fonts),
| while inline CSS often leads to small, inconsistent
| differences everywhere.
|
| It's a great solution to a problem a lot of people were
| having. That's why it's so popular.
| Sateeshm wrote:
| media and container queries. Pseudo selectors
| paavohtl wrote:
| CSS-in-JS (like how Styled Components and Emotion do it) is
| primarily a solution to code organization. It doesn't
| fundamentally change how CSS works.
| pier25 wrote:
| But it's a performance killer
|
| https://dev.to/srmagura/why-were-breaking-up-wiht-css-in-
| js-...
|
| Edit:
|
| See also this thread on Bluesky
|
| https://bsky.app/profile/infrequently.org/post/3lnehf53bpcl7
| MrJohz wrote:
| It can be, depending on how it's used. But most of the
| modern tools I've seen are specifically designed to compile
| away the dynamic aspects of CSS-in-JS, meaning it
| essentially becomes a different way of writing normal CSS.
| lelandfe wrote:
| > _Bandwidth graciously donated by mediatemple_
|
| I wonder what year this last was true.
| thm wrote:
| Mediatemple's cult-like following, despite their technical
| hiccups, was marvelous marketing work.
| lelandfe wrote:
| I still have vivid memories of their depiction of the top
| tier offering as a server filled with fire.
| tzury wrote:
| "Everything you love about Media Temple is now at GoDaddy."
|
| Oh lord..
|
| How far back will the Time Machine go today in this thread?
| swyx wrote:
| i wrote my own version where you can edit the CSS live and see it
| update :)
|
| https://svelte-zengarden.netlify.app/
|
| (click and drag on the writing hand emoji)
| __mharrison__ wrote:
| Wow! Haven't seen this since the slashdot days.
| tzury wrote:
| This site is old, and I mean it in a good way.
|
| This site was a "culture" shock for me, back in 200x and made me
| walk away from Microsoft ASP.NET and start building apps on
| linux, realizing all those "server controls" with inline style
| parameters were basically the complete wrong way, the "anti
| internet way".
|
| It was Alex Russell (creator of Dojo JS) who showed that side in
| one of the conferences, and I was shocked how much information I
| was missing while getting my technical news through Microsoft
| channels.
|
| For many years, my toolkit was simply Web.py, HTML, JS and CSS.
|
| We then got jQuery, and Backbone, and Underscore, till the React
| and then TS made new "Full stack" dumber again.
| tucnak wrote:
| Svelte now exists; it's a bit of a "clever" fullstack
| undebuggable wrote:
| > made me walk away from Microsoft ASP.NET and start building
| apps on linux, realizing all those "server controls" with
| inline style parameters were basically the complete wrong way,
| the "anti internet way".
|
| That's still online, although as an outdated relict:
| https://www.ajaxtoolkit.net/. There was no enterprise software
| without drag panel!
|
| For a moment semantic markup and CSS had taken the lead but
| nowadays I don't even care enough to check what the trends are.
| Stopped caring around the moment of "HTML inside JavaScript"
| (JSX).
| radicalbyte wrote:
| I started writing ASP & PHP, the whole ASP.Net thing was about
| helping Visual Studio developers make crappy web apps, it
| wasn't fit for purpose for the web writ large.
|
| You didn't _need_ to switch to Linux either; I built everything
| under Windows (IT didn 't allow Linux desktops) and deployed it
| to both Windows and Linux servers.
| wordofx wrote:
| > This site was a "culture" shock for me, back in 200x and made
| me walk away from Microsoft ASP.NET and start building apps on
| linux
|
| What stopped you from building such apps on Asp.net? It didn't
| prevent you from building anything like that. You could stop
| creates style sheets and separate JS files.
|
| > realizing all those "server controls" with inline style
| parameters were basically the complete wrong way, the "anti
| internet way".
|
| Ironically what's old is new again because we have literally
| gone full circle even down to nextjs? Recreating view state...
| and tailwind with inline styling and shadcn with react
| components.
| tzury wrote:
| Indeed. The famous asp.net "__VIEWSTATE" is now back to
| life...
| thm wrote:
| I had two designs there and to this day, I get emails from people
| seeking permission to reuse the CSS.
| pknerd wrote:
| CSS Zen Garden was the site that helped me to learn about the
| wonders of CSS.
| insin wrote:
| Did anyone ever do a good post-action write-up of how if you
| actually use the CSS Zen Garden technique for something which
| isn't a fixed target for demoing the power of CSS and the
| creativity of those who wield it, you end up with both HTML and
| CSS everyone is afraid to touch?
|
| When multiple different CSS layouts depend _deeply_ on the
| specific structure of the markup and the markup _needs_ to change
| over time, at the least you're in for pain, and at the most
| you're hosed/rewriting.
| milesrout wrote:
| The structure of the markup is dependent on the semantic
| structure of the content that is marked up. The CSS is styling
| that structure.
|
| The markup shouldn't need to change over time in a way that
| makes the CSS layouts not work because it just reflects the
| semantic structure of the document, which shouldn't really need
| to change. If it does you have quite a different document and
| so of course it will need CSS changes too.
|
| I was always much more afraid of touching ad-hoc CSS that was
| written alongside HTML, because it ends up having all these
| classes and elements that have no semantics and it becomes very
| unclear what anything actually _means_. The very worst is the
| "tailwind" styling where classes etc mean _nothing_ , just
| styling.
| oliwarner wrote:
| I disagree. Most websites are a "fixed target". Creating markup
| that clearly reflects this and then styling that isn't hard.
|
| Maintaining CSS is easier than picking through markup trying to
| catch all the class names, especially if you use a preprocessor
| with nesting.
|
| Admittedly in my professional experience, CSS-only refreshes
| are rare, but in my case only because it's been more common to
| change the content at the same time.
| bpiroman wrote:
| Love this! Would be cool if somebody did a css zen garden 2.0
| using modern CSS tools. Oh and tailwind css is not aloud lol
| meekaaku wrote:
| As someone who learned CSS from Zen Garden and the likes of Eric
| Meyer, modern css tools like Tailwind looks like an anti pattern
| throwaway150 wrote:
| Absolutely! There are so many problems with Tailwind.
|
| The HTML is littered with styling information. Reading HTML
| should be about content and meaning, not knowing that "pl-16
| pr-8 bg-olive-500 text-gray-700" means "this is probably a card
| header". But... you might argue that people do not read HTML
| anymore. Yes, people don't read HTML anymore. Who would when
| the devs using this framework turn the HTML into a horrible
| mess! If you litter your HTML with so many framework classes,
| there is more noise than content in HTML. Is it a surprise that
| reading HTML has fallen out of fashion? And since nobody reads
| HTML anymore, devs are totally unhinged with cluttering it with
| more and more classes and styles. It's a self perpetuating
| cycle.
|
| Webdevs do style duplication rampantly. Instead of something
| like ".button", you'd find stuff like "text-white rounded bg-
| gray-aaa" littered throughout hundreds of places. I'm not sure
| if this is a Tailwind problem or dev problem but the problem
| definitely is there. A large project would soon reach a
| situation where if you want to make a style change across all
| similar UI elements it's a whack-a-mole game to find out which
| inline styles in which elements you need to look at.
| brailsafe wrote:
| I have a fairly strong grasp on CSS, at one point having what
| I felt was as close to as knowledgeable as I'd care to be
| about it, but one thing always stuck out as a neverending
| battle; style organization. I think Tailwind does have all
| those problems to some extent, but CSS alone didn't find
| cultural consensus around how best to implement it, always
| leaning on whichever flavour of the month conceptual
| framework that was often just one more system to try to
| manage. There's some virtue in writing the stuff you do
| cleanly, but sometimes it's just not as valuable to someone
| who's primarily doing what could be described as complex
| software development. Sometimes the marginal benefit to a
| clean implementation and a slightly messy redundant one of
| the same interactive caliber just isn't that important
| relatively, especially when the negative qualities are
| somewhat mitigated by component re-use and scoping.
| chuckadams wrote:
| I think it's the complex specificity rules that prompted
| things like TW to come about. Sure it's useful and powerful
| but it's utterly baffling to reason about, especially when
| everyone's conventions work at a different level of
| specificity. Trying to tame specificity gave us cumbersome
| structures like BEM, and TW came about as an act of
| rebellion against such things.
|
| Conversations about CSS complexity always remind of this
| quip: "Two CSS selectors walk into a bar. A bar stool on
| the other side of town falls over."
| ookblah wrote:
| yeah, and then one day you want .button, but with a
| variation. GREAT. but oh no, now there's this other button
| that has a little bit of a change but not enough to create a
| separate class. maybe we'll just inline it... but no, i need
| a mobile selector here or i have some complex hover style. i
| know, let's create a basic utility class to help me out here.
| hmm, starting to look suspiciously like tailwind...
|
| now multiply this problem by more people working on an app,
| with different isolated components that they never even
| dreamed of during css zen garden's time and this is how
| something arose. we've tried creating centralized css sheets
| and it just doesn't work at scale.
|
| so yeah, a necessary evil, but i wouldn't call it an anti-
| pattern. it grew out of real needs. we had bootstrap and all
| these css frameworks attempting to make "order" about of
| something that honestly after decades of working with i don't
| think can be ever be fully "clean". people just gotta move
| past it.
| chuckadams wrote:
| It's a culture problem with Tailwind devs: for a long time
| there was a crusade against `@apply` in favor of inlining
| every class. I think the reason was solely because TW's tree-
| shaking wasn't very capable then and did even worse with
| @apply, but the air was thick with specious "philosophical"
| justifications flying around for inlining all the things. The
| most typical was "it should always be done through a
| component toolkit", which of course just buries the problem
| in javascript -- not to mention doing it dynamically is
| incompatible with tree shaking, so you end up having to
| predeclare everything you use...
|
| Nowadays the anti-@apply contingent seems to have gone quiet,
| so it is possible to not only use TW and similar toolkits
| sanely (which has always been the case) but to even see
| people publicly advocating for sanity.
| troupo wrote:
| > Reading HTML should be about content and meaning, not
| knowing that "pl-16 pr-8 bg-olive-500 text-gray-700" means
| "this is probably a card header".
|
| Unlike vanilla CSS where you need to look at browser dev
| tools and computed styles to figure out why something is
| styled this way. Because of course it's not styled just by
| the `.jus-one__more--modifier`.
|
| And Tailwind is mostly there for people developing
| sites/apps, not reading final HTML. So all that is usually
| contained in the specific component.
| theyknowitsxmas wrote:
| I think it works well and is a good standard for companies with
| hundreds of people. Want to style everything one-off in a
| landing page go ahead.
| amjoshuamichael wrote:
| I think CSS tools like that appeal to people who learned web
| development in a kind of ad-hoc way. When I first started, I
| just wanted to make designs I had in my head. I kind of went
| from "header, text, and image on the page" to, "how do I center
| this?", "how do I change this color?", "how do I space these
| elements out?" It wasn't long before I had developed a toolkit
| of CSS ideas, but once you do that, you lose out on a lot of
| the finer details that make CSS work well. I knew how to work
| around weird issues using position: absolute and transform, but
| I wasn't familiar with block formatting contexts, or the
| intricacies of the box model. When all of your CSS knowledge is
| just band-aids placed on your other shoddy CSS knowledge,
| you're working on fumes. At that point, you could imagine the
| appeal of grabbing a prebuilt toolkit of composable styles that
| takes away your access a lot of the available CSS footguns.
|
| What changed things for me was reading an short online book-
| style series about learning HTML/CSS from the ground up. It
| introduced everything from first principles, and had an
| approach where they explained _why_ things were the way they
| were. They didn 't just give you their "top 10 ways to center a
| div" and ask you to leave. I read the whole thing in an
| afternoon and it changed the way I think about web development.
| For the life of me, I can't remember what the book was called.
| If anyone's read something similar I'd love a reference, it was
| a while ago now and I'd still like to reference it. I
| specifically remember them saying "display: block is like a
| word document, and display: flex is like how you'd expect
| things to work," which illuminated a lot for me, not just about
| the display property, but generally about the way HTML & CSS
| were designed.
| lotsoweiners wrote:
| > What changed things for me was reading an short online
| book-style series about learning HTML/CSS from the ground up.
|
| Do you remember which one? Your experience sounds a lot like
| mine and I'd love to learn CSS from first principles.
| amjoshuamichael wrote:
| Unfortunately, no :( I was hoping someone would recognize
| the book and reply...
| rendaw wrote:
| I feel like the main point of css zen garden was how, by
| maximizing your use of semantic HTML, you could separate the
| presentation from the content and operate on them completely
| independently.
|
| While you can still do this to the extent zen garden does, it's
| really operating within the limits of css (i.e. css can do this,
| therefore I can create this type of design, not I want this type
| of design, therefore I need to write this css).
|
| There are lots of style choices that require modifying the DOM
| directly to effect, and can't be done purely with CSS. I've seen
| discussions on W3C where it was like "Well if you add another div
| around this you can achieve this effect, so why do we need a new
| CSS property?". Stuff like inserting or swapping an image is
| simple, but swapping a styleable SVG is impossible because the
| SVG nodes need to be directly embedded in the html.
|
| So you're forced to mix presentation and content structuring
| decisions at the HTML and Javascript levels and even some simple
| design changes require modifications throughout the stack.
| zelphirkalt wrote:
| On the other hand CSS is very capable these days and many
| designs, that actually are not flying air castles and take the
| medium into account, can be implemented flawlessly using only
| CSS and HTML.
| leo-notte wrote:
| Agreed. A lot of modern web design problems come from trying
| to force a medium to do something it was never meant for. If
| you work with the grain of HTML and CSS instead of against
| it, you can still build really flexible and beautiful layouts
| without needing to hack the DOM or pile on JS. zen garden was
| a reminder of that and it still holds up.
| 90s_dev wrote:
| The CSS community's promise was always that structure and
| presentation can be separated.
|
| After my 30 years of writing GUIs, I'm now convinced that this
| is the wrong place to draw a dividing line.
|
| Instead, we should be isolating _intent_. This is what
| Composites do in my project. I 'm so excited to announce it
| next week!
| kalleboo wrote:
| Enter stage: XSLT
| mrfinn wrote:
| In the age of spaghetti-mixed Web Components, remember kids you
| can still be good with yourselves and properly split your Web
| Apps into individual CSS, JS, and HTML templates files, even
| going framework-less.
|
| Keep the Zen Torch on.
| antirez wrote:
| The idea of CSS Zen Garden, that was: to show that you can
| produce server side simple and semantic HTML, and CSS will be
| enough to do the rest for the presentation of the content, was an
| incredible innovation of 200x that was totally forgotten, and
| that now, younger generation of programmers that grown up with
| big web frameworks no longer "get". They see CSS as something
| complex and impossible to handle, exactly because of what modern
| HTML is (because of such frameworks), without realizing that this
| is indeed the same problem: that modern web sucks, not that CSS
| sucks.
| pavlov wrote:
| What changed was that "web 2.0" happened. Web design's focus
| changed from documents to applications.
|
| CSS Zen Garden was about styling "web 1.0" HTML documents.
|
| But dynamic UIs have completely different styling needs. People
| started building JavaScript applications, and they started
| needing UI layouts similar to those provided by desktop UI
| frameworks. And CSS was never designed for that. Concepts like
| "float" were entirely derived from the word processor universe.
| CSS had to add several complex new layout engines over the
| following decades.
| ta12653421 wrote:
| ++1
|
| One of the best websites back then, id guess even today?
|
| it was enlightening to work through this book, i even got a
| hardcopy of it from the local library while being a student
| uzyn wrote:
| Loved the site and the companion book. Borrowed it at my local
| library and kept renewing it. Taught me CSS, coming out of
| hacking CSS with all the weird tricks at that time, and made me
| realize that you _can_ make beautiful semantic websites without
| the crazy hacks.
| tiew9Vii wrote:
| CSS Zen Garden is the good old days of web when people cared.
|
| Now server side rendering is all the rage again, maybe we will
| also see a comeback of semantic html and simple stylesheets.
| martin-adams wrote:
| I wasn't sure how good CSS was and whether it would be good for
| layouts and such. Then I found the CSS Garden and it was the
| shining light that made me understand its power.
|
| Similarly, it was ExtJS that made me realise that web sites could
| be just as good as desktop apps.
| throwaway150 wrote:
| So happy to see CSS Zen Garden on HN today! Those were the days!
|
| But I've also got to rant now.
|
| What I find most troubling about Tailwind and CSS "frameworks"
| like it (and modern software development in general) is the
| growing pride in not understanding the underlying systems.
|
| Tailwind offers a quick, surface-level solution: you can slap
| some utility classes onto a page and get something that looks
| "good enough" without ever learning how CSS actually works.
| Nevermind that the HTML is now a mess where you've got more CSS
| classes than content!
|
| The attitude is, "Who cares how it works? I got my pretty page.
| That's a win!"
|
| But this isn't just a Tailwind problem. It's part of a larger
| trend in the industry: celebrating ignorance, rushing for results
| without building real understanding.
|
| When did not knowing become something to be proud of? Isn't it
| sad that depth and mastery are now treated as optional, even
| undesirable?
|
| /rant
| panstromek wrote:
| I get the idea, but don't think that's the case for Tailwind.
| Tailwind classes map directly to CSS properties, you can't
| really do much with it if you don't understand CSS
| throwaway150 wrote:
| Are you sure? Could it be confirmation bias because _you_ do
| understand the CSS?
|
| From what I've seen across multiple teams, it's very common
| for developers to just slap Tailwind onto their project,
| copy-paste classes they found online and call it "done."
| Maintainability and reusability are treated as someone else's
| problem.
| bcye wrote:
| Copy-pasting code and calling it done isn't limited to
| Tailwind though.
| budgi4 wrote:
| Software development is a layering of abstractions over time.
| How's your assembly?
| vacuity wrote:
| How's your Electron app's performance?
|
| It's very concerning when software developers neglect that
| their tools (abstractions) have _tradeoffs_.
|
| "If civil engineers built bridges the way software engineers
| build applications, the bridges would all fall down in a
| month".
|
| And similar sentiments. Granted, most things aren't mission-
| critical, but then just because my house won't collapse
| doesn't mean I want to waste money on poor insulation and
| broken appliances.
| kreetx wrote:
| This site had huge effect on me back in the day!
|
| For those who don't know: for the same html content you could
| submit a design in CSS and images. For example these impressed me
| the most:
|
| - https://csszengarden.com/202/
|
| - https://csszengarden.com/189/
|
| - https://csszengarden.com/177/
|
| - https://csszengarden.com/136/
|
| - https://csszengarden.com/206/
|
| There was also one which had a position: fixed knife "cutting the
| page from the middle" when you scrolled, but it doesn't seem to
| be on the list anymore. Edit: and another one I remember was like
| so that the top of the page is sea level and you'd scroll to the
| bottom of the sea, where there was either an octopus, a submarine
| or a diver, can't remember.
| pantulis wrote:
| There was a book by Dave Shea and Molly Holzschlag called "The
| zen of CSS design" that explained some of the tricks of the most
| amazing themes. On my last cleaning I let go of a lot of now
| obsolete books but that book remains, it's so beautiful!
| JimDabell wrote:
| There's an aspect of this that is not readily apparent unless you
| were a web developer around the time this was created.
|
| Before CSS, layouts were implemented by abusing table elements to
| create a grid. Then images were sliced up into sections, and each
| section was placed into the table. This has generally been
| remembered in the present day, however what seems to have been
| forgotten was the pushback against CSS.
|
| There was a large number of web developers who were happy with
| the status quo and refused to learn CSS. One of the most
| persistent myths was that you couldn't make anything look nice
| with CSS. Specifically, CSS was accused of only being able to
| create "boring, boxy" designs.
|
| It wasn't true at all. Even back in the early days of CSS, you
| could create great layouts. It was especially absurd because the
| approach favoured by the people saying this was literally abusing
| tables to create grids.
|
| So along comes Dave Shea and points out that this is ridiculous,
| that CSS is capable of great designs, and puts the CSS Zen Garden
| up. A whole bunch of people contribute good-looking designs and
| make it impossible for people to claim that "CSS can only produce
| boring, boxy designs". I think it's amusing that he won the
| argument so conclusively that people forget it was even an
| argument in the first place.
| kreetx wrote:
| I'm fuzzy on the timeline, but _there was_ a time where the
| emerging CSS wasn 't up to the task of creating more complex
| layouts (no flexbox, not to speak of the grid). CSS Zen Garden
| was just there to show what _could be_ done by that point.
| JimDabell wrote:
| Things have certainly gotten easier, but even back then CSS
| had things like pseudo-elements and display: table-cell. The
| main problem was Internet Explorer 6 holding everybody back
| so floats were the main way of laying things out, and those
| go back to CSS 1 (1996).
| Macha wrote:
| floats and clearfix were plenty powerful even before flexbox,
| despite not being intended for the purpose.
|
| But then, neither were tables.
| jonwinstanley wrote:
| Ahhh yes, floats were everything.
| unconed wrote:
| With all due respect to Dave, no. Please stop rewriting history
| without the relevant details.
|
| CSS Zen Garden is a project that demonstrated that "progressive
| enhancement" and "semantic HTML" were nonsense. The only reason
| something like CSS Zen Garden worked at all is because all the
| markup is fixed, all the content is static, and the designs are
| not really responsive.
|
| There is no CMS with a theming system that offers the
| flexibility that CSS Zen Garden claims one can have with a
| single .css, independent of the HTML. And this is because web
| developers were huffing the HTML/CSS gospel too much, fussing
| over not having extra divs in their source and what not, and
| celebrating "semantic HTML" without ever running their website
| through a screen reader.
|
| The reason people stopped using table layout when they were
| doing CSS is because CSS1 did not support the _most common way
| of doing layout at the time_, and IE6 held the web hostage for
| a decade. This is a remarkable thing because it means everyone
| hopped on this bandwagon despite it being very obviously ill-
| informed and not ready for production. The CSS Zen Garden era
| designs can be expected to be full of float/clear tricks,
| requiring careful layout dependency between elements so
| everything gets pushed down just far enough. And it looks
| exactly like the table-based layouts they were replacing,
| except they will scale improperly or not at all.
|
| The "status quo" attitude has also not vanished, as witnessed
| by CSS variables, custom properties and all the other epicycles
| that keep getting added on to CSS instead of actually just
| scrapping the parts that are dumb. None of these CSS experts
| have the vision or depth of experience to really know what it
| takes to implement what they spec, or what is even still
| relevant today and what isn't.
|
| I actually implemented my own web layout system for Use.GPU
| from scratch, with flexbox and blackjack and hookers, and it's
| remarkable how much of HTML/CSS you don't need, and also, how
| many parts of it are still laughably inadequate (like text-
| ellipsis).
|
| Dave did not win the argument. The people who celebrated CSS
| Zen Garden were cargo culters who confused a pretty design for
| a structurally sound layout, and who honestly just wanted
| something they could feel good about while dealing with pre-
| Firebug / pre-Dev Tools CSS development.
|
| There is a really easy way to test this too, and I would
| challenge Dave to do it: translate all the content to another
| language. See how many of those beautiful CSS-only designs fall
| apart.
| JimDabell wrote:
| This sounds less like you want to correct something I have
| said that was inaccurate and more like you have a fundamental
| disagreement with the design of CSS.
| unconed wrote:
| Where in your comment did you mention the IE angle? The
| effect of lack of dev tools? Where did you mention the
| boondoggle of CSS2 tables and how everyone had to learn a
| whole new way of making floats behave? Where did you
| mention the laundry lists of named hacks that people used
| to get around browser parser differentials?
|
| You didn't. You wrote the story as it is being told instead
| of how it happened.
|
| You just don't know what you're talking about.
| Griffinsauce wrote:
| > [IE] held the web hostage for a decade.
|
| I wonder whether we'll ever get to reach this point with
| Safari. Especially with regards to PWAs and the insane state
| of "native" apps.
| DaiPlusPlus wrote:
| If that's how your feel about CSS, what do you think about
| XSLT?
| unconed wrote:
| If that's your take away from the comment, then reading
| comprehension is dead.
| troupo wrote:
| XSLT was and still is amazing
| timeon wrote:
| You could easily make float/clear layout for dynamic content.
| unconed wrote:
| Pop quiz: make a 3 columns layout with fixed width header
| and sidebars, with a sticky footer at the bottom of the
| page, and which reaches full height even if the main
| content is shorter than the sidebar, or vice versa... even
| if the whole page is shorter than the browser. It must work
| in IE6-8.
|
| Spoiler: you can't.
| radicalbyte wrote:
| The reason we used tables was because getting things right in
| CSS in the early days across all of the browsers was a
| nightmare. An expensive nightmare. Which was fine if you were a
| well funded startup and could afford to rebuild your HTML
| regularly.
| brightball wrote:
| The "across all browsers" problem was such a huge pain. Not
| just for CSS but JS too.
|
| I still remember the campaign for sites to drop support for
| IE6 in protest.
| radicalbyte wrote:
| Yeah fun times.
|
| I kept our internal reporting site running for 3-4 years, I
| used CSS for layout.. it required regular maintenance but I
| had enough time to do it as my main job was as a Database
| Admin / Data Engineer (I'd have been called "devops
| engineer" nowadays as I had quite a broad set of
| responsibilities).
| padolsey wrote:
| It always felt like a fun challenge. For me, it was a crucial
| part of my love of the web (and eventually, programming): the
| hackability and the way that there was no canonical correct
| way to solve a given problem. I miss those days.
| suspended_state wrote:
| CSS at the time was still a leaky abstraction: in order to
| get things working, you had to include extraneous DIVs in the
| HTML code as anchors for the CSS rules. The standard body has
| attempted to address this issue with pseudo-elements and
| pseudo-classes as well as other features I may not be aware
| of.
|
| At least though, these extra DIVs weren't disrupting the page
| layout (eg. when disabling the CSS - something that was still
| possible at the time), which was beneficial for
| accessibility.
| elevaet wrote:
| I remember a time when using <div> tags was considered a sign
| of "expensive" to some.
| 90s_dev wrote:
| Not to mention that early on, CSS was _very_ lacking compared
| to today. We didn 't even have `border-radius` until something
| like 2011! Consider that this relatively simple site design[1]
| takes about _420 lines_ of modern CSS[2]. And that 's even
| using nesting, and liberal use of :has, which is a game
| changer. I remember having to restructure both my CSS _and_ my
| HTML to achieve appearances which were otherwise impossible to
| create in the intuitive way, all because of inherent
| limitations to CSS at the time.
|
| [1] https://90s.dev/
|
| [2] https://90s.dev/style.css
| katzgrau wrote:
| Re border radius... The coveted rounded corner, the mark of a
| really slick design before that property made it easy :D
|
| I think media queries/responsive is what did in the last
| bastion of CSS resistors.
| darau1 wrote:
| Modern CSS makes me long for Hi5 to make a comback. My
| profile would be killer.
| immibis wrote:
| Creating a grid is exactly the purpose of a table, not an
| abuse.
| padolsey wrote:
| Semantically speaking, tables are supposed to contain tabular
| data, not to be used solely for their layout capabilities.
| That's why it's called an abuse.
| Sharlin wrote:
| > Tables have existed as part of web standards since the HTML
| 3.2 standard (January 1997). The standard referenced an
| earlier RFC and was intended to be compliant with the table
| tags Netscape had already added to their browser, but this
| was their official addition to the HTML standard.
|
| > The standard pointed out that tables could be used for
| tabular data or layout purposes, but cautioned that using
| them for layout would impact accessibility.
|
| > In HTML 4 (April 1998), this warning was strengthened to
| "Tables should not be used purely as a means to layout
| document content", and we were pointed to the addition of
| CSS1 to help accommodate this. It was noted, however, that
| using deprecated features was expected to continue for a
| little while [heh] in order to support older browsers
| (browser listed above).
|
| https://www.tiernok.com/posts/history-of-html-table-
| layouts....
| JimDabell wrote:
| An HTML table describes data that is related across multiple
| axes. A grid is a typical presentation for that data. That
| does not mean that creating a grid is the _purpose_ of a
| table, and it doesn't mean that any instance of a grid should
| be a table.
| throw310822 wrote:
| > layouts were implemented by abusing table elements to create
| a grid.
|
| Never understood what was actually wrong with it, apart from
| the whole "semantic html" yadda yadda that is meaningful for a
| small subset of applications.
| suspended_state wrote:
| >> layouts were implemented by abusing table elements to
| create a grid.
|
| > Never understood what was actually wrong with it
|
| Separation of concerns?
| Sharlin wrote:
| On the contrary, semantics are very important from
| accessibility point of view.
| jdance wrote:
| Yeah me neither, I think the CSS being cool and hard to use
| was the real reason. People like being "elite", and tables
| were just dead simple.
|
| I am surprised people here still hold on to that era of CSS.
| There are even people in the comments being proud of clearfix
|
| But I should probably be thankful for CSS for getting me out
| of webdev early :)
| RyanOD wrote:
| An oldie but goodie. This was my first exposure to CSS and the
| foundation for the years I taught web design to low-income high
| schoolers. We would all go to an end-of-the-year web design
| competition at the local community college. The kids would have
| to explain CSS to the judges because they had no idea. :)
|
| Many students walked away winning desktop computers (available
| due to computer lab upgrades). Probably the proudest
| accomplishments of my career.
|
| If I remember right, I actually sent a few questions to Dave
| Shea, Eric Meyer, Andy Budd, etc and they replied with help.
| Forever grateful.
| fmxsh wrote:
| When I first heard of CSS in a brief discussion, background-
| repeat and background-position felt like liberation and magic,
| but also as a strange thing intruding into HTML, as techniques
| specific to HTML had become tradition, like layout using tables
| and the 1-pixel gif method to create borders.
|
| Then, later, CSS Zen Garden was very impressive to me, given my
| limited understanding of CSS.
___________________________________________________________________
(page generated 2025-04-28 23:02 UTC)