6 ms·

Every time I hear someone complain about CSS I just know they've never used it in the IE6/7 days. Good lord, the amount of hacks, shims, fallbacks, polyfill, ob

Every time I hear someone complain about CSS I just know they've never used it in the IE6/7 days. Good lord, the amount of hacks, shims, fallbacks, polyfill, obscure stuff you had to do to make it work in IE6, IE7, and my absolute favourite(!) the IE7 compatibility mode which was like IE6 but not quite! Ever since the wide adoption of stuff like flexbox and grid I haven't dared to complain about not getting stuff to work.

taf2 5y ago
zoom:1;float:right; There it’s fixed
deanclatworthy 5y ago
Ah you young ones only supporting IE6. I still have trauma from supporting IE5!
- jozzy-james 5y ago
  ie 5...mac edition :shudder:
- username91 5y ago
  position:relative on everything if you wanted it to be visible. var undefined; Fun times.
- asddubs 5y ago
  that's nothing, back in my day we had to manually carve the website layout into clay tablets
crispyambulance 5y ago
I remember the dumpster-fire days too. The thing that I can't understand is, why did it take SO LONG to get useable, proper, and intuitive CSS-based layout on web-pages? I mean, we've had all kinds of rock-solid mechanisms for layout in desktop applications since the dawn of GUI's in the NINETEEN EIGHTIES. Meanwhile, in CSS, people had resort to HTML tables up until sometime in the early naughts, when AWFUL, counterintuitive float-based hacks were part of the "Web 2.0" buzz. For Christ's sake, just getting fixed side-bars and a width-adaptive central area was called "The Holy Grail" by CSS experts. Isn't that the one of the most fundamental layouts GUI's-- AKA "The Docpanel"? It wasn't possible to get really nice layout without crazy hacks until flexbox in 2010-ish? Finally, a few years after flexbox, CSS grid comes out, and oopsie, we weren't supposed to use flexbox for overall layout anyway. Now it's CSS-grid for 2D (page layout), Flexbox for 1D (component layout), and floats for what they were originally intended for (putting pictures into a block of text and have the text flow around the pictures). To be fair, I actually like CSS now. It seems like it's really reached a point where you don't have to cling tightly to somebody's zany overcomplicated framework and can pretty much execute your will without frenetic trial and error. So NOW it's a success, but it's distressing that I feel CSS deserves nothing more than a sarcastic SLOW CLAP?
- dmitriid 5y ago
  > The thing that I can't understand is, why did it take SO LONG to get useable, proper, and intuitive CSS-based layout on web-pages? Many reasons: - HTML and CSS are not designed for anything complex. HTML and CSS at their core are only meant to display a static page of text and some images in a single rendering pass on a computer from 1990s. - Many decisions in CSS (especially early CSS) are one-off solutions that might not even have correct specifications compared to how people usually use it Float is really a one-off solution for a very specific subset of layout. The standard box model famously has a default that no one in real world uses, and that IE actually got right. There are more: https://pavpanchekha.com/blog/css-problems.html https://pavpanchekha.com/blog/css-problems.html and https://www.impressivewebs.com/css-the-bad-parts/ https://www.impressivewebs.com/css-the-bad-parts/ - Any solution has to be aware of any previous solution and mistake Let's say, you introduce flex. How will it work with floats? What about display:inline or display:inline-block? Tables? Inside tables? Let's say you introduce grid. All the question above plus all the questions on how it will behave with flex. Let's say you introduce... - Standards are mostly driven by browser implementors, who are not known for any/much of web work. Additionally, solutions have to be "fully complete including edge cases that maybe one person in the world cares about". Cant' find the link for that, sorry, you'd have to take me at my word :) - All that still has to work reasonably fast for some definition of fast, including all the weird interactions between mistakes and other workarounds of past, present, and future For example, Cassowary constraint solving algorithm for layouts was proposed in 1999, but was rejected because it was deemed too costly to process.
  - crispyambulance 5y ago
    > HTML and CSS are not designed for anything complex. Yeah, I believe you, I can see how that would have been the thinking back in the 90's. But there started to be significant web applications in the early 2000's. It's all water under the bridge now, but what if there had been more "throwing away" (deprecation) of the bad stuff and less mitigation with the whims of browser implementors? I feel like we would be in a better position today. What if the W3C had taken a more standards-based approach with hard PASS/FAIL requirements on styling/layout/semantics rather than "recommendations" that browser implementors have always taken as optional and subject to interpretation?
orware 5y ago
I had been trying to get into Tailwind CSS in recent projects but noticed some of the Bootstrap functionality I tend to like was missing out of the box so with Bootstrap 5 coming out last week I switched gears to start using that for a new project. The project itself is an update to an older one that was originally built with Bootstrap 2. For the old one, when I go to print the somewhat detailed tables I'm using show up fine, but in the new Bootstrap 5 version, one of the tables sticks outside of it's container when going to print and for the life of me I've been struggling to figure out a solution that works consistently for the print side of things (which I feel tends to be overlooked quite a bit in regards to CSS). What's even odder, is that when I implement a change that helps with the second table (making it appear contained within the page dimensions) the first table above starts exhibiting the issue of it being outside of the container. Also, in this case, if I were to leave the default styling of the "table-responsive" div containing the table, you wouldn't be able to see the rest of the columns at all when printing (since the scrollbar would show up) so everything I'm describing above is with an override to have "overflow-x: visible" when printing. Some other suggestions online included adding some overrides that use "page-break-inside: avoid;" for tables/tr/td/div elements and "display:block !important;" for the body and div elements but I'm not completely happy with those results, but yup that's been a bit frustrating trying to sort out since I'm not even sure why it's behaving the way it is at the moment. I haven't kept up fully with all of the Sass/SCSS advancements in recent years but have a semi-decent CSS foundation to build off of (from my understanding those advancements primarily help with some additional programmatic elements that then get pre-processed back into CSS? Along with some syntactic sugar to simplify some of the repetitiveness that CSS can require). The other big annoyance I was dealing with was related to what appears to be a long-standing WebKit issue related to scrollbars on mobile devices? (for the theme I'm using, I'd scroll down on an iOS device and wouldn't be able to see the very last item in the mobile menu). I found a reference somewhere (probably Stack Overflow of course) that mentioned using "@supports (-webkit-touch-callout: none)" to try and target the mobile browsers specifically and I reduced the height by an extra 65px or so which seemed to be enough to help with that particular issue (the theme utilizes "perfect scrollbar" it seems, but not entirely sure about all of the styles involved). (Before settling on this solution I had already tried out the solution described over here: https://allthingssmitty.com/2020/05/11/css-fix-for-100vh-in-mobile-webkit/ https://allthingssmitty.com/2020/05/11/css-fix-for-100vh-in-...). One last item I was dealing with this week seems to have to do with SVG rendering on the desktop vs. on mobile (for a logo). We sort of have a designer on staff but he deals more with print than with web stuff so I asked for a variation of our logo with the name of the application integrated into it and provided back to me as an SVG (since the PNG I had created myself looked slightly fuzzy when it was downscaled to fit the space I was using it in on the page, so I felt an SVG version would look crisper). After swapping things to the SVG version provided to me, it looks pretty good on mobile, but on the desktop (both in Chrome and Firefox), things just don't look as good. Some resources online mention it could be related to the lower DPI of a desktop monitor vs. the retina type DPI of a mobile device, but I don't know...I also saw some mention of a "pixel hinting" approach that might be able to be utilized by the designer in Adobe Illustrator perhaps that might help as well so that's something I've asked him to give a try for me so we can see the results, but I was kind of disappointed about the way the SVG looked as well (and now that'll require a bit of extra time to research/learn/experiment about, rather than focusing more on the application I'm trying to actually build...but at the same time it's semi worth it at the moment since I'm hoping the foundation I'm building with this new web app will be utilized in a couple of other updates that I'd like to make over the coming year, but we'll see how it goes ;-). I'll postscript this message that I'm not a frontend dev, but since I'm basically a team of one with an eye for certain details/issues, I try and get these sorts of problems sorted out at the beginning of a project so they don't cause issues, but also as a team of one, I really wish that in addition to the backend frameworks that are available (Laravel in my case is the one I'm currently ramping up on, as it's the more or less leader on the PHP side), it would be nice to have a nice frontend option with "batteries included" for a developer to really utilize and not have to worry too much about (Bootstrap has probably been the closest in that regard...I do like a lot of what Tailwind CSS is doing though, and of course it's heavily promoted in the Laravel community, but I just found that it would require too much work for me and too much time...and my workplace isn't exactly software development focused so I have to pick my battles in that regard vs. spending a lot of time getting something basic going vs. getting something shipped for users to start using). Hopefully one day we'll be completely away from needing to do any sort of CSS hacks (and things have come an extremely long way in the past few years), but at the moment I wouldn't say things are completely hack free yet (at least for us non-100% frontend folks...you all might have some extra magic you can cook up on the fly to solve any problems encountered maybe using what's already available :-).
ehayes 5y ago
I've seen things you people wouldn't believe. Clearfix classes assigned to every element. I watched rounded rectangles built in Photoshop, sliced and exported to PNGs, then aligned with tables and a prayer. All those hacks will be lost in time, like tears in rain. Time to design.
ehayes 5y ago
Just to give the less grizzled devs among us an idea how much better things are today: 14-ish years ago we all wanted rounded corners, but there was no border-radius (or at least we couldn't use it because IE). So it seemed like the web was full of rounded corner tutorials, and all of them involved jumping through a bunch of hoops. This thread reminded me of this parody of rounded-corners called "How to Make Square Corners with CSS" containing their coveted 84 step process to beautiful square corners in CSS: http://web.archive.org/web/20071014004940/http://www.drivl.com/posts/view/700 http://web.archive.org/web/20071014004940/http://www.drivl.c...
- asddubs 5y ago
  want a drop shadow on a div? no problem, just wrap it in 8 other divs and give each of them a different background for the sides and corners
jraph 5y ago
My favorite obscure thing: you sometimes had to add the zoom:1 CSS declaration so the element would "have layout", Whatever that meant, so it behaved the way you wanted. You also had the various filter: progid:DX… declarations to make things that came with other browsers work on IE using DirectX directives. This would, by the way, break the CSS syntax because of the colon in the value, but fortunately parsers of other browsers would recover at the right place. You could also run arbitrary JS in this filter property, too. I don't know how this would have worked with CSPs today. To add to the confusion, the filter property has since been repurposed, and the modern one is NOT related to the older, IE one. One of the biggest issues at the time was the non-standard box model that IE used and there was no way to tell other browsers to use this box model, nor to tell IE to use the standard box model. Now both can be used in any browser with box-sizing:border-box (the IE box model) or box-sizing: content-box (the default standard box model). I guess browsers needed to implement border-box for the quirks mode anyway. Conveniently, IE would happily load specific stylesheets declared in "conditional comments" so it could be possible to fix some things. Or you could use weird syntax like prefixing property names by a star, that the IE CSS parser would not mind but the other browsers ignore. Each version of IE had its specific quirks in its CSS parser so it was possible to target one version or another. Which is fortunate, because the rendering engine behaved very differently from version to version.
- goldenkey 5y ago
  The box-sizing property is actually very useful for when you want to reserve space in a percentage sized element with different sizing units. For example (in SASS CSS): .container { $footer-size: 2em; box-sizing: border-box; height: 100%; padding-bottom: $footer-size; .footer { position: absolute; bottom: 0 left: 0; height: $footer-size; } } Otherwise, one would have to use calc() which isn't supported in older browsers.
  - jraph 5y ago
    Absolutely. By the way, it seems many frontend developers generally prefer box-sizing:border-box, and Bootstrap sets it for all elements by default. Which can be a little disturbing when you don't know it, work on a project that includes bootstrap and you expect content-box. Fortunately, browser dev tools are good at telling you what is going on.

taf2 5y ago

zoom:1;float:right; There it’s fixed

deanclatworthy 5y ago

Ah you young ones only supporting IE6. I still have trauma from supporting IE5!

jozzy-james 5y ago
ie 5...mac edition :shudder:
username91 5y ago
position:relative on everything if you wanted it to be visible. var undefined; Fun times.
asddubs 5y ago
that's nothing, back in my day we had to manually carve the website layout into clay tablets

crispyambulance 5y ago

I remember the dumpster-fire days too. The thing that I can't understand is, why did it take SO LONG to get useable, proper, and intuitive CSS-based layout on web-pages? I mean, we've had all kinds of rock-solid mechanisms for layout in desktop applications since the dawn of GUI's in the NINETEEN EIGHTIES. Meanwhile, in CSS, people had resort to HTML tables up until sometime in the early naughts, when AWFUL, counterintuitive float-based hacks were part of the "Web 2.0" buzz. For Christ's sake, just getting fixed side-bars and a width-adaptive central area was called "The Holy Grail" by CSS experts. Isn't that the one of the most fundamental layouts GUI's-- AKA "The Docpanel"? It wasn't possible to get really nice layout without crazy hacks until flexbox in 2010-ish? Finally, a few years after flexbox, CSS grid comes out, and oopsie, we weren't supposed to use flexbox for overall layout anyway. Now it's CSS-grid for 2D (page layout), Flexbox for 1D (component layout), and floats for what they were originally intended for (putting pictures into a block of text and have the text flow around the pictures). To be fair, I actually like CSS now. It seems like it's really reached a point where you don't have to cling tightly to somebody's zany overcomplicated framework and can pretty much execute your will without frenetic trial and error. So NOW it's a success, but it's distressing that I feel CSS deserves nothing more than a sarcastic SLOW CLAP?

dmitriid 5y ago
> The thing that I can't understand is, why did it take SO LONG to get useable, proper, and intuitive CSS-based layout on web-pages? Many reasons: - HTML and CSS are not designed for anything complex. HTML and CSS at their core are only meant to display a static page of text and some images in a single rendering pass on a computer from 1990s. - Many decisions in CSS (especially early CSS) are one-off solutions that might not even have correct specifications compared to how people usually use it Float is really a one-off solution for a very specific subset of layout. The standard box model famously has a default that no one in real world uses, and that IE actually got right. There are more: https://pavpanchekha.com/blog/css-problems.html https://pavpanchekha.com/blog/css-problems.html and https://www.impressivewebs.com/css-the-bad-parts/ https://www.impressivewebs.com/css-the-bad-parts/ - Any solution has to be aware of any previous solution and mistake Let's say, you introduce flex. How will it work with floats? What about display:inline or display:inline-block? Tables? Inside tables? Let's say you introduce grid. All the question above plus all the questions on how it will behave with flex. Let's say you introduce... - Standards are mostly driven by browser implementors, who are not known for any/much of web work. Additionally, solutions have to be "fully complete including edge cases that maybe one person in the world cares about". Cant' find the link for that, sorry, you'd have to take me at my word :) - All that still has to work reasonably fast for some definition of fast, including all the weird interactions between mistakes and other workarounds of past, present, and future For example, Cassowary constraint solving algorithm for layouts was proposed in 1999, but was rejected because it was deemed too costly to process.
- crispyambulance 5y ago
  > HTML and CSS are not designed for anything complex. Yeah, I believe you, I can see how that would have been the thinking back in the 90's. But there started to be significant web applications in the early 2000's. It's all water under the bridge now, but what if there had been more "throwing away" (deprecation) of the bad stuff and less mitigation with the whims of browser implementors? I feel like we would be in a better position today. What if the W3C had taken a more standards-based approach with hard PASS/FAIL requirements on styling/layout/semantics rather than "recommendations" that browser implementors have always taken as optional and subject to interpretation?

orware 5y ago

I had been trying to get into Tailwind CSS in recent projects but noticed some of the Bootstrap functionality I tend to like was missing out of the box so with Bootstrap 5 coming out last week I switched gears to start using that for a new project. The project itself is an update to an older one that was originally built with Bootstrap 2. For the old one, when I go to print the somewhat detailed tables I'm using show up fine, but in the new Bootstrap 5 version, one of the tables sticks outside of it's container when going to print and for the life of me I've been struggling to figure out a solution that works consistently for the print side of things (which I feel tends to be overlooked quite a bit in regards to CSS). What's even odder, is that when I implement a change that helps with the second table (making it appear contained within the page dimensions) the first table above starts exhibiting the issue of it being outside of the container. Also, in this case, if I were to leave the default styling of the "table-responsive" div containing the table, you wouldn't be able to see the rest of the columns at all when printing (since the scrollbar would show up) so everything I'm describing above is with an override to have "overflow-x: visible" when printing. Some other suggestions online included adding some overrides that use "page-break-inside: avoid;" for tables/tr/td/div elements and "display:block !important;" for the body and div elements but I'm not completely happy with those results, but yup that's been a bit frustrating trying to sort out since I'm not even sure why it's behaving the way it is at the moment. I haven't kept up fully with all of the Sass/SCSS advancements in recent years but have a semi-decent CSS foundation to build off of (from my understanding those advancements primarily help with some additional programmatic elements that then get pre-processed back into CSS? Along with some syntactic sugar to simplify some of the repetitiveness that CSS can require). The other big annoyance I was dealing with was related to what appears to be a long-standing WebKit issue related to scrollbars on mobile devices? (for the theme I'm using, I'd scroll down on an iOS device and wouldn't be able to see the very last item in the mobile menu). I found a reference somewhere (probably Stack Overflow of course) that mentioned using "@supports (-webkit-touch-callout: none)" to try and target the mobile browsers specifically and I reduced the height by an extra 65px or so which seemed to be enough to help with that particular issue (the theme utilizes "perfect scrollbar" it seems, but not entirely sure about all of the styles involved). (Before settling on this solution I had already tried out the solution described over here: https://allthingssmitty.com/2020/05/11/css-fix-for-100vh-in-mobile-webkit/ https://allthingssmitty.com/2020/05/11/css-fix-for-100vh-in-...). One last item I was dealing with this week seems to have to do with SVG rendering on the desktop vs. on mobile (for a logo). We sort of have a designer on staff but he deals more with print than with web stuff so I asked for a variation of our logo with the name of the application integrated into it and provided back to me as an SVG (since the PNG I had created myself looked slightly fuzzy when it was downscaled to fit the space I was using it in on the page, so I felt an SVG version would look crisper). After swapping things to the SVG version provided to me, it looks pretty good on mobile, but on the desktop (both in Chrome and Firefox), things just don't look as good. Some resources online mention it could be related to the lower DPI of a desktop monitor vs. the retina type DPI of a mobile device, but I don't know...I also saw some mention of a "pixel hinting" approach that might be able to be utilized by the designer in Adobe Illustrator perhaps that might help as well so that's something I've asked him to give a try for me so we can see the results, but I was kind of disappointed about the way the SVG looked as well (and now that'll require a bit of extra time to research/learn/experiment about, rather than focusing more on the application I'm trying to actually build...but at the same time it's semi worth it at the moment since I'm hoping the foundation I'm building with this new web app will be utilized in a couple of other updates that I'd like to make over the coming year, but we'll see how it goes ;-). I'll postscript this message that I'm not a frontend dev, but since I'm basically a team of one with an eye for certain details/issues, I try and get these sorts of problems sorted out at the beginning of a project so they don't cause issues, but also as a team of one, I really wish that in addition to the backend frameworks that are available (Laravel in my case is the one I'm currently ramping up on, as it's the more or less leader on the PHP side), it would be nice to have a nice frontend option with "batteries included" for a developer to really utilize and not have to worry too much about (Bootstrap has probably been the closest in that regard...I do like a lot of what Tailwind CSS is doing though, and of course it's heavily promoted in the Laravel community, but I just found that it would require too much work for me and too much time...and my workplace isn't exactly software development focused so I have to pick my battles in that regard vs. spending a lot of time getting something basic going vs. getting something shipped for users to start using). Hopefully one day we'll be completely away from needing to do any sort of CSS hacks (and things have come an extremely long way in the past few years), but at the moment I wouldn't say things are completely hack free yet (at least for us non-100% frontend folks...you all might have some extra magic you can cook up on the fly to solve any problems encountered maybe using what's already available :-).

ehayes 5y ago

I've seen things you people wouldn't believe. Clearfix classes assigned to every element. I watched rounded rectangles built in Photoshop, sliced and exported to PNGs, then aligned with tables and a prayer. All those hacks will be lost in time, like tears in rain. Time to design.

ehayes 5y ago

Just to give the less grizzled devs among us an idea how much better things are today: 14-ish years ago we all wanted rounded corners, but there was no border-radius (or at least we couldn't use it because IE). So it seemed like the web was full of rounded corner tutorials, and all of them involved jumping through a bunch of hoops. This thread reminded me of this parody of rounded-corners called "How to Make Square Corners with CSS" containing their coveted 84 step process to beautiful square corners in CSS: http://web.archive.org/web/20071014004940/http://www.drivl.com/posts/view/700 http://web.archive.org/web/20071014004940/http://www.drivl.c...

asddubs 5y ago
want a drop shadow on a div? no problem, just wrap it in 8 other divs and give each of them a different background for the sides and corners

jraph 5y ago

My favorite obscure thing: you sometimes had to add the zoom:1 CSS declaration so the element would "have layout", Whatever that meant, so it behaved the way you wanted. You also had the various filter: progid:DX… declarations to make things that came with other browsers work on IE using DirectX directives. This would, by the way, break the CSS syntax because of the colon in the value, but fortunately parsers of other browsers would recover at the right place. You could also run arbitrary JS in this filter property, too. I don't know how this would have worked with CSPs today. To add to the confusion, the filter property has since been repurposed, and the modern one is NOT related to the older, IE one. One of the biggest issues at the time was the non-standard box model that IE used and there was no way to tell other browsers to use this box model, nor to tell IE to use the standard box model. Now both can be used in any browser with box-sizing:border-box (the IE box model) or box-sizing: content-box (the default standard box model). I guess browsers needed to implement border-box for the quirks mode anyway. Conveniently, IE would happily load specific stylesheets declared in "conditional comments" so it could be possible to fix some things. Or you could use weird syntax like prefixing property names by a star, that the IE CSS parser would not mind but the other browsers ignore. Each version of IE had its specific quirks in its CSS parser so it was possible to target one version or another. Which is fortunate, because the rendering engine behaved very differently from version to version.

goldenkey 5y ago
The box-sizing property is actually very useful for when you want to reserve space in a percentage sized element with different sizing units. For example (in SASS CSS): .container { $footer-size: 2em; box-sizing: border-box; height: 100%; padding-bottom: $footer-size; .footer { position: absolute; bottom: 0 left: 0; height: $footer-size; } } Otherwise, one would have to use calc() which isn't supported in older browsers.
- jraph 5y ago
  Absolutely. By the way, it seems many frontend developers generally prefer box-sizing:border-box, and Bootstrap sets it for all elements by default. Which can be a little disturbing when you don't know it, work on a project that includes bootstrap and you expect content-box. Fortunately, browser dev tools are good at telling you what is going on.