9 ms·

Old CSS, new CSS (2020)

201 points by Tomte 3y ago

dang 3y ago
Related: Old CSS, New CSS (2020) - https://news.ycombinator.com/item?id=29531941 https://news.ycombinator.com/item?id=29531941 - Dec 2021 (97 comments) Old CSS, New CSS - https://news.ycombinator.com/item?id=22215931 https://news.ycombinator.com/item?id=22215931 - Feb 2020 (244 comments)
dhosek 3y ago
Kind of reminds me of my thinking (back in 1995) that I wanted to write a browser that would have a menu option to show what the output would look like with different browsers (this was back before writing a browser was essentially writing an operating system). I remember some really awful attempts at styling before CSS, the worst being <font size=+1><ol></font> item text to change the size of the list bullets (which, of course, only worked on Netscape and broke rendering entirely on other browsers).
lovegrenoble 3y ago
I'm using "display:flex" on almost everything, and as you said, flexbox is suitable for almost every situation. Also, for anyone struggling with flexbox - I use this tool to streamline the process: https://flexboxcss.com https://flexboxcss.com
- o11c 3y ago
  I only dabble in HTML, but for the kinds of layout I find myself doing, grid comes up more than flex does. Subgrid is needed for some tasks, but poorly supported still. Container queries are a less-limited alternative to media queries. When writing custom rules for other people's websites (using the Stylus extension), elem[attr=value] and variants (^=, etc) are very useful. :has() is useful for styling the parent of the actual element with the attributes but not in all browsers yet. Last I checked it is still not possible in the wild to implement fully automatic dark-mode (etc.) theming (using HSL) even though colorspaces are in the spec for the relevant functions.
  - lelanthran 3y ago
    > I only dabble in HTML, but for the kinds of layout I find myself doing, grid comes up more than flex does. It depends on whether the content is fixed to desktop monitors or responsive to mobile screens. Grid doesn't give the same responsiveness flexibility when the page is displayed on mobile. In my experiments with grid vs flexbox, every single time I used grid, I had to switch over to flexbox the minute I needed the content to display on mobile screens. My usage of grid turned out to be simply a different form of tables, which don't work well (or at all) on mobile screens.
    - o11c 3y ago
      What I did with grid was use media (or container, easier to debug at top level and necessary when nested) queries to do a completely separate layout for the same DOM when the viewport (or parent) was too small horizontally. The problem with flex is that it means "adjacent" elements can randomly wrap anywhere even if they really belong close to each other, whereas with grid I could arrange for closeness separately for each available horizontal size.
      - lelanthran 3y ago
        > The problem with flex is that it means "adjacent" elements can randomly wrap anywhere even if they really belong close to each other, whereas with grid I could arrange for closeness separately for each available horizontal size. I don't put down a flex and leave it at that; I use media queries to change it between flex-horizontal and flex-vertical. This means that I either wrap at particular width for desktop, or "wrap" at every cell for mobile. Granted, it's not perfect as it only supports two classes of screen size - desktop or mobile :-)
- kmoser 3y ago
  I prefer this one since it shows you the resulting HTML/CSS markup, and lets you change the number of flex items: https://flexbox.tech/ https://flexbox.tech/
- Akronymus 3y ago
  I recently started at a new job where I need to do a lot of stuff in the frontend (sadly). Flexbox is a lifesaver, except when it isn't (I didn't know grid was a thing until last night, but it really solved a usecase I struggled with quite a bit with a flexbox)
audiodude 3y ago
I distinctly remember working at a company where I had to upload the new assets for our rounded buttons, which were a grid of 3x3 image elements. LOL clearfix. I also never really had to fight with IE 6 compatibility, but when I fought it, it fought back hard. Also explaining to designers why we can't do translucent backgrounds (also IE 6).
- Brajeshwar 3y ago
  Ah, Yes, the 3x3. Whenever this pops up, I remember a lot of fond memories of the early days of front-end development. I wrote about ours at https://brajeshwar.com/2005/splice9-bitmap-window-resizer-component-01b/ https://brajeshwar.com/2005/splice9-bitmap-window-resizer-co... I remember “feathering” the curves in Photoshop for a smoother finish to the rounded corners. My team, especially the new ones, would go -- heck, the trick, the trick, we learn a trick. ;-) The struggles were real, and the fun was short and intermittent but worth every moment.
  - uxcolumbo 3y ago
    Good ol’ times. A list apart, yayhooray, … and your articles helped me learn web design.
  - wildrhythms 3y ago
    Pre-drop shadow we had to cut out static images of the shadow too. And let's hope you never have to change the background that the shadow sits on!
- Inviz 3y ago
  there was a way to use package image in a non-standard way (iirc using Offsets in Photoshop) and use negative background position to emulate 3x3 grid image with less elements. Was an advanced technique.
  - Klonoar 3y ago
    You mean CSS sprite sheets, or is there another technique that I somehow missed all these years?
josephg 3y ago
I'm wondering if we'll ever see Houdini make its way into browsers. The idea is that instead of modern CSS, the browser provides a bunch of hooks for various parts of its layout engine. You can then provide custom code that uses those hooks to implement any layout system you want. CSS is big and complex, and it still needs to support the whole legacy of web applications going back forever. Most applications just use a tiny subset of CSS. Houdini could allow smaller, faster layout engines with none of the legacy stuff. And because your app ships its own layout engine, if there's a feature you want, you can just add it to the layout engine and it'll instantly work in every browser. I have no idea whats happened with it though. Now that flexbox, grid, sticky and a few other things are in all browsers, CSS feels good enough. But maybe I'm lacking imagination. https://developer.mozilla.org/en-US/docs/Web/API/Houdini_APIs https://developer.mozilla.org/en-US/docs/Web/API/Houdini_API... Oh, it looks like chrome and safari both already support a lot of Houdini: https://houdini.glitch.me/ https://houdini.glitch.me/
- nicoburns 3y ago
  The one thing I'd really like for web layout is a "stretch unit" that works similarly to CSS Grid's fr units in that it would be defined as "taking up a proportion of available space after other siblings have been sized" except: - It would have no automatic minimum, so it would actually be equivalent to minmax(0, 1fr) (this would make it much more performant, avoiding the exponential time complexity of many existing CSS layout modes. - It could be used for the width/height properties (and potentially other places such as margin/padding/inset) If you had that along with a simplified 1-dimensional display mode (i.e. like flexbox except with the flexing disabled) then I think most people probably wouldn't want much more in most circumstances. Houdini is interesting, but as someone who has spent a lot of the last year implementing a web layout engine [0], I'm a little skeptical that JS is ever going to be fast enough to really compete with built-in layout modes. It could be an interesting use case for WASM if the problem of passing data into the WASM VM cheaply (perhaps by reference) can be solved. [0]: https://github.com/DioxusLabs/taffy https://github.com/DioxusLabs/taffy
  - josephg 3y ago
    > It could be an interesting use case for WASM if the problem of passing data into the WASM VM cheaply (perhaps by reference) can be solved. WASM Reference Types should hopefully solve this. The WASM working group seems to have some good momentum - so I'm hopeful this (or a similar replacement spec) will land sooner rather than later. https://github.com/WebAssembly/reference-types/blob/master/proposals/reference-types/Overview.md https://github.com/WebAssembly/reference-types/blob/master/p...
blackoil 3y ago
Interestingly, both IE and NN had `box-sizing: border-box;` as default behaviour, and at least for me that was sensible behavior. Probably a better decision at that point would have been to update spec and add a quirks mode other way around.
- JimDabell 3y ago
  border-box was the original behaviour in an early draft of the specification, but it was changed to content-box before final publication. Browsers that jumped the gun and released with draft behaviour got it wrong. And it wasn’t default behaviour so much as the only behaviour – the box-sizing property that allowed web developers to control this came a long time afterwards.
- CM30 3y ago
  Even the folks working on the specifications now think border-box should have been the default behaviour: https://wiki.csswg.org/ideas/mistakes https://wiki.csswg.org/ideas/mistakes The only reason it's not is because of backwards compatibility.
kmoser 3y ago
> Let’s say you wanted all your <h1>s to be red, across your entire site. You had to do this: <H1><FONT COLOR=red>...</FONT></H1> …every single goddamn time. Hope you never decide to switch to blue! This was never a big problem for me because in those days I wrote Perl scripts to generate my pages. I just defined $h1_color = 'red' and ran the script to crank out the static HTML pages. Boss (me :) wants to change the color to blue? Just change 'red' to 'blue' and re-run the script.
- cqqxo4zV46cp 3y ago
  Your own, worse, CSS, that requires a build toolchain. You were ahead of your time!
  - codegeek 3y ago
    To be fair, things like SASS and LESS have been out there for a while. Tailwind requires build in production.
    - cuu508 3y ago
      I think we're talking 1995-2000 here, not 2006 (when sass appeared), 2009 (when less appeared), or 2018 (when Tailwind appeared)
  - bmacho 3y ago
    It isn't easy: - to have no build toolchain - to work without javascript - to have single configuration points
tunesmith 3y ago
> Generating CSS with JavaScript was a possibility, but boy oh boy is that ever a bad idea. lol. As a backend developer that pretends to be full-stack, I enjoyed the hell out of reading this. CSS is such a mosh pit that it's just about impossible to find a summary of why things developed as they did. Plus I feel curiously reinforced about the times I've come at this with fresh backendy ideas, asking frontend devs "uh, why are we doing it this way?" and they only make strangled noises in response.
- temporallobe 3y ago
  As a mostly front-end person who knows CSS pretty well, it’s still baffling as to why things developed the way they did and why there are so many ways to do certain things like layout. The sheer number of layout options and their inherent quirks make designing any site or app from scratch a nightmare. This is why most modern applications use layout engines like Bootstrap or foundation (especially because it does most of the responsive design for you).
  - p9fus 3y ago
    Is there anything in specific you can point to in terms of layout? IME Most of the time you can just `display: flex` or `display: grid` (and then tweak the necessary properties on the children) and it generally works well.
- Akronymus 3y ago
  As a full stack dev that wants to be backend: Fully agree with you there. Frontend is so much more of a pain for me than backend because so much of it just seems bad in terms of usability for no real reason.
  - ttfkam 3y ago
    On the frontend, the users control the execution environment. On the backend, developers control the execution environment. It had to be this way for the web to scale the way it did. Most developers are control freaks. "I put in input, and the computer does what I say." Far more so than the general population, I think. That lack of control on the frontend will predictably not be looked on highly by many in our profession. I think those who are more comfortable having a more loose grip on their environment tend to be more comfortable with front end development—more accepting the state of how things are, not some elegant and provable state that can be verified to the nth degree. We've molded and shaped our world in the backend to be as predictable and controllable as possible. Arguably, the frontend is more representative of the real world and its compromises.
hnatiukr 3y ago
> Oh, and everyone wrote HTML tags in all caps. I don’t remember why we all thought that was a good idea. Maybe this was before syntax highlighting in text editors was very common (read: I was 12 and using Notepad), and uppercase tags were easier to distinguish from body text. The use of uppercase HTML tags in the early days wasn't primarily due to memory concerns. It was more about readability and consistency. As HTML evolved, lowercase tags became the standard for better readability and compatibility with XML. Another point that in the early days of computing, memory was a precious resource, and every byte mattered. Some developers believed that using uppercase characters could save memory because uppercase letters have simpler representations in ASCII, occupying fewer bits. However, this difference was extremely marginal and hardly made a noticeable impact on memory usage.
- bazoom42 3y ago
  What? Upppercase and lowercase occupy the same amount of bits. ASCII uses 7 bits for all characters (although in practice 8 bits).
  - fallous 3y ago
    In the early days of computing ASCII was not universally used and often character spaces were less than 8 bits and lacked lower-case, or were mixed charsets like PETSCII that had upper-case letters and the extra charspace were filled with graphics. For a text-only system you could store the doc with 6 bit chars since you could ignore the upper charspace populated with graphics.
    - josephg 3y ago
      Was this ever true for HTML?
    - bazoom42 3y ago
      This was long before HTML though. HTML was always at least ASCII.
      - 3y ago
p4bl0 3y ago
> It [Firefox] was quick, it was simple, it was much more standard-compliant, and absolutely none of that mattered. > > No, Firefox really got a foothold because it had tabs. The article doesn't mention it but at this time, equally attractive along with tabs, was the pop-up blocker! Truly the first ad-blocker like thing. And it was awesome too :).
ramesh31 3y ago
God bless CSS. I mean just look at the alternatives. There's really nothing else in existence with such power and flexibility. Any time I spend in native land it's always a feeling of pure freedom and enjoyment coming back to the web platform.
- mdhb 3y ago
  Flutter is a nice alternative I found in that a lot of thought really went into how to design a UI framework from the ground up using everything we now have learned over the years about what works, what is important and without having to worry about backwards compatibility but could take a greenfield approach. With that one exception I otherwise agree, CSS especially in 2024 is actually very nice to use for the most part.
  - ttfkam 3y ago
    It's hilarious to me that even with 25 years of engineering hindsight, you can only point to one framework that has executed well enough to be considered superior to CSS. With 20 years of prior art to look at, new options should be better by default. What does it say about our industry when the vast majority of "replacements" are not?
huksley 3y ago
Awesome read! And yes, :has() is supported now by all major browsers. https://developer.mozilla.org/en-US/docs/Web/CSS/:has https://developer.mozilla.org/en-US/docs/Web/CSS/:has
- Dalewyn 3y ago
  Keeping in mind that "all" major browsers is Chrome, Chrome, Chrome, Chrome, Firefox, Chrome, Chrome, Safari, and Chrome.
  - teddyh 3y ago
    I feel there’s a Monty Python parody there somewhere.
  - tgv 3y ago
    And that there are so many people with older browsers. And there is no easy polyfill for :has.
    - ttfkam 3y ago
      Not as many as you'd think. Chrome's automatic update a decade and a half ago really changed the game from when folks had to manually upgrade. IE 11 installs are getting real small and typically have enterprise IT teams to help them out. I'm sure there's some poor souls out there still using Windows XP, best wishes to them, but I'm not devoting any engineering hours on their behalf. Just like folks running a 57 Chevy, you're welcome to it, but you're responsible for its maintenance, upkeep, and road-worthiness from here on out. If that's how you want to spend your time, all the best. Just don't go complaining that the Bluetooth doesn't work.
      - tgv 3y ago
        It's not about IE11. :has() is not available on Safari before 15.4 and Firefox before 121. Nor Samsung before 20. That's all reasonably new, and many people, especially on mobile, can't update.
divbzero 3y ago
Does anyone know the history of the Space Jam website? I’m curious who created it and which blessed souls have kept it up for so long. (May its existence never be relegated to the Wayback Machine…)
sussmannbaka 3y ago
Fast forward a few years and > <H1><FONT COLOR=red>...</FONT></H1> …every single goddamn time. is in fashion again! Only now it’s called class="text-red-500" :o)
- mdhb 3y ago
  I do continue to find it weird how CSS is just relegated to this second class citizen when it comes to web development and huge numbers of folks seemingly have little to no interest in learning it beyond what they can copy and paste. That wouldn’t fly in any other language.
  - mtsr 3y ago
    For me a big part is that global CSS doesn’t match component based web applications as well. Coordinating global class names becomes a pain quickly. Then you move to scoped CSS and suddenly CSS doesn’t add much anymore.
    - naasking 3y ago
      > Coordinating global class names becomes a pain quickly. In other words, CSS class names are the new global variables. I like that framing. Everything old is indeed new again.
    - bryanrasmussen 3y ago
      >Coordinating global class names becomes a pain quickly. However scoped css variables does add quite a lot. So I'm thinking that can't be the scoping you were thinking of?
    - ttfkam 3y ago
      Better not to think of it as global variables and more like annotations for cross-cutting concerns. That said, don't blame CSS just because React treated it like a second class citizen. Try Svelte. Matches the components there perfectly. It really is amazing to use a web framework that doesn't hate the platform it's written for.
  - 3y ago
4ndrewl 3y ago
Thank you for this. I had totally forgotten about "web safe colors"!
JimDabell 3y ago
> A year and a half later, in mid ‘98, we were gifted CSS 2. (I love the background on this page, by the way.) This was a modest upgrade that addressed a few deficiencies in various areas, but most interesting was the addition of a couple positioning primitives: the position property, which let you place elements at precise coordinates, and the inline-block display mode, which let you stick an element in a line of text like you could do with images. inline-block was actually introduced in CSS 2.1, which came a few years after CSS 2.
chris_wot 3y ago
In the comments the guy who invented quirks mode actually explains its history! Someone update Wikipedia, please… I cannot.
qznc 3y ago
Variables are not mentioned. What if you want to use the same color for backgrounds here, border there, and text there? CSS can do that today with something like var(--my-color). To me, that makes a CSS build unnecessary. Sorry, sass and co.
- FractalHQ 3y ago
  Custom properties are great until you need to access them from JavaScript and realize it’s impossible and are sent back to the drawing board. After building countless design systems with CSS/SCSS/Tailwind/Svelte/SASS/PostCSS/etc, I’m convinced that CSS as a separated language in separate files needs to die. I’m building an experimental design system in pure Typescript and I feel like I’m finally able to free my UI from the Stone Age. I’m sure I’ll be back to the drawing board again soon enough.
- wildrhythms 3y ago
  Indeed, and you can have fallback values like var(--my-color, #B22222) and combined with calc() you can do some amazing things in pure CSS.
- mtsr 3y ago
  Right, this and native nesting support.
temporallobe 3y ago
Funny there’s no mention of SASS or SCSS.
ramses0 3y ago
A few other memories: The Netscape 4 "missing closing table tag of doom" whereby omitting a closing table tag would cause the whole document not to render. https://www.webmasterworld.com/css/234.htm https://www.webmasterworld.com/css/234.htm Especially cromulent because in the absence of ANY other layout or styling control, the common mechanism were to effectively play nested games of tic-tac-toe with tables, valign=center (you never had it so good!), and if you were lucky, html-tidy on the command line for debugging. The other "woulda coulda shoulda" is referenced here, circa 2004-ish was passing CSS for "JSS". https://levelup.gitconnected.com/a-brief-history-of-css-in-js-how-we-got-here-and-where-were-going-ea6261c19f04 https://levelup.gitconnected.com/a-brief-history-of-css-in-j... ...references are tough to find, but I believe Mozilla/NS attempted to push (and had a short-lived branch) for JS-based styling language. ie: body.style.background = "white" and using that as THE language for writing "stylesheets". IIRC: Microsoft basically outright refused because they had the MS-Word people who envisioned the "CSS-as-books" universe (and had effectively infinite senior programmers to work on implementing "the cascade") while Netscape was smaller, scrappier, and more interested in an _effective_ web, not a _perfect_ web. Very tough to find original sources for it as it was before search engines and with web-decay, sites aren't referenced. Microsoft held the web back by at least a decade by EEE (embrace, extend, extinguish), but launched it forward (accidentally) again by forgetting that they'd implemented XHR, which allowed AJAX and the rest of the interactive techniques. You haven't lived until you've had a convicted monopolist with rooms full of lawyers who sat in a room debating whether to arbitrarily snuff out your company by suing you into oblivion for making something compatible with their browser (once you've grown juuust big enough, and seen your peer companies destroyed after crossing a threshold). THAT's why there's such a lingering, smoldering distaste for Microsoft. They intentionally broke the interoperable internet, and intentionally smashed innovative technology with dual clubs called "legal" and "finanacial". The other fun bits as competitor technologies in the proto-internet era were: BBS's with ANSI graphics, then "RipScript" as proto-SVG. Followed by Prodigy, which was effectively a proto-browser (with its own vector-like rendering capabilities). Even gopher, a more text-based browsing experience, was a competitor to Mosaic 1.0, as nobody knew what the internet was supposed to be back then. Along with lynx, and links, which are conceptually awesome, except that CSS (layout vs hierarchy) and JS (interaction vs declaration) have rendered (har har) them obsolete. Can't forget to mention AOL-server (with TCL), and NSS... Netscape Secure Server, which invented(!) SSL and for a while was the only way to serve secure traffic. Absolutely unavailable to the hobbyist, as it was a very expensive product. There's few alternate outcomes, but open source, and monopolist financial capture have skewed the web we have now. If I could have a magic wand, I'd shoot for 402-Payment-Required, and would be hesitant to encourage truly global (universal) aggregation of content for searching. We're in a duality where "only google" can download and index the whole internet every day and "only facebook" has access to "the facebooks". Facebook having a business incentive to trap event data, and merchant/for-sale data behind a login requirement is a huge loss for the open internet. Google being "the gatekeeper" to navigating (omni-box + advertising replacing DNS) is also a loss for the open internet. Don't believe me? Try and set your browser homepage in chrome. It'll only ever open it up ONCE, when the browser opens for the first time. Not for new tabs, not for new windows, not without a janky extension.
65 3y ago
I've been writing CSS for over 10 years, and I still battle with certain issues all the time (mostly flexbox, images, and positioning). CSS is easy to learn but almost impossible to master.
- ttfkam 3y ago
  Layout has always been easy to learn but difficult to master. This has been true since long before the advent of CSS and the web. You think the folks working at newspapers of record never had to hack something up to make it fit right above the fold? And their output targets were static!

201 points by Tomte 3y ago

dang 3y ago

Related: Old CSS, New CSS (2020) - https://news.ycombinator.com/item?id=29531941 https://news.ycombinator.com/item?id=29531941 - Dec 2021 (97 comments) Old CSS, New CSS - https://news.ycombinator.com/item?id=22215931 https://news.ycombinator.com/item?id=22215931 - Feb 2020 (244 comments)

dhosek 3y ago

Kind of reminds me of my thinking (back in 1995) that I wanted to write a browser that would have a menu option to show what the output would look like with different browsers (this was back before writing a browser was essentially writing an operating system). I remember some really awful attempts at styling before CSS, the worst being <font size=+1><ol></font> item text to change the size of the list bullets (which, of course, only worked on Netscape and broke rendering entirely on other browsers).

lovegrenoble 3y ago

I'm using "display:flex" on almost everything, and as you said, flexbox is suitable for almost every situation. Also, for anyone struggling with flexbox - I use this tool to streamline the process: https://flexboxcss.com https://flexboxcss.com

o11c 3y ago
I only dabble in HTML, but for the kinds of layout I find myself doing, grid comes up more than flex does. Subgrid is needed for some tasks, but poorly supported still. Container queries are a less-limited alternative to media queries. When writing custom rules for other people's websites (using the Stylus extension), elem[attr=value] and variants (^=, etc) are very useful. :has() is useful for styling the parent of the actual element with the attributes but not in all browsers yet. Last I checked it is still not possible in the wild to implement fully automatic dark-mode (etc.) theming (using HSL) even though colorspaces are in the spec for the relevant functions.
- lelanthran 3y ago
  > I only dabble in HTML, but for the kinds of layout I find myself doing, grid comes up more than flex does. It depends on whether the content is fixed to desktop monitors or responsive to mobile screens. Grid doesn't give the same responsiveness flexibility when the page is displayed on mobile. In my experiments with grid vs flexbox, every single time I used grid, I had to switch over to flexbox the minute I needed the content to display on mobile screens. My usage of grid turned out to be simply a different form of tables, which don't work well (or at all) on mobile screens.
  - o11c 3y ago
    What I did with grid was use media (or container, easier to debug at top level and necessary when nested) queries to do a completely separate layout for the same DOM when the viewport (or parent) was too small horizontally. The problem with flex is that it means "adjacent" elements can randomly wrap anywhere even if they really belong close to each other, whereas with grid I could arrange for closeness separately for each available horizontal size.
    - lelanthran 3y ago
      > The problem with flex is that it means "adjacent" elements can randomly wrap anywhere even if they really belong close to each other, whereas with grid I could arrange for closeness separately for each available horizontal size. I don't put down a flex and leave it at that; I use media queries to change it between flex-horizontal and flex-vertical. This means that I either wrap at particular width for desktop, or "wrap" at every cell for mobile. Granted, it's not perfect as it only supports two classes of screen size - desktop or mobile :-)
kmoser 3y ago
I prefer this one since it shows you the resulting HTML/CSS markup, and lets you change the number of flex items: https://flexbox.tech/ https://flexbox.tech/
Akronymus 3y ago
I recently started at a new job where I need to do a lot of stuff in the frontend (sadly). Flexbox is a lifesaver, except when it isn't (I didn't know grid was a thing until last night, but it really solved a usecase I struggled with quite a bit with a flexbox)

audiodude 3y ago

I distinctly remember working at a company where I had to upload the new assets for our rounded buttons, which were a grid of 3x3 image elements. LOL clearfix. I also never really had to fight with IE 6 compatibility, but when I fought it, it fought back hard. Also explaining to designers why we can't do translucent backgrounds (also IE 6).

Brajeshwar 3y ago
Ah, Yes, the 3x3. Whenever this pops up, I remember a lot of fond memories of the early days of front-end development. I wrote about ours at https://brajeshwar.com/2005/splice9-bitmap-window-resizer-component-01b/ https://brajeshwar.com/2005/splice9-bitmap-window-resizer-co... I remember “feathering” the curves in Photoshop for a smoother finish to the rounded corners. My team, especially the new ones, would go -- heck, the trick, the trick, we learn a trick. ;-) The struggles were real, and the fun was short and intermittent but worth every moment.
- uxcolumbo 3y ago
  Good ol’ times. A list apart, yayhooray, … and your articles helped me learn web design.
- wildrhythms 3y ago
  Pre-drop shadow we had to cut out static images of the shadow too. And let's hope you never have to change the background that the shadow sits on!
Inviz 3y ago
there was a way to use package image in a non-standard way (iirc using Offsets in Photoshop) and use negative background position to emulate 3x3 grid image with less elements. Was an advanced technique.
- Klonoar 3y ago
  You mean CSS sprite sheets, or is there another technique that I somehow missed all these years?

josephg 3y ago

I'm wondering if we'll ever see Houdini make its way into browsers. The idea is that instead of modern CSS, the browser provides a bunch of hooks for various parts of its layout engine. You can then provide custom code that uses those hooks to implement any layout system you want. CSS is big and complex, and it still needs to support the whole legacy of web applications going back forever. Most applications just use a tiny subset of CSS. Houdini could allow smaller, faster layout engines with none of the legacy stuff. And because your app ships its own layout engine, if there's a feature you want, you can just add it to the layout engine and it'll instantly work in every browser. I have no idea whats happened with it though. Now that flexbox, grid, sticky and a few other things are in all browsers, CSS feels good enough. But maybe I'm lacking imagination. https://developer.mozilla.org/en-US/docs/Web/API/Houdini_APIs https://developer.mozilla.org/en-US/docs/Web/API/Houdini_API... Oh, it looks like chrome and safari both already support a lot of Houdini: https://houdini.glitch.me/ https://houdini.glitch.me/

nicoburns 3y ago
The one thing I'd really like for web layout is a "stretch unit" that works similarly to CSS Grid's fr units in that it would be defined as "taking up a proportion of available space after other siblings have been sized" except: - It would have no automatic minimum, so it would actually be equivalent to minmax(0, 1fr) (this would make it much more performant, avoiding the exponential time complexity of many existing CSS layout modes. - It could be used for the width/height properties (and potentially other places such as margin/padding/inset) If you had that along with a simplified 1-dimensional display mode (i.e. like flexbox except with the flexing disabled) then I think most people probably wouldn't want much more in most circumstances. Houdini is interesting, but as someone who has spent a lot of the last year implementing a web layout engine [0], I'm a little skeptical that JS is ever going to be fast enough to really compete with built-in layout modes. It could be an interesting use case for WASM if the problem of passing data into the WASM VM cheaply (perhaps by reference) can be solved. [0]: https://github.com/DioxusLabs/taffy https://github.com/DioxusLabs/taffy
- josephg 3y ago
  > It could be an interesting use case for WASM if the problem of passing data into the WASM VM cheaply (perhaps by reference) can be solved. WASM Reference Types should hopefully solve this. The WASM working group seems to have some good momentum - so I'm hopeful this (or a similar replacement spec) will land sooner rather than later. https://github.com/WebAssembly/reference-types/blob/master/proposals/reference-types/Overview.md https://github.com/WebAssembly/reference-types/blob/master/p...

blackoil 3y ago

Interestingly, both IE and NN had `box-sizing: border-box;` as default behaviour, and at least for me that was sensible behavior. Probably a better decision at that point would have been to update spec and add a quirks mode other way around.

JimDabell 3y ago
border-box was the original behaviour in an early draft of the specification, but it was changed to content-box before final publication. Browsers that jumped the gun and released with draft behaviour got it wrong. And it wasn’t default behaviour so much as the only behaviour – the box-sizing property that allowed web developers to control this came a long time afterwards.
CM30 3y ago
Even the folks working on the specifications now think border-box should have been the default behaviour: https://wiki.csswg.org/ideas/mistakes https://wiki.csswg.org/ideas/mistakes The only reason it's not is because of backwards compatibility.

kmoser 3y ago

> Let’s say you wanted all your <h1>s to be red, across your entire site. You had to do this: <H1><FONT COLOR=red>...</FONT></H1> …every single goddamn time. Hope you never decide to switch to blue! This was never a big problem for me because in those days I wrote Perl scripts to generate my pages. I just defined $h1_color = 'red' and ran the script to crank out the static HTML pages. Boss (me :) wants to change the color to blue? Just change 'red' to 'blue' and re-run the script.

cqqxo4zV46cp 3y ago
Your own, worse, CSS, that requires a build toolchain. You were ahead of your time!
- codegeek 3y ago
  To be fair, things like SASS and LESS have been out there for a while. Tailwind requires build in production.
  - cuu508 3y ago
    I think we're talking 1995-2000 here, not 2006 (when sass appeared), 2009 (when less appeared), or 2018 (when Tailwind appeared)
- bmacho 3y ago
  It isn't easy: - to have no build toolchain - to work without javascript - to have single configuration points

tunesmith 3y ago

> Generating CSS with JavaScript was a possibility, but boy oh boy is that ever a bad idea. lol. As a backend developer that pretends to be full-stack, I enjoyed the hell out of reading this. CSS is such a mosh pit that it's just about impossible to find a summary of why things developed as they did. Plus I feel curiously reinforced about the times I've come at this with fresh backendy ideas, asking frontend devs "uh, why are we doing it this way?" and they only make strangled noises in response.

temporallobe 3y ago
As a mostly front-end person who knows CSS pretty well, it’s still baffling as to why things developed the way they did and why there are so many ways to do certain things like layout. The sheer number of layout options and their inherent quirks make designing any site or app from scratch a nightmare. This is why most modern applications use layout engines like Bootstrap or foundation (especially because it does most of the responsive design for you).
- p9fus 3y ago
  Is there anything in specific you can point to in terms of layout? IME Most of the time you can just `display: flex` or `display: grid` (and then tweak the necessary properties on the children) and it generally works well.
Akronymus 3y ago
As a full stack dev that wants to be backend: Fully agree with you there. Frontend is so much more of a pain for me than backend because so much of it just seems bad in terms of usability for no real reason.
- ttfkam 3y ago
  On the frontend, the users control the execution environment. On the backend, developers control the execution environment. It had to be this way for the web to scale the way it did. Most developers are control freaks. "I put in input, and the computer does what I say." Far more so than the general population, I think. That lack of control on the frontend will predictably not be looked on highly by many in our profession. I think those who are more comfortable having a more loose grip on their environment tend to be more comfortable with front end development—more accepting the state of how things are, not some elegant and provable state that can be verified to the nth degree. We've molded and shaped our world in the backend to be as predictable and controllable as possible. Arguably, the frontend is more representative of the real world and its compromises.

hnatiukr 3y ago

> Oh, and everyone wrote HTML tags in all caps. I don’t remember why we all thought that was a good idea. Maybe this was before syntax highlighting in text editors was very common (read: I was 12 and using Notepad), and uppercase tags were easier to distinguish from body text. The use of uppercase HTML tags in the early days wasn't primarily due to memory concerns. It was more about readability and consistency. As HTML evolved, lowercase tags became the standard for better readability and compatibility with XML. Another point that in the early days of computing, memory was a precious resource, and every byte mattered. Some developers believed that using uppercase characters could save memory because uppercase letters have simpler representations in ASCII, occupying fewer bits. However, this difference was extremely marginal and hardly made a noticeable impact on memory usage.

bazoom42 3y ago
What? Upppercase and lowercase occupy the same amount of bits. ASCII uses 7 bits for all characters (although in practice 8 bits).
- fallous 3y ago
  In the early days of computing ASCII was not universally used and often character spaces were less than 8 bits and lacked lower-case, or were mixed charsets like PETSCII that had upper-case letters and the extra charspace were filled with graphics. For a text-only system you could store the doc with 6 bit chars since you could ignore the upper charspace populated with graphics.
  - josephg 3y ago
    Was this ever true for HTML?
  - bazoom42 3y ago
    This was long before HTML though. HTML was always at least ASCII.
    - 3y ago

p4bl0 3y ago

> It [Firefox] was quick, it was simple, it was much more standard-compliant, and absolutely none of that mattered. > > No, Firefox really got a foothold because it had tabs. The article doesn't mention it but at this time, equally attractive along with tabs, was the pop-up blocker! Truly the first ad-blocker like thing. And it was awesome too :).

ramesh31 3y ago

God bless CSS. I mean just look at the alternatives. There's really nothing else in existence with such power and flexibility. Any time I spend in native land it's always a feeling of pure freedom and enjoyment coming back to the web platform.

mdhb 3y ago
Flutter is a nice alternative I found in that a lot of thought really went into how to design a UI framework from the ground up using everything we now have learned over the years about what works, what is important and without having to worry about backwards compatibility but could take a greenfield approach. With that one exception I otherwise agree, CSS especially in 2024 is actually very nice to use for the most part.
- ttfkam 3y ago
  It's hilarious to me that even with 25 years of engineering hindsight, you can only point to one framework that has executed well enough to be considered superior to CSS. With 20 years of prior art to look at, new options should be better by default. What does it say about our industry when the vast majority of "replacements" are not?

huksley 3y ago

Awesome read! And yes, :has() is supported now by all major browsers. https://developer.mozilla.org/en-US/docs/Web/CSS/:has https://developer.mozilla.org/en-US/docs/Web/CSS/:has

Dalewyn 3y ago
Keeping in mind that "all" major browsers is Chrome, Chrome, Chrome, Chrome, Firefox, Chrome, Chrome, Safari, and Chrome.
- teddyh 3y ago
  I feel there’s a Monty Python parody there somewhere.
- tgv 3y ago
  And that there are so many people with older browsers. And there is no easy polyfill for :has.
  - ttfkam 3y ago
    Not as many as you'd think. Chrome's automatic update a decade and a half ago really changed the game from when folks had to manually upgrade. IE 11 installs are getting real small and typically have enterprise IT teams to help them out. I'm sure there's some poor souls out there still using Windows XP, best wishes to them, but I'm not devoting any engineering hours on their behalf. Just like folks running a 57 Chevy, you're welcome to it, but you're responsible for its maintenance, upkeep, and road-worthiness from here on out. If that's how you want to spend your time, all the best. Just don't go complaining that the Bluetooth doesn't work.
    - tgv 3y ago
      It's not about IE11. :has() is not available on Safari before 15.4 and Firefox before 121. Nor Samsung before 20. That's all reasonably new, and many people, especially on mobile, can't update.

divbzero 3y ago

Does anyone know the history of the Space Jam website? I’m curious who created it and which blessed souls have kept it up for so long. (May its existence never be relegated to the Wayback Machine…)

sussmannbaka 3y ago

Fast forward a few years and > <H1><FONT COLOR=red>...</FONT></H1> …every single goddamn time. is in fashion again! Only now it’s called class="text-red-500" :o)

mdhb 3y ago
I do continue to find it weird how CSS is just relegated to this second class citizen when it comes to web development and huge numbers of folks seemingly have little to no interest in learning it beyond what they can copy and paste. That wouldn’t fly in any other language.
- mtsr 3y ago
  For me a big part is that global CSS doesn’t match component based web applications as well. Coordinating global class names becomes a pain quickly. Then you move to scoped CSS and suddenly CSS doesn’t add much anymore.
  - naasking 3y ago
    > Coordinating global class names becomes a pain quickly. In other words, CSS class names are the new global variables. I like that framing. Everything old is indeed new again.
  - bryanrasmussen 3y ago
    >Coordinating global class names becomes a pain quickly. However scoped css variables does add quite a lot. So I'm thinking that can't be the scoping you were thinking of?
  - ttfkam 3y ago
    Better not to think of it as global variables and more like annotations for cross-cutting concerns. That said, don't blame CSS just because React treated it like a second class citizen. Try Svelte. Matches the components there perfectly. It really is amazing to use a web framework that doesn't hate the platform it's written for.
- 3y ago

4ndrewl 3y ago

Thank you for this. I had totally forgotten about "web safe colors"!

JimDabell 3y ago

> A year and a half later, in mid ‘98, we were gifted CSS 2. (I love the background on this page, by the way.) This was a modest upgrade that addressed a few deficiencies in various areas, but most interesting was the addition of a couple positioning primitives: the position property, which let you place elements at precise coordinates, and the inline-block display mode, which let you stick an element in a line of text like you could do with images. inline-block was actually introduced in CSS 2.1, which came a few years after CSS 2.

chris_wot 3y ago

In the comments the guy who invented quirks mode actually explains its history! Someone update Wikipedia, please… I cannot.

qznc 3y ago

Variables are not mentioned. What if you want to use the same color for backgrounds here, border there, and text there? CSS can do that today with something like var(--my-color). To me, that makes a CSS build unnecessary. Sorry, sass and co.

FractalHQ 3y ago
Custom properties are great until you need to access them from JavaScript and realize it’s impossible and are sent back to the drawing board. After building countless design systems with CSS/SCSS/Tailwind/Svelte/SASS/PostCSS/etc, I’m convinced that CSS as a separated language in separate files needs to die. I’m building an experimental design system in pure Typescript and I feel like I’m finally able to free my UI from the Stone Age. I’m sure I’ll be back to the drawing board again soon enough.
wildrhythms 3y ago
Indeed, and you can have fallback values like var(--my-color, #B22222) and combined with calc() you can do some amazing things in pure CSS.
mtsr 3y ago
Right, this and native nesting support.

temporallobe 3y ago

Funny there’s no mention of SASS or SCSS.

ramses0 3y ago

A few other memories: The Netscape 4 "missing closing table tag of doom" whereby omitting a closing table tag would cause the whole document not to render. https://www.webmasterworld.com/css/234.htm https://www.webmasterworld.com/css/234.htm Especially cromulent because in the absence of ANY other layout or styling control, the common mechanism were to effectively play nested games of tic-tac-toe with tables, valign=center (you never had it so good!), and if you were lucky, html-tidy on the command line for debugging. The other "woulda coulda shoulda" is referenced here, circa 2004-ish was passing CSS for "JSS". https://levelup.gitconnected.com/a-brief-history-of-css-in-js-how-we-got-here-and-where-were-going-ea6261c19f04 https://levelup.gitconnected.com/a-brief-history-of-css-in-j... ...references are tough to find, but I believe Mozilla/NS attempted to push (and had a short-lived branch) for JS-based styling language. ie: body.style.background = "white" and using that as THE language for writing "stylesheets". IIRC: Microsoft basically outright refused because they had the MS-Word people who envisioned the "CSS-as-books" universe (and had effectively infinite senior programmers to work on implementing "the cascade") while Netscape was smaller, scrappier, and more interested in an _effective_ web, not a _perfect_ web. Very tough to find original sources for it as it was before search engines and with web-decay, sites aren't referenced. Microsoft held the web back by at least a decade by EEE (embrace, extend, extinguish), but launched it forward (accidentally) again by forgetting that they'd implemented XHR, which allowed AJAX and the rest of the interactive techniques. You haven't lived until you've had a convicted monopolist with rooms full of lawyers who sat in a room debating whether to arbitrarily snuff out your company by suing you into oblivion for making something compatible with their browser (once you've grown juuust big enough, and seen your peer companies destroyed after crossing a threshold). THAT's why there's such a lingering, smoldering distaste for Microsoft. They intentionally broke the interoperable internet, and intentionally smashed innovative technology with dual clubs called "legal" and "finanacial". The other fun bits as competitor technologies in the proto-internet era were: BBS's with ANSI graphics, then "RipScript" as proto-SVG. Followed by Prodigy, which was effectively a proto-browser (with its own vector-like rendering capabilities). Even gopher, a more text-based browsing experience, was a competitor to Mosaic 1.0, as nobody knew what the internet was supposed to be back then. Along with lynx, and links, which are conceptually awesome, except that CSS (layout vs hierarchy) and JS (interaction vs declaration) have rendered (har har) them obsolete. Can't forget to mention AOL-server (with TCL), and NSS... Netscape Secure Server, which invented(!) SSL and for a while was the only way to serve secure traffic. Absolutely unavailable to the hobbyist, as it was a very expensive product. There's few alternate outcomes, but open source, and monopolist financial capture have skewed the web we have now. If I could have a magic wand, I'd shoot for 402-Payment-Required, and would be hesitant to encourage truly global (universal) aggregation of content for searching. We're in a duality where "only google" can download and index the whole internet every day and "only facebook" has access to "the facebooks". Facebook having a business incentive to trap event data, and merchant/for-sale data behind a login requirement is a huge loss for the open internet. Google being "the gatekeeper" to navigating (omni-box + advertising replacing DNS) is also a loss for the open internet. Don't believe me? Try and set your browser homepage in chrome. It'll only ever open it up ONCE, when the browser opens for the first time. Not for new tabs, not for new windows, not without a janky extension.

65 3y ago

I've been writing CSS for over 10 years, and I still battle with certain issues all the time (mostly flexbox, images, and positioning). CSS is easy to learn but almost impossible to master.

ttfkam 3y ago
Layout has always been easy to learn but difficult to master. This has been true since long before the advent of CSS and the web. You think the folks working at newspapers of record never had to hack something up to make it fit right above the fold? And their output targets were static!