Today we have fun with three bite-sized topics to get you through your day. First, we look at how we define different types of technical debt. Then we look into Michael’s second least favorite topic in web development – carousels and sliders. This episode is rounded out with a rundown of some browser features that may not work the way you might otherwise suspect.
Types of Technical Debt (3:45)
Retiring Sliders (30:44)
- 10 Reasons Why You Need to Ditch Your Homepage Slider.
- Is It Time for Web Designers to Retire the Slider?
- Should I Use A Carousel
- Why Homepage Carousels Are Bad (& 3 Alternatives to Try Instead)
Weird Browser Behaviors (40:10)
- Permissions API:
- Plugging the CSS History Leak
- Web Features That May Not Work As You’d Expect
The following is a machine-generated transcript of this episode. It will contain errors until it has been reviewed and edited, and we apologize for the difficulty that may cause for screen readers. Do you want to help us speed up our transcribing process? Consider sponsoring an episode.
Welcome to the Drunken UX Podcast, everybody. This is episode number 94, and we’ve got three different things that we pulled from the web that we’re gonna be talking about with you tonight. We’re gonna be looking at different types of technical debt, some opinions on what we should be doing about sliders on web pages, and taking a look at some funky browser features folks. I am your host, Michael Fienen.
I’m still finding myself. I’m your other other host, Aaron.
And if you’re enjoying the Drunken UX Podcast, be sure to check out our very kind sponsors over at the live@Manning conference series. APIs right now are the backbone of modern interconnected software systems. You can join them at the API Live at manning conference and ensure your APIs. Are flexible functional, end user friendly.
If you want to register for the API conference, it is August 3rd, which if you’re listening to this on release day that is tomorrow. But those tickets are free and you can go get one by going to drunkenux.com/apiconf. That’s drunkenux.com/apiconf.
What’s the C I stand for?
then? What’s the O? Uh conference of Natural Functions?
No it’s not an abbreviation. Let’s see. Uh I am trying to cool off a little bit this evening with a I have a glass that you pour your water into and then you shove a silicone mold into it and you freeze the whole glass. Uh Yeah. Uh and it gives you like this wedge of ice, uh this angled wedge of ice in it. So I’m drinking from that this evening with some gentlemen jacket.
I don’t think I’ve seen that for like over a year.
Yeah, I kind of started melting already, but yeah, no, I haven’t used it in quite a while and I thought I’m going to get that out because it’s cold enough to hurt your hands when you’re holding it. But yeah, gentlemen, Jack, I’m running starting to run low on this bottle. So I figured let’s let’s see what I can do damage wise to it for this episode, although I am not finishing it because I do not want to die. Okay,
I’ve got weird, it’s not mixed, but I have both and I’m drinking them interchangeably. I’ve got a bottle of tequila, it’s a right Blanco tequila, it’s just like the basic deal at the liquor store kind of thing. It’s good, but I couldn’t margarita though, but I’m drinking it straight on the rocks with a very strange looking. It’s ice, right? Yeah. And then I’ve got um, some mountain dew voltage. It’s
That the Orange one.
No, it’s like a bluish color, but it doesn’t taste blew, it tastes like so coincidentally I also got some like Trolli sour Brite crawlers, like sour patch kids, but they’re like worms and this drink actually tastes a little bit like those but not sour, but it’s that kind of flavor. So I’m having a weird like flavor interaction thing tonight, but it’s interesting. I’m not mixing them, I’m drinking them
heart. Okay. Um, sure. I like to feel like I’m back in college sometimes too. So I mean I can’t, I can’t blame you. So we get three topics we’re going to tackle this evening. I have fun with these and went out and dug up some articles. This first article comes from Nicholas carrier. Um and I apologize if my french is not up to standard on that. Um this is from his blog post over at bite size theories dot com where he’s talking about three kinds of technical debt. You talked about
Yeah, back in episode 38. We did a whole episode on technical debt and what it is and how it can build up and what you can do about it. Um and it’s, it’s a topic that I think is nice to kind of revisit once in a while, maybe not as a whole episode, but you know, there’s a little part of this one because I did like the way he broke down sort of the theory because we didn’t do that, not to my recollection, but he kind of buck.
It’d technical debt in a way that I thought was kind of a useful way of thinking about it because depending on the type of uh you know, web professional, you are developer designer devops, type person, technical debt can take on different forms and those have trade offs, you know some of them are easier than others, some of them are more costly than others.
And so I thought let’s take a second look at what he talked about and see kind of you know what nomenclature we might add to, you know the breakdown that he has.
I think I think the technical debt is like uh like it’s similar to ready to real like financial debt in the sense that you don’t want to have it, like it’s not something you want to accumulate a lot of but I think you can use it as a tool if your judicious about how you use it,
you can buy a house by taking on a mortgage that’s a big amount of debt but you’re getting a house out of it and it lets you paid out over time. And I think with technical debt it’s my favorite definition was trading trading short term velocity gains or like a repaying the velocity later. Like you’re getting a lot of extra velocity now for your ticket completion but you’re gonna have to be repaying it later.
Yeah, it’s yeah, I like the financial comparison to it because yeah, there’s good debt and there’s bad debt and the bad debt is the stuff that will really bury you and pull you down and hurt you. But part of good finances is simply debt management. You know, the richest people on the planet all have their own amount of debt and in different ways and and how they do it like you say, your house is a good example of that.
Houses are generally considered good debt for a number of reasons. Uh Whereas credit cards are typically considered bad debt. Their high interest, you have to pay them constantly and it’s easy to not pay them off because you’re making minimum payments on them and things like that. So this is something to think about.
I like that comparison because I think the really important difference between the two is that when you take a mortgage out, there is a structured repayment plan built in to the product.
The first bucket that he calls out is the most obvious one, which is code, technical debt weight. People
put technical debt in code,
they put technical debt in code.
invited in in many cases,
believe me, it’s that’s like some that’s some college credit card right there.
It’s code debt is like a vampire. Once you’ve invited it in the damages, you know, he calls it though the cheapest form of technical debt because it’s it’s the easiest of the three that he calls out. He considers it the easiest to pay down fixing code. Technical debt is just a matter of changing the code.
I understand where he’s coming from and I don’t completely disagree. And I guess maybe we’ll see what he’s comparing to do with the next items. I will say that I think that certain kinds of technical debt and code can be very difficult to pay down. Here’s a great example. If you define an A. P. I. That is being used by third parties for your what you can learn about at the man in conference that we mentioned earlier,
fuck if you if you define an A. P. I. And you don’t version it than any changes you make to it or any corrections you make or any type of that you’ve baked into it now carries a pretty big cost when you make changes to it or try to pay it down later. The same thing that if you have very key models or like data modeling or uh important objects in your application and you’re careless with your decisions about them.
It can be very difficult to change that later. Same thing with like choosing a framework if you choose one framework and you’re in production, switching to a different framework can be like a monumentally difficult task that may or may not ever get prioritized.
So stick, stick that one on on the bulletin board. This idea of data modeling because that’s going to come back up in just a second.
Oh, I see that.
okay. I didn’t realize they weren’t considering that the code.
No, you you’re absolutely right. And I think, you know, if any of these, we’re going to be able to sit here and carve out exceptions, you know? Yes, there are ways to make really expensive, bad decisions with code. Yes, they are going to be really cheap ways to do the other things and, and easy fixes I think, you know, looking at as a general, you know, a very broad generalization of the category and he does qualify a little.
I say one of the reasons code can be easier to deal with is because you can change your approach to the code on the fly and the example he gives is if you’ve got a lot of code technical debt, then if you take on a test driven development methodology to approach that, you can make it easier and cheaper to pay down that code debt. Okay, I would agree with that.
You start wrapping the work you’re doing in these tests and it lets you start isolating and compartmentalizing places where the bad code is and you can use those tests as the framework to winnow it down um, to management parts.
I think a good, good razor here is um, you want to take time to make sure that your surfaces, like the places that you’re going to be interfacing with your objects, your classes, your modules, etcetera. Making sure that those things are pretty intentionally written and thoughtful and at least like able to be maintained mostly. And then the stuff inside of the functions are inside of the classes.
You can, you can write technical that there because that’s internal stuff and you can always re factor it later. And your tests like if you have tests written to work with these things, the surfaces won’t change. So the test should need to be changed except maybe on the set up. And then you could just modify the internals of how these things work without having to mess with the surfaces. This only matters because it’s going to affect the maintain ability.
Even if you’re only using an internally it’s gonna affect your maintain ability if you are able to keep the surface is consistent. So your your method signatures um your method names, your classes, you know any anything that’s going to be used by things outside of that class or object or or name space.
If that if they the the the entry points of the A. P. I. If the method signatures and all that can remain the same, it’s gonna be easier to change it later. So I would agree if if that’s what he means here that I agree.
This the second bucket is architecture debt. This is a big one I think and probably the most expensive of the technical debts I think because when you start thinking about architecture and a lot of folks may never have to deal with the actual architecture that runs their stuff. But if you are an army of one or a freelance developer or you know like you and I, you know, we run our own little servers for personal projects and and things like that.
I run, you know, a server that hosts drunken U. X. And and this kind of stuff. You can make decisions about how you prop that stuff up. So for instance, let’s say you’re building a new application and you’re going to host it in AWS and you have a choice, I can just spin up an ec two instance. Okay.
And say, you know what now, I have a server, I can install exactly what I need on it, I can, you know, tailor it to how much memory and CPU I need in storage or I could contain arise it running with kubernetes or doctor or something like that and abstract away some of that easy to gives me a very powerful solution. It gives me a lot of flexibility and a year later I have 64 different patches. I need to apply to packages because I haven’t been logging into it.
Um I forgot to start failed band. So it’s been getting hammered by Russian hackers for you know, the last eight months and I didn’t realize it. Uh my logging server crashed on it and hasn’t been keeping any logs or working at all. Like the maintenance side of that begins to rear its head and you’re like crap.
I just wanted to build my application, I could have gone to harajuku and just split it up there and not have to think about is my operating system patched, what version of PHP am I on? Like those challenges begin to add up and they themselves start to create debt inside of the way you’re hosting whatever resources you have. I agree with that, You know, one, I think a bellwether for this. Do you have architecture technical debt?
one of the ways I think you can answer that question is and this is kind of specific, but if you’re building an application and in order to update that application you have to schedule downtime, then you have architecture technical debt. Sure. I mean that’s I think a measure of that. If you have built a good sort of robust supportive architecture, you can either swing set stuff, you can update in place.
You can, you know, pause services without taking down an entire application, things like that. But if you have to hard stop stuff and schedule a six hour maintenance window where nothing is accessible, you have architecture technical debt.
I think another way to look at it is if you’re like, I always joke about how google loves to discontinue services that people love when enough people like them. So if you’re hosting provider is make place of google and suddenly shuts down that particular infrastructure service and you have to move to a different place, how quickly can you move?
I think there’s a variation on that too, which is how many single points of failure do you have? You’re always gonna find some weird random single point of failure unless you’re somebody like netflix or amazon who has, you know, thousands of servers running across the country, most people are going to have single points of failure somewhere in their infrastructure.
We saw that a couple weeks ago, right, with um who’s alchemy? Alchemy went down and then like a month or so before that with Fastly actually affected my job. We we used fastly for DNS and
yeah, so uh those single points of failure, your goal and it’s just like any debt, your goal isn’t necessarily to eliminate all your single points of failure, but you should know how many there are. Uh you know, is it a service and a p I that you are relying on that if that api goes down, your system does not fail elegantly. Um is it, you know, a load balancer? You have one load balancer? This, this is always a fun thing, right?
Well I have redundant servers behind the load balancer and then you say, well how many load balancers do you have it? And like I just have the one think about that for a second. You just
need, you did load balancers all the way down because
You still need something to tell the traffic which load balancer to go to it. So it’s like, yeah, you end up, you can force get around all of that with you know, some 53 stuff and things like this, but most people, like I said, we’ll have a single point of failure somewhere in their chain. Um and so that’s a good way to kind of measure your vulnerability to that.
The other thing to think about is out of all of these talking about like what kind of debt is the cheapest is sort of an abstract discussion. Except with architecture where bad architecture, technical debt can incur real debt on the business side of things. Because it’s easy, it is so easy to spend a lot more money on cloud services and things like that parochial gets expensive
quickly. I mean it’s it’s nice to not have to maintain all of the devops stuff with maintaining your servers and patches and updates and everything. It’s definitely nice man. Like I’ve seen I’ve seen the cost things like the in line cost things on our are heroic coincidence and
wow, amazon gets real expensive real fast if you’re running like full size ec. Two instances if you have badly optimized um I a s infrastructure as a service. If you are farming out whether that’s the AWS or heroic or Digital Ocean or is your any of these places if you have not optimized your infrastructure, your cloud infrastructure, you could be spending as a company.
We’re talking tens of thousands of dollars that you don’t need to because you’re paying for a high memory instance of something that Doesn’t pass 30 consumption or something like that. Like there’s just a lot of ways that that infrastructure can give you actual debt that you need to look at and then changing it can then be problematic depending on how it’s set up. This move towards what we call um infrastructure as code. Right,
alright. With uh not gonna see Jenkins, what Jenkins um like puppet. Configures puppet Yeah, puppet and um
Chef Chef Chef is one. Yeah. Yeah, terrible, isn’t it? Mm pair forms out there uh care forms go, I think chef is ruby um puppet is ruby. I may be wrong. Um The other issue last on my list for architecture is just that architecture debt can hide very real issues on you that you don’t realize if your infrastructure is not logging stuff properly and alerting you on things and you don’t have no GOs or Prometheus or any of these application monitoring appdynamics, something like that.
If your application is throwing 500 errors 1000 times a second to users because of a mis configuration and you aren’t getting those that can really hurt you. Like that can hide all kinds of issues because emails aren’t getting to you and alerts aren’t getting to you. Um, and performance, you know, it may be something as simple as a page that should load in 70 milliseconds is taking 700 milliseconds because of a memory mis configuration.
Um, anybody who’s ever tried to performance tune Apache um, something I have unfortunately gotten my hands into a few times, trying to like really tune a low memory, low CPU Apache instance to be performant, man, it’s hard and if you don’t know what you’re doing, it’s real easy to have those servers slug like really drive along. Um The third bucket is data and modeling. So you mentioned this, he broke it out into its own thing.
The idea of data and modeling. Um This is like the idea and my example is a real world example. We built an application that had a database back in uh and we spent a week going back and forth trying to think about how we wanted to model this data and what would make the most sense. At the time we settled on dynamodb dynamo is a, what they call a no sequel solution.
Okay, basically one giant table with a bunch of columns and you, you build, uh, indexes on it based on different combinations of, of columns and that worked great until it didn’t. But our problem was the decision making we made at the start was changed by changing requirements. Okay. And instead of going ahead and going with a relational database, like my sequel or post Grace or anything else, um, we decided to build for what we thought was going to be the limit.
When the specs started changing and the need started changing, it became more and more difficult to modify data. Um, it became more and more difficult to change data and the issue we just ran into, which was entirely Michael’s fault. Michael did not deploy a production release a few months ago. And so the question came in about, hey, how do we get into the state? And I’m like, well, should just be there.
And I went and looked and none of the data was there. And I’m like, what’s going on? Well, Michael didn’t release the production code. And so we went back to our logs. So remember when I said architecture debt, are we had logging in place that stored all the raw submits. So we were able to go back through the data and extract all all of these submissions from the logs to find the lost data. And it
sounds like a fun weekend.
Oh yeah, no, it’s, it’s bad. So we’re going through it and we’re looking at, okay, so now we need to update the existing records with this data to insert the stuff that wasn’t being saved. And it’s a nightmare with dynamodb because of the way indexing and it works. And the fact that you can’t just, it’s not like a normal relational database where you can just throw query at it and it’s happy to give you back whatever matches the query dynamo doesn’t work that way.
Um and so our failure to anticipate that and there’s going to be uh we’re going to talk about something here in just a second that will help explain this, our failure to sort of anticipate that incur debt for us. Um and that goes for custom post types in WordPress. You know, you’re building a custom post type and thinking about what fields you need. Your data modeling doesn’t necessarily have to be like strict database, you know.
O.M.L. you know, things like that. Um this can be simple stuff. What does my structured content look like, you know, what information do I need in order to spit out these things on the front end and what starts as good ideas and good decision making can still lead to debt unintentionally. Um It’s just something that can happen
a long time ago I worked on an app that began as using a SQL database and later on we change it to post grass and rails. Was great because it has built into an O. R. M. An object racial mapper which basically acts as an api boundary or your database and it gives you a common interface regardless of what engineer using under the behind the scenes.
So when we switched from Maya’s quell to Postgres, I think there was maybe like one or two things we had to change because they were like some manual SQL queries. We had written their little complicated. Um but for the most part the entire app was like it was like a half a day migration to go from one to the other and most of that was just getting the data itself migrated from one database engine to the other.
There are two other types of debt that I think should be called out. Um one is designed that and the other is content that because I think those are things
okay, can you define those for me? So I think I know what you mean, but
so design debt can be incurred by like the use of patterns that leak into each other or that overlap without properly overlapping. So this gets into pattern library stuff and design system kind of work UX UI or areas where um one of my favorites is like talking about spacing on things and figuring out like, well I put top and bottom margins on these but they’re included with other things that have top and bottom margining.
Now these things are all fighting me and I have to figure out how to go in and rationalize them because the way I’m using box sizing, you know, is causing them to be additive instead of combining like design can leak and drift. You get designed drift on things over time and going back and trying to fix those after the fact or retrofitting can be very difficult and time consuming rather than building something from the ground up to be correct.
Um so where I see this happening is in areas like, you know, when you do a redesign, are you retrofitting design or are you actually re articulating your html? You know?
And so I’m cribbing from that. Um I had an app that I went from semantic CSS framework and then I went to tailwind and then I went to a different framework, I started with Bootstrap and then I went to tailwind and then I went to semantic CSS. These are three very, very, very different approaches towards styling your html and not just in how classes are used, but also in how the html is structured.
It’s very different And there was a significant cost in moving from 1 to the next. So when I think about design debt, I think about like, are you doing them, are you doing to Kenyans? Are you doing uh the other one object oriented CSS? Yeah. Right.
Well, and and one way that you incur that dead in those things too is being indecisive about them, right, grabbing foundation and using it halfway, but then also mixing it with some bend the methodology or something like that, you know, or somebody changes right. Another dev comes in and starts working on stuff and maybe you don’t do code review. And it turns out they’ve been writing CSS in a completely different methodology.
You can call that code technical debt, but I really feel it specifically designed technical debt,
Um, I’ll end on this. It’s a little bit of uh, thinking from martin Fowler, he had this uh, tech debt quadrant that he shared. The two columns are reckless and prudent and the two rows are deliberate and inadvertent.
And so this can kind of help you define where you’re, you know, when we talk about good or bad technical debt, we were talking earlier, it’s like if you have a prudent, deliberate technical debt that is significantly better than reckless inadvertent technical debt.
So what is reckless inadvertent?
That’s a real like YOLO approach like development,
not storing keys in a secure way is pretty reckless and and if you don’t know, you know, if you simply don’t know better, that makes it inadvertent. You know, if you’re a new dev and you don’t think about key stores and things like that reckless inadvertent. Um okay, so
what’s prudent and deliberate then?
So prudent and deliberate is saying this is an ugly function, But this is a showstopper bug that’s going to take me three days to fix, right? But I can get a patch out right now that gets my service back up and I think,
I think we’ve all been there. I mean for depending how many years you’ve been doing this at some point, you will invariably run into that. That’s that’s that’s good. You know, going back to our financial comparison from earlier, this is kind of like you just got into a car accident or you blew out a tire or something and now you have to use your credit card to pay to get it fixed and you’re like Okay this cost me $1,000 to fix.
I throw it on the credit card And then I can pay it off over the next 3-5 months or whatever. Um You have a plan but you’re getting the thing done now and you have your plan to get rid of to fix it later on.
Yeah, so that’s a little look into some different technet, thinking um go check out the article at their website and be sure to put some thought into how your technical that may be sneaking up on you.
over at Speaky Boy Mr eric carr kovac who I have a lot of respect for and uh I I am actually kind of um I feel like I almost need to have like a show with just all his stuff because I have quoted his article so many times over at Spec E Boy, he’s put up an article where he’s written about. Is it time for web designers to retire the slider? Um Now if you listened to me before and I was looking I thought we did an episode on this and I guess we had
before you continue, you should clarify what you mean by slider because usually we use a different name,
not not very tiny hamburgers. Um this can be a carousel, like an image carousel or a content carousel, um a panel rotator. Uh And in my eyes, this takes many forms. For instance, the the tab um slider or the content Taber that can be on in the hero section of a page. Anything that basically is designed to Present multiple pieces of information inside of one container. It’s like a rotating billboard, rotating anything.
Yeah, yeah, rotating like led billboard going down the highway, things like that. Um My hatred for caress cells is matched only by my hatred for chatbots. That’s not a joke. Like I legitimately I have fought fights to keep sliders off of web pages. Um and I’ve given talks on like I have gone through conferences and presented on the fact that actually get rid of centerpieces.
I can vouch for that. I mean we’re before the show. I was I was joking that I don’t think it’s fair to ask web designers to retire the sliders because most web designers I know don’t like using sliders.
It’s usually, it’s usually it’s a decision comes down from management with chinese syndrome or just I also described it as, um, a design solution for people with object permanence problems where you, if you don’t see yourself represented on the homepage front and center, then you think that you don’t exist on the web page at all.
Yeah. Uh, and in eric’s defense, he does make that note in the article. He does talk about how it is often not the designer’s choice to implement these things. It usually does come from elsewhere. There’s a separate article by joe Rinaldi over at Impact Plus.
Um, he’s, he has the comment that it’s an easy solution for telling competing departments within an organization that their messaging is on the website, which is another way of saying exactly what you just said, like, oh, they, they’re so important. They want to be on the homepage fine. You’re on the homepage
like sliders or caress cells are a compromise or maybe a way to surrender two. Yeah. To a lot of very loud and noisy departments. You and I both worked in higher ed for a long time. So you know what I’m thinking about here? Um, but it’s, I think that if you, if your team that’s responsible for maintaining the design and communication of the website of using it as a communication platform.
You have to be able to be empowered to say no and to tell the people you’re working with how it’s going to be and then you don’t end up with with sliders. Like it’s, if you’re using one, it’s probably because you make you compromise because you’re not empowered to say no to people
and you may not have the social capital to do it. Um you know, one of the, one of the things about those fights is capitulating on a feature like this is often done because you would have to burn a lot of social capital to fight it. But then that capital is gone for you now, now people don’t like you now, you’re the person who says no to things. And so when you have three more items on your list, that would have been better and easier to win.
Now they aren’t um it’s It’s a content problem. It’s an understanding problem. In 2021, you know, people still ask for them to be implemented on pages. Uh huh.
That’s because it’s an uncreative solution. I like I want to put this out there. I want to say if you are currently hooked up on a slider on the slider juice and you want something different for yourself. If you want to take speaking boy and joe and all these web advice and get away from the slider sauce. I think the solution is to implement a more affirmative content strategy.
If you can go to these to your stakeholders and you can say really identify like what it is they’re needing, like identify, listen to them, find out what their actual needs are and you realize like, oh well they have this semi annual event and they want to make sure that it’s represented on the homepage, then you can build a content strategy around that to where they are represented. And then it’s not so important that they’re constantly on the carousel or whatever.
But in the real world, sliders represent performance problems. They represent accessibility problems they cause bloat on your page, especially if they are implemented badly or poorly. You know, you’re talking about sliders, I’ve seen sliders that load, not just all the content of every slide when the page loads, but they re download it. They don’t cash it.
You’ve seen this with me, we’ve covered this news episode and the episode about news sites where we found one of the news sites had had one of those rotator and it was repeatedly downloading the stuff over and over and over again.
Nobody look, nobody is going to sit on your website and click through each of the things unless you make them, unless you force them to do it and if you force them to do it, they’re not going to be happy about it. I always hate seeing the ones where it’s like the slide shows up and then the text like animates onto it onto the thing. Like what this is like the 2000s like this is no longer a novelty. You’re wasting my time.
It’s also a a problem with code bloat because in our, you know, speed to capitulate and just say fine, we’ll throw it up there but we’re going to do it as easy as possible.
I’m gonna, well it’s technical debt. Yeah, you’re absolutely right. It’s also something that I’m gonna go grab a library because it’s going to take me twice as long to write one from scratch and you’re just doing a vanilla jazz.
But the library I grab is going to be 75 kilobytes Of which I am touching eight kB of that code because the library is accounting for all these educates is all these different configuration settings, all these different approaches and uses, which is great for the plug ins builder. But As a result I’m loading 75 kB or the code. I don’t need.
How many show of hands. How many of you out there who use WordPress have ever used revolution sliders.
Oh God, forget the java script. Let’s talk about CSS on that now.
That’s when do you go from having like an occasional, that’s when you have like you have a substance abuse problem with sliders when you’re at that point.
So we’ve got a couple articles will be in the show notes on this from different places. My favorite is simply should I use a carousel dot com because it’s going to have all kinds of information in it. It also has all the data. When Aaron says things like people don’t click through paris cells that’s supported by research. Like A lot of research and it’s, it’s definitive.
Like it’s not maybe the drop off from the first slide to the second slide is like 93% or something like that. The
best thing about that site, should I use a carousel dot com? Is that when you load the page, it considers all of the sites that you’re currently working on and it determines for each of those sites. Should you use the carousel? And so the answer is calculated dynamically for each site that you work on.
I don’t know what you’re talking about.
Well, take a site like for drugging you extra calm, so load that and now load. Should I use a carousel? What does it say? It says no. Right, okay. So like pick, pick a different site, pick new cloud or a quint. But and then go to She’s
it always says no. That’s the joke. Oh, okay. I’m like, I thought you were talking about like, it actually like did something like, no, I’m not the way that works. I’m with you.
So good. I got Michael,
I’m there with you.
last article comes to you from the kind folks over at everybody’s favorite CSS site, CSS tricks. Um, this is from Ferrari Candia. The article is web features that may not work as you’d expect. This is kind of cool because it tackles and we’re only going to talk about a few of the items that are brought up in it, but there are several that are mentioned through it beyond this. So do go check that out and see the other things.
But this is kind of a look into things the browser does and, and features that are available that don’t necessarily do what you think they would under normal circumstances. And I thought that was kind of neat. And there were a couple examples that I even went, oh, I didn’t know that. And so there’s probably a little something here for everybody to learn.
And it’s one of those like figuring out idiosyncrasies, you know, we spent a lot of years figuring out like the difference between how I E nine would render something versus Netscape versus you know, firefox and Safari.
So, you know, that process has certainly gotten much, much better over the years, but that doesn’t mean that idiosyncrasies have gone away and in some cases and and with these a lot of these features, it’s often just a case of hey, the thing you’re doing doesn’t work how you would think because you’re used to it other ways um the first one being visited, colon-visited, so Aaron, what? We were just talking right about CSS specificity.
What is colon visited? Is it is it a pseudo element or a pseudo class?
That would be a pseudo class. Right,
Yes, because it defines state
because it’s single colon,
It’s a good way to pull it out and say, you know, is it visible? You know, is it bold it or is it, you know, is the alert highlighted? But with Colin visited get computed style does not work. And that is intentional, like it doesn’t work for a reason.
Uh Is it a
yeah. Why? Why would that be
is it a security issue?
Okay. Because because because if you can see if they visited a site before and you can programmatically query for that, then you can find out information about their browser or like information outside of the site context.
To protect yourself. You want to make sure you always pan left negative 10,000 pixels, those links. That’s the solution here. But
every direction you gotta go up negative 10,000 pixels down. It’s it’s a whole thing. Yeah. Yeah. So this goes back to about 11 years ago the CSS history lead um and there’s an article over at Mozilla that I’ll have links in the show notes that breaks this down. But basically come back to this idea that people started using the visited pseudo class as a means of breaking down where people had gone.
And so browsers collectively locked down get computed style against that specific pseudo class so it will never return, it returns null, I believe it doesn’t return anything. Um And so generally speaking, yeah, no the that one case just happened and I don’t, you know, it’s not necessarily that everybody’s out there. Like boy I really want to know what the visited state is on these links.
But it’s just a case of here’s something you would just expect to work and if you didn’t know why it wasn’t working for you it would be a pain in the butt to probably figure it out.
Okay. I’ve not actually tried this. But I wonder if you had like an off page container somewhere and you had a list of say 100 different like big site links to Facebook, Twitter Amazon whatever. And then you apply a visited style to each of them. And if if it was visited then it’s displayed none. Otherwise it’s display in lane. What you have to do. You have to like check to see.
You have to do like a j query selector for everything that’s visible and then iterate through it. And then that would tell you like if the links had not been visited or you know I mean? Because really, I don’t know what you would do that maybe like a cross site, like a CSR efforts to cross site scripting attack or something? I don’t know.
Yeah, you could do like J query from a google. Cdn
right? Google had their Cdn set up and they had everything right, not just jake where you pull prototype, you could pull hell they had like mu tools and things like that still in there. Like you could pull anything you wanted to out of this. So the
the intent was that you pull it down, you pull jake worry or move tools or whatever from you google on you say newyorktimes dot com And then later on when you go to amazon dot com, it’s still cashed in the page loads faster. That’s the intent,
that’s the intent and like web fonts were set up kind of the same way you can use google fonts to do that. And likewise, the other side of that though is also just the strict performance aspect, which was google C d s are super fast and your server probably was fast but not as fast. So there was a secondary benefit there.
But yeah, the cashing thing we all used to sit around and be like, well just use yeah, the google Cdn J query because then if they’ve been to, you know, popular site X and popular site X is also using it that I’ve saved them that download. That’s not true
You still get the speed
benefit of using google Cdn. So it’s always as if it’s the first time. Certainly.
Yes. So there is no such thing as cross domain asset cashing
even from a C D M
even from a Cdn for. So what
what why that that’s this is not intuitive for me.
But if you if you load if you’ve previously loaded J query on google dot com and then now you’re trying to visit facebook dot com and we’ll j query there. How can they, how could facebook tell that you’ve loaded it previously from google
because they could just
tell that you have it.
You need to think about it a little more fourth dimensionally. Okay. I’m not gonna do it with something as broad and basic as J query. I’m going to do something like load the sites.
That that makes a lot more sense. I was thinking it was just applying to see DNS but know that
it’s easier to explain from a methodology standpoint. I think using that general thing, but you have to think about like if I want to be nefarious, how would I exploit that? And that’s how people exploited it.
So, so the reality is that any domain, any asset is always contextualized to the domain that’s loading it
right now. Cashing does work. You go back to the site, it will load from cash, but it just doesn’t cash cost domain like you you are, you are limited to what are called groups and we’ll talk about that in the section. Um, groups in storage, sort of compartmentalize all the side, you know, make silos for all this stuff. So yeah, one of those, yeah, not not going to give you the benefit. You think it does. Uh loading. This is a fun one.
So another topic we’ve covered this lazy loading, right? How and how to you know, get a little more performance out of your imagery and things like that loading is an html attribute you can put on things like images that will tell the browser to lazy load that image until you know it’s viewed. Uh Some people prior to this would use techniques that leveraged what’s called the intersection. Observer. A. P. I. A very cool. A. P. I. A very useful A. P. I.
That can tell you where on a page somebody is and can tell you if something is coming into view or out of you. So folks would say, well when an image that isn’t loaded is within 10 pixels of you know the intersection, then go ahead and load that image then. Mhm. That’s very cool. Except that there are two things about it. one is loading unless you are doing something with it. Outside of the realm of normal behavior loading does not work.
If the user has scripting disabled and
you mean wait hold on. You mean if they have scripting disabled then the loading trigger doesn’t even fire.
again, this comes back to a a privacy and a tracking issue because you can use the loading of images as a way of tracking a user.
Uh interestingly enough so
if somebody all these features are like both around the
security security relations and so is the last one for what it sort of. Uh But yeah so if somebody has disabled scripting in their brows are you know using security settings, lazy loading won’t work. The other thing about lazy loading that was interesting to me the loading attribute you can’t poly fill it. Okay hold on
hate probably fill whatever here probably felt I think probably gone filling like a vector art kind of thing.
I can’t disagree with you.
It’s been explained to me what it is but it’s not an intuitive name at all and I just I hate it.
Mhm. Um So you can’t powerful. Okay so what
do you actually mean with that?
Right? When when we didn’t have local storage, people would do things like write a poly fill that would mimic local storage using cookies or something like that.
Right. Okay. Okay. So so this is because loading operates kind of like on like the bare metal making air quotes here bare metal level of the browser rather than that like the the client side code level you can’t wear the polypill would normally execute. That’s why it doesn’t work. So kind presumably
you can write a poly fil for it, you can do it like you could write the code and the code would work sort of. The problem you run into is basically a race condition. The problem is in the time it takes your polypill to load and be useful. The images will have likely already loaded on the page.
like you would have to do something else on top of like the old solutions or things like instead of using a source on an image tag, you might use something like data source and you would swap those. But if you’re using like a vanilla approach, image source and then the loading attribute.
If the browser doesn’t support the loading attribute, it’s just going to load the image like normal and your polypill simply isn’t going to react fast enough to prevent that. So yeah, like I said, yeah, funny. Like it’s just kind of I hadn’t thought about it, but it makes sense. Our last little little thing doesn’t work the way you might think is web storage persistency. A lot of people think web storage and we’re talking about like local storage, right?
Local storage lasts until people clear their cache. Okay. By convention. Yeah, that’s mostly true. But it’s not. There are two exceptions to this one is the big one is Safari. Safari actually has a seven day limit on local storage. Okay. So After seven days, Safari just says, Nope, this is gone. Mhm. That’s just something I think a lot of people aren’t used to and aren’t necessarily considering.
Um Now obviously you can re up that you know people keep coming back to a side or something, but if somebody doesn’t come to your site for a week, you should not assume that that local storage is still there. Um Yeah, there is something else too because I said by convention, most browsers Let you store stuff and they have huge data caps, like local storage can take up depending on the browser, up to 50% of available storage.
So if you’ve got a 500 gig drive it can store 250 gigs in local storage if it’s allowed. Um Now there is a limit per group usually. And I I used that word earlier when we were talking about cross domain stuff. Right? Groups. A group is basically a domain. Okay. So you’ve got what is usually like a two gig limit per group. So it’s like a half your storage in total, determined by up to two gigs per group. And that that cap varies I think chrome is one gig.
Um It just depends. But if things start filling up the browser will just start the leading stuff and it uses what’s called an L Ru policy at least recently used. So the oldest stuff basically starts getting thrown away and it will just do that to make room. There is however, a persistent storage ap you can use to say, hey, this stuff should be protected, it shouldn’t get thrown away.
Um, and so we’ll have a link uh to, you know, where that works and how that storage, A P I and the permissions work. It’s a browser permission thing. You do have to ask for it. It does cause of pop up and all of that. But web storage persistency is kind of a funky little thing because local storage does not have an expiration built into it like a cookie does. So the browser handles it a little differently.
And Safari being the odd boy just says seven days we’re going to be different from everybody. Seven days it’s gone.
That’s really good to know. I I’ve used local storage before for like kind of pseudo auto saving features for like, you know, when the user wants to like have something of the writing, have it be kind of like pre saved just in case the computer crashes or whatever without doing a write to the database and they would probably be super miffed after like a week because they left the tab open for a week all of a sudden it goes away.
Uh huh. So go take out check out the article. There’s a few more things in there that we didn’t bring up, but I thought these would be some of the more interesting ones to folks were doing web development. Go look at those, it’s over at CSS tricks and we’ll have it all in the show notes.
folks, I hope you enjoyed the different topics from this evening. It’s I I enjoy kind of taking a break sometimes and just kind of running through a few different things just to dress it up and and change things up. Let us know any topics that are on your mind or things you think should uh come up in a future episode, you can connect with us on any of the social media that twitter or facebook at slash drunken you X.
Or instagram at slash drunken you X podcast and as always hit us up in our chat room, we have a discord server at drunken uX dot com slash discord. If anybody is interested to keep your ears to the wall because we have some pretty killer guests lined up. We’re gonna be talking about stuff like web vitals, we’re gonna be talking about content strategy for developers, we’re gonna be talking about something else that may be wordpress related and theme related.
Uh I’m not going to spoil all of it right now, but let’s just say we’ve got some pretty awesome folks in the pipeline so be on the lookout, we’ll announce some stuff coming up on on social media about those things.
Get subscribed if you’re not already hit the like button, leave us a review. It really helps us out because it’s important to us that when we are interacting with you and riding up these shows and coming up with these ideas that we keep our personas close, but our users closer. Bye bye.