S10 E13 | Styles in the modern age with Martine Dowden

Are you an Angular developer? Do you how to correctly manage styles in an Angular application? Whether you do or don't, this episode will be for you! Come learn from Martine Dowden how to manage and structure styles correctly in an Angular application! Global styles, view encapsulation, modern CSS features, what to put in and what not to put in Component level styles, you name it we cover it!

https://martine.dev/
https://www.joshwcomeau.com/css/custom-css-reset/
https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Containment/Container_queries
https://news.ycombinator.com/item?id=30898803



Follow us on X: The Angular Plus Show
Bluesky: @theangularplusshow.bsky.social  

The Angular Plus Show is a part of ng-conf. ng-conf is a multi-day Angular conference focused on delivering the highest quality training in the Angular JavaScript framework. Developers from across the globe converge  every year to attend talks and workshops by the Angular team and community experts.

Join
Attend
X
Bluesky        
Read
Watch

Edited by Patrick Hayes
Stock media provided by JUQBOXMUSIC/ Pond5

Episode Transcript

Speaker 1 (00:08):
Welcome to the Angular plus Show. We're app developers of
all kinds share their insights and experiences. Let's get started.

Speaker 2 (00:21):
Welcome back everyone to another episode of the Angular plus Show.
Today we are going to be talking about a topic
that I know pretty much nothing about, and I have
attempted to learn half a dozen times too close to
a dozen times in my life, and I've never succeeded
at it. So hopefully this can maybe get me, you know,
a little bit closer. I believe our host is going

(00:43):
to be able to do that for me, so all
all the faith is being put over there for the
time being. But until then, I have two great hosts
of me today. Who I wanted to go first. I
was thrown. I was throwing. I was throwing be Love
under the bus a little bit earlier, So I'll go.
I'll go Brian.

Speaker 3 (01:00):
I was gonna challenge your intro Jay and I was
gonna say, Okay, so you tried to learn this topic,
which it's funny you haven't even said it yet, so
I'll continue to keep the mystery. So you tried to
learn this topic like ten times or twenty times? Have
you done any actual formal training or learning experiences on
this topic, or you just constantly copy pasting from a
particular website like MDN or something and just bringing it over.

Speaker 4 (01:23):
Okay, that's what I know.

Speaker 5 (01:26):
Here's what I know. Like at least half of the
guests already know what you're.

Speaker 3 (01:28):
Talking about, you think, so how long can we make
it without it?

Speaker 4 (01:36):
There was I don't know how to say this without
saying it.

Speaker 3 (01:38):
But when a particular new approach to using this came
out a couple of years ago now, like whatever, five
or six years ago, eight years ago, I actually took
one of the first class like online courses. It was
like almost like a gamified of like you were building
and yeah, yeah, yeah, So I got to learn that
particular like really really well because I actually like kind

(02:01):
of went through the of course and did it.

Speaker 4 (02:04):
But it's funny.

Speaker 3 (02:04):
I still work with engineers today and they're just like
they don't know which like attributes to use or how
to like, yeah, put it all together.

Speaker 2 (02:12):
So well as as Charles grows, I get farther and
farther away from from from those files anyway, so I
can just not worry about it at this point. It's great,
this is what we.

Speaker 5 (02:23):
Need to train junior like early career does. That's what
they need to be good.

Speaker 2 (02:29):
That's why I hired them exactly that I don't have,
never worry about it in my entire life. My entire
career sounds great to me.

Speaker 5 (02:35):
Laura, I'm also here present.

Speaker 2 (02:42):
Okay, Well, on that note, let's introduce our guests today, Martine,
how are you doing today? You were a guest, Martine,
dad In awesome.

Speaker 6 (02:51):
How are you guys? Pleasure to be on the show.

Speaker 2 (02:54):
I'm so still to talk about CSS. Who guess by
all O talk and discussions today, specifically an angler because
we are an Angular plus show. But Martin, you want
to give yourself a little introduction and tell people who
you are and why they should listen to you or not.

Speaker 6 (03:20):
I don't know. You should just trust me. I'm the expert.
No no, so I Uh.

Speaker 7 (03:29):
My name is Martine. I work for Andromeda Galactic Solutions.
I've been a front end dev. I started devving on
the front end. I now do a little bit of everything,
but the I started on the front and CSS has
been kind of my puppy, and then I know, expanded
on into Angular and JavaScript and all that fun stuff.

Speaker 6 (03:49):
My backgrounds action in psychology.

Speaker 7 (03:51):
So I started on the design and UX aspect fairly
early and then moved into coding.

Speaker 8 (03:57):
So that's kind of usually might approach the things.

Speaker 2 (04:02):
Yeah, cool, Okay, what are we talking about? The CSS
and angular? How to do it, how to optimize it,
and how to make it better?

Speaker 7 (04:12):
Right?

Speaker 2 (04:12):
Is that is that what we got you on here for? Okay? Great?

Speaker 5 (04:15):
Yes, that's all the things.

Speaker 2 (04:16):
I'm glad I did the prep work for this for
this episode.

Speaker 5 (04:18):
Great, they did his homework. He almost took a course
on CSS, decided not to and to just complain about
it instead.

Speaker 2 (04:27):
That's exactly right.

Speaker 9 (04:31):
On.

Speaker 6 (04:32):
The capstone for any CSS course should be centered the difficult.

Speaker 3 (04:36):
Right, Seriously, it used to be back in the day,
but not anymore. You know, if you do learn flexbox
or grid like, you're good to go. But you're right
back then you had the margins and negatives and whatever.

Speaker 2 (04:50):
My capstone was on machine learning, and honestly, I would
take that over twenty sets any day of the week.

Speaker 7 (04:57):
It has become a lot easier to do than it
once was. I will totally agree to that.

Speaker 2 (05:02):
Tut all of the l ms out there have been
trained on all of the STACKO or flow from history,
so you don't actually learn how to spend or did
if he use an LM nowadays, because there's all the
same stuff that we've all tried to figure out over
the years on there.

Speaker 7 (05:19):
Yeah, that that's mildly concerning. Actually, I'm trying to think
of the number of things we used to do for
like clearing floats.

Speaker 6 (05:24):
And whatever else. All of that is still on stack.

Speaker 5 (05:27):
About floats. All floats were the word.

Speaker 3 (05:30):
You line them all up and float right and then
clear and.

Speaker 7 (05:35):
Yeah, there's a there's a new property now that replaces
there's a fix. There's a legitimate way of doing clear
fix that doesn't involve the clear fix hacks hack. Now
it's uh uh properly, it's a display flow route. It
actually works really well, So floats are actually usable now.

Speaker 5 (05:52):
Ironically, at the time they're like, this is the only
thing you can actually use to accomplish this. It's to
be really hard to deal with. It's definitely going to
mess you up for at least a few days every
time you touch it. And now they're like, oh, by
the way, yeah, okay, that thing you always struggle with,
here's the easy way to do it. But you have
like ten other ways that you can do the.

Speaker 2 (06:12):
Thing that was the worst. Honestly, that was like, that
was one of my biggest issues with university. In school
in general, it was like, I get it, they teach
you the hard way. But the biggest kick in the
face was when I finally learned calculus. They taught you calculus,
and I'm like, no, everything I've done in mathematics up
until this point is easier with calculus. This is such garbage.

(06:36):
Why did I spend six years learning all this stuff
when it takes like one percent of the effort to
do with calculus. I feel like computer sciences, or at
least back back in the day, computer science was like
that compared to like now, because it's just like so
much easier to do everything now.

Speaker 5 (06:51):
Yeah. Well, I mean I remember like being super stoked
when I got my first rollover to work. You think
job Now, it's like it's so easy now. Kids these
days they don't know how good they got it.

Speaker 2 (07:06):
I do not know how good they have it.

Speaker 7 (07:09):
I say, slice and dice, slice and dice and spacer
and spacer dips.

Speaker 6 (07:17):
Yeah.

Speaker 5 (07:20):
I always solved the pea. I usually just solved the
problem by making an image and photoshop slicing it up
and putting it in a table.

Speaker 3 (07:34):
The problem is how do you deal with with responsive,
because then you look at it on a phone.

Speaker 5 (07:43):
Like exactly the size. I mean, have you ever opened.

Speaker 3 (07:49):
I know, I know that I should not even have,
but like you resize the browser, then all of a sudden,
it's just like.

Speaker 4 (07:57):
The whole the time.

Speaker 5 (07:58):
Yeah, oh yeah, that's I mean, that's I think why
a lot of us at that point went to flash
because you could control the way everything looked and it
felt like the right way Because I worked I worked
in sign Yeah, in like two two thousand and two,
two thousand and three, I worked for my aunt who
does graphic design in Los Angeles, and we had a

(08:20):
client that needed a website and she would design it
and it was my job to make it look exactly
like her designs.

Speaker 10 (08:26):
On the screen.

Speaker 5 (08:27):
Fine, which the only way to do that at that
time was h slash slash. Yeah, out control of it.
But but yeah, anyway, some questions, see, I think we
should let Martin U. So what are some of the

(08:51):
common issues you see with like styles in angular specifically?

Speaker 7 (08:59):
I don't think the one I've seen a lot recently,
and I don't I'm not sure if it's by nature
of the clients I've been working with or if it's
just more prevalent.

Speaker 6 (09:07):
Is a lot of the tools like.

Speaker 7 (09:11):
Your your graphics tools, your figmas, your XD's, your have
a really nice you know, click and copy my CSS button.
And what I've been seeing this trend I've been seeing
a lot of is instead of creating some basically for
lack of a better term of theme, right, you'll get
the same styles copied over and over and over and

(09:35):
over again. And so I think that that to me
is probably like right here right now, the top thing
I see, But the other, the other one is also
the the probably the segmentation between what should you put
in the base file versus what you put in the
component file? Right like where where do Where's that line
between the reusability and then should what can be extended

(09:58):
versus not versus based on media queries. That that gets
into the more technical of CSS proper, maybe outside of
of Angular. But like the I think the really big
prevalent right now is the copy paste. We've just gone
from copy pasting from stack overflow to copy pasting from Pigma,
but the favor is not the same and the outcome

(10:20):
is just as good.

Speaker 5 (10:21):
Yeah. Well, and now we've got people vibe coding or
like even just using like co pilot. I mean I
do it myself when I'm making sample apps and like
just make it look like this because I don't want to.
I don't want to think about CSS, to be honest.
Post for trellis Yeah, and you know what, yef that
works super great for like, you know, one or two views,
but it quickly gets out of control because if you've

(10:44):
ever built your Angular app, your styles bundle is going
to be one of your biggest totally, like it's huge or.

Speaker 2 (10:52):
So in terms of Angular styles. So you were saying that,
you know big as you're like what do you put
in your base one versus what you put in your
component one? Stuff like that. I'm assuming most of our
listeners will know. But you want to talk a little
bit of qout how style encapsulation works, Like I'm assuming
it has to do with view encapsulation with an A either.
So like, yeah, everything in the root obviously cascades across

(11:13):
your entire application, but if you put something in the
in the component, that's not going to cascade the chi
child's components, right, So like, how does that all right?

Speaker 7 (11:22):
So basically the generally speaking, unless you mess with the settings,
because you can, which that's all different kind of worms
at that point. But by the fault out of the box,
what all happen is you have these styles at CSS
fell at the rid of the project, and that one
is going to be that's going to be global to

(11:42):
your entire application, no matter what component you're in, no
matter what it's going to, those styles are going to apply.

Speaker 6 (11:48):
And then each component.

Speaker 7 (11:49):
Themselves has a style file, which is the scope is
limited to the component itself, so only the HTML that's
inside of that that component is going to be affected
by those styles. Which so you can let's say you
have a class name that you're the same the same title,
class name or whatever, that you're styling differently. Now this
is I would consider that bad practice, but we'll move

(12:10):
on to to that later. But the like, let's say
you have the same class name in multiple component files,
they wouldn't conflict with you other or try to hammer
each other out. Now there is you can set the
you can set the property on the component so that
the styles do are actually shared between components.

Speaker 8 (12:30):
I personally have not found a really good use case
for doing that short of the the only the only
one I can think of.

Speaker 7 (12:37):
Off the top of my head is like, let's say
you have one of the things I've often done is
have a table component, which is where you pass it
data and maybe a handful of properties to tell it
how to behave. But that way you sort your filters
you're you know, are just kind of there, and that
way you can, especially if it's the if it's an

(12:57):
application that has a lot a lot of tables, it
can save a lot of time. I could see wanting
to share that CSS. Maybe that if you happen to
have a table that doesn't fit the specific you know,
presets that you've created in that component and you have
to go make a special cookie, I could see doing that.
But outside of like a very handful of extremely specific
corner cases, I personally have not found a good use

(13:20):
case for sharing styles across component.

Speaker 6 (13:22):
At that point, just put it in the baseball and
move on with your life.

Speaker 5 (13:24):
Right, Yeah, I think that only place that I've ever
seen like the encapsulation none the it's like component libraries, right,
So if you're building a component, is I mean is
that true? Yes, remembering that that was yes, the only
time where I heard that, Like, okay, yeah, let's mess
with this a little.

Speaker 2 (13:42):
Bit, because then you can guide your component that you
can add the component that's from a library into your
Angular component and then in your Angular component styles sheet,
the component style sheet, you can say like, oh, set
this variable to this, or do this, set this variable
to this blabbla or whatever, and the library exactly you're like, oh,
I'm going to use this library, but it allows me

(14:03):
to configure it on MID. So you're like you're breaking encapsulation,
but you're not breaking en capsulation within your code. You're
like leveraging the fact that they're letting you break in
capsulation for their codes that you can make it look
the way that you want to look, would still use
their things.

Speaker 7 (14:19):
And if you're going to do that, you need to
be super careful that basically a lot of properties are
set to inherit and essentially instead of like or or
you know, current color or those kind of inheritance properties
and not because if you set you know, paragraph tag
background yellow in that it's gonna have some fun side
effects right well.

Speaker 5 (14:41):
And I think you also have to be careful with
like what you need like if you're doing that, if
you're building component libraries like we worked with I worked
on an enterprise app where we were trying to switch
out component libraries, but the previous one, like all the
style names were really basic, like really basic, and it
took I don't think we ever actually fully extracted out

(15:02):
the style sheets because it it first of all, they
were everything got applied after everything else, so it didn't
matter what, like it was the last in, always the
last in, and so high specificity. It wrote everything, and
so it made it really, really really hard to get
it out because everything you couldn't do like a find

(15:24):
and replace because it was literally had names like title,
you know, like you.

Speaker 2 (15:29):
Gotta be your variables and things correctly. That reminds me
of a story back from when I was in the University
of Remember one of my professors was telling you about
how he like consulted for a company or something like that,
and uh, when they got the code base, no one
could figure out what was going on because all the
variables were named like ammals, like you know, elk equals whatever,

(15:51):
deer equals this, you know whatever. He's just like, I
don't know what any of these variables.

Speaker 4 (15:57):
Did it sounds like a joke.

Speaker 3 (15:58):
It sounds like somebody like out the program and then
wrote a program.

Speaker 4 (16:02):
To like make a joke and like hand it off
to somebody. Here you go. Ha, what I did for you.

Speaker 5 (16:07):
Sounds like a joke. But I actually have met like
students that were software engineering students who have said the
following to me. Oh, I like to give my variables
funny names because I think it's funny. No, no, no, no,
you give your test data funny data. Yes, yes, yes,
in the unit test like everybody.

Speaker 4 (16:27):
Whatever you want in the spig file, I don't care.

Speaker 3 (16:29):
You can be Star Wars themed, you can be whatever,
Bill and Bob, whatever you want. It doesn't matter to
me outside of the yes, funny, it's not funny, you guys.

Speaker 2 (16:44):
The closest I'll get to that is at Trellis, we
name all our apps after trains, so we have.

Speaker 5 (16:49):
You can be your app whatever stupid things trains.

Speaker 2 (16:53):
Yeah, because I've always I've always said, over the course
of Trellis, like, oh, like all aboard the Trellis train,
like to shoo, So we have like Aurora and Bullet
and I love that.

Speaker 5 (17:05):
All over angular and everyone you on board.

Speaker 2 (17:10):
So whenever we have to make a new app. We
always like brainstorm, Like what's what's a new train we
can name like Scotsman and Spirit and like all this.

Speaker 5 (17:18):
One named snow piercern.

Speaker 2 (17:20):
Is our is our load testing snow testing application.

Speaker 5 (17:24):
Yeah, okay, okay, this is all right. Let's go talk
about stuff. Okay, So all right, so back to like
what what does belong in that root styles dot c
s S file?

Speaker 7 (17:41):
Generally speaking, I would say anything that involves your theme, right,
so excuse me. The you're gonna look at things like
your basic fonts and setting your defaults there. I know
a number of libraries, like if you're using material a
little automatically theme and do your buttons for example.

Speaker 6 (18:01):
So depending on what.

Speaker 7 (18:04):
Any component library or you know, themes or stells library
you're using, from that standpoint, you're gonna have to worry
a little bit about collisions. But but assuming no, nothing
like that, I would do things like do basic stells
on my buttons, basing styles on my links. This is
how my paragraphs are going to look as generally speaking,

(18:24):
but very much the theme things, so like color, font size,
you know font size, basically typography things, background colors, maybe padding,
depending on the situation, But I tend to keep the
layout related things to the components because how it lays

(18:44):
out may completely differ based on now if it's may
completely differ based on where it's at or where it's
being used. So I tend not to do anything related
to positioning positioning there, but like things anything.

Speaker 6 (19:00):
Related to.

Speaker 8 (19:03):
What you'd see in a brand guide essentially.

Speaker 5 (19:05):
Right, Yeah, that makes sense. Do you ever do like
a tokenization for properties like colors and stuff like that, or.

Speaker 7 (19:14):
I'll use CSS custom properties for anything any colors because
it's that way, And I don't.

Speaker 6 (19:23):
Name them blue, red, yellow, green.

Speaker 7 (19:25):
Or whatever the color of the day, because there's nothing.

Speaker 5 (19:31):
So disappointing when you're like, oh, we just changed the
blue to green, and now everything's named blue, but no
it's green.

Speaker 6 (19:36):
Guys, Yeah, exactly exactly.

Speaker 7 (19:41):
So I generally, you know, do your standards like a
you know, primary secondary or primary accent, or if you
have a tertiary, then I'll just do primary secondary tertiary,
that kind of thing. I also, because of things like
text area not inheriting the font, I'll go ahead and
and do a custom property for my for my defont typeface,

(20:05):
simply because I know it's going to get applied to a
couple different places, and I'll usually do let's say, a
foreground and a background for each type. So let's say
you have a primary. Let's your primary is a dark blue, right,
I'll do a primary contrast of like white or something
something that way. I know, like if I have this

(20:26):
as a background color, I'm always going to use the
flip side as my foreground color or that kind of
pairing simply because that way I only have to hear
about the checking the accessibility of it once. Right, I
know those two colors work together, I can move on
with and not have to wear about it every single time.

Speaker 6 (20:44):
So I'll do that sort of thing. What else are
you usually put in there? I may do.

Speaker 7 (20:50):
I'll do the like my drop shadows, those sorts of
things that are that may be used in multiple places,
I'll do. But basically anything that it's like the same
way as you have like you might do a default
a default class or something for like all, I don't

(21:10):
know every informational informational dive or whatever you might have
a class of, like informational message where you have so
anytime I have a value that might get used where
I want it to be the same every time, but
could be used in multiple of these, like you know,
kind of high level classes. Then I'll I'll go ahead
and give it a custom property. But your heavy hitters

(21:32):
are going to be your colors, your anything related to color,
anything related to topography.

Speaker 5 (21:37):
Yeah, that makes a lot of sense. And that's the
stuff that like I feel like going into a website
if when teams, when teams don't do like design tokens
where they've sort of very much standardized how things are
supposed to look, that's where you end up in websites
where like the colors are all just a little bit off,
or like why is this spon's size screaming at me?

(21:59):
And this one is like and and and As a team,
that's like it's really really hard to manage because then
you're like, oh, they changed, you know, oh Cisco Blue
just changed from this code to this code. Now I
got to go through you either change it in the
design token or you have to go through and change
it everywhere in that yeah value, right.

Speaker 7 (22:23):
And then I have done this, and the r g
B A and the r g B and the heck
the the because there's you know, there's way yeah, and
now you've got all the color matrix functions and all
of those fun ones.

Speaker 6 (22:37):
So there's there's there's a bunch you can control find.

Speaker 5 (22:40):
For now exactly. Yeah, So that makes a lot of sense.
So then in the components, now do you do you
like do you ever work with component libraries? Does it
just kind of depend on your client?

Speaker 7 (22:55):
Depends on the project then on the client might go
to by the fill. If I'm an angular is going
to be material unless there's a compelling reason not to,
or if there's a I mean, some projects, especially simple ones,
where and the more the reality is, the more they give,
the more things become available in HTML and just raw,

(23:18):
plain old HTML and CSS, the less I tend to
use them. So I you know, back in the j
Query days, you pretty much use jQuery for everything, right,
and then there is so and then came along maybe
I don't need j querry, maybe you don't need j query, right,
and then we had we got rid of that, and

(23:38):
then everybody used either underscore low dash, depending on which
side of that fence you were in. And now at
this point with you pretty much don't need it anymore.
And I feel like there's a lot of things that
component libraries bring that over time, we won't need anymore
because like the with the pop over API, the that's

(24:00):
what they've been doing with dialogues. The fact that we
can now as soon as all the browsers are you know,
get it, implement it, you can style drop downs correctly. Ye. Like,
as more and more of those things become true, there's
going to I feel like there's going to be less
and less of a need for those heavy libraries that
can't be replaced by one or two generic components and

(24:22):
a really nicely put together style sheet.

Speaker 6 (24:24):
Yeah.

Speaker 3 (24:25):
I mean one of the benefits of that obviously is
also just like native performance, right, I would think anyways,
you know more, you know, it's almost like a lot
of these component libraries were like polyphils to some extent.
It's just the browser lacked these features or the features
in the browser were lacking themselves, and so that's where
the opportunity in the market came for these folks to

(24:46):
come out with component libraries that took care of some
of the things like drop downs and making sure they
didn't flow off the screen or you know, got positioned
correctly or had like Yeah, but it's still I would
think a performance would be a big benefit of that
because then now you're movie stuff kind of off the
JavaScript main thread and it's just going to be a
native element and you're just.

Speaker 4 (25:04):
Gonna need CSS. So J will still have to learn CSS.

Speaker 5 (25:08):
Ultimately, Hey, we'll have to wire somebody that knows CSS.

Speaker 3 (25:15):
It is interesting though, Jay, I don't want to like
aify all the things, but like, I mean, you don't
really need to know CSS, right, can't you just know?

Speaker 2 (25:25):
What I do is I go and copy it from
a spot in our code base that and built.

Speaker 4 (25:30):
Oh there you go. You already have human agent.

Speaker 2 (25:33):
Like a lot of what we do is the same thing,
just for new use case, right, Like we've already done
the table here, We've already done the thing here, and
I just.

Speaker 4 (25:42):
Go and for like new designs and stuff. I mean,
I have not used some of these tools.

Speaker 3 (25:47):
And so I don't have any particular call out, but
I'm sure that like with a coding agent, with like
playwright MCP and with a Pigma file, you can probably
just kind of like set it all up and walk away.
I'm not guaranteeing the quality of the code. I'm not
guaranteeing that, but I'm like you could probably like go
get this.

Speaker 4 (26:08):
And see what you get.

Speaker 5 (26:10):
I was talking to somebody who they they're in the
designs and they're like, I took my Figma drawings and.

Speaker 4 (26:17):
How well does it work?

Speaker 5 (26:18):
I had my agent, Well they it built it and
it was just using vanilla JavaScript and CSS.

Speaker 4 (26:24):
No talon.

Speaker 3 (26:25):
Yeah, I feel like you almost get better results because
of the the way it's atomic and this so much
training data, it feels like, but nonetheless, okay.

Speaker 5 (26:35):
So it's vanilla JavaScript.

Speaker 4 (26:37):
Just yes, I'm so curious.

Speaker 5 (26:39):
And they're like, well, and then it even noticed that,
like my style sheets were really big, so it broke
it up in the smaller style sheets and I'm like,
there's it's still the same number of styles. Like it
didn't reduce the like it's the copy paste problem, right.

Speaker 3 (26:56):
It's the same thing. It's still taking the same right,
it's still the same problem.

Speaker 4 (26:59):
Yeah.

Speaker 5 (26:59):
Yeah, like you haven't made anything. You haven't reduced that bundle,
I mean, because yeah, you're your bundler doesn't have any
idea that title in one thing that's exactly the same
as title in another thing is the exact same style,
and therefore could be you just.

Speaker 3 (27:13):
Get another, just get another yeah, and then in the
dom you end up here's the style tag, here's the
style tag, here's the same Yeah, yeah understood.

Speaker 5 (27:21):
Yeah yeah, So I mean, like I think that for
if you're just going to code out you know, like
my blog or my sample app, it's totally fine. If
you're doing it for an enterprise application that needs to perform, well,
you might want to put like a little bit of
eyes on what gets generated.

Speaker 4 (27:37):
And yeah, it's a good call.

Speaker 6 (27:39):
The maintainability. The maintainability is also not going to be there.
I mean, that's I wouldn't think so problem. So if
you want to do so, you're gonna end.

Speaker 4 (27:47):
Up nobody what's in there.

Speaker 7 (27:49):
Yeah, you're going to end up in that same problem.
I've ever tried to actually make an edit to a
PHP template for WordPress.

Speaker 6 (27:56):
Look like it's like.

Speaker 7 (27:58):
It's impossible, right, It's like it's it's right once, edit never,
And I feel like, as of right now, a lot
of what is generated is kind of that.

Speaker 5 (28:08):
Yeah, yeah, like it's it. The output works, it's fine,
But yeah, I think it's when you're compiling the pieces together,
especially on really large applications, it's harder to like it
never does the same pattern twice. Right, it's not deterministic,
which means you're going to have different ways of doing
things over and over and over again. And that just
adds to the cognitive When I'm reviewing a pr if,

(28:30):
I have to be like, Okay, wait does this work?
It does work? Why it's not like this one? But
it does work? You know. It's like, it's just that
cognitive load of that. And then you get more prs
coming out faster, so then you spend more time having
to review prs, and so it's.

Speaker 3 (28:45):
And the cognitive load that you're talking about is like, uh,
it's it's the same thing, but it's just done slightly different.
And so now I have to look like why was
that done differently? Is there a reason for that? Is
am I missing something? Is there something that?

Speaker 7 (28:57):
Like? Is it?

Speaker 4 (28:58):
Whatever it is? Could be good, could be bad. What's
the difference.

Speaker 5 (29:00):
It's like I loved using like all the JavaScript ray
methods that I forgot how to use, you know, so
I'm like, wait, what what's the shift? And unshift mess
me up every time? Never remember how that works?

Speaker 4 (29:13):
Like I think it works, it's.

Speaker 5 (29:15):
Not the way it works.

Speaker 7 (29:18):
I feel like the speed, I feel like the speed
that's gained on the dep side by just saying hey,
generate me. This is basically just being lost again on
the review and like we're not actually gaining time, we're
just shifting where that time is spent.

Speaker 5 (29:35):
Yeah, well, especially when bugs come in, like we just
had we had a big release and it was you know,
like we got everything developed and then you know, we
were testing it and we had to go through and
fix some bugs, and it was I found it more
difficult to fix bugs because the patterns weren't the same.
It's so I mean, I don't love copy paste code,

(29:58):
but I kind of do love when everybody is it
the same way because then at least I'm like, well,
I see your problem here. You forgot to do the
do to do you know or whatever. Like it's just
it just slows it down just a little bit. And
it's kind of like, you know, if you're going to
duplicate style after style of your style on your app, Yeah,
like that the amount of bundle size that is from

(30:19):
that one change might not matter, but collectively, over time
it starts to matter. So so we've kind of talked
about like where styles belong like a little bit like
because there's The reason I was asking about component libraries
is because you were talking about what kind of styles
you handle in the component. So that's the question we
should ask now, because yeah.

Speaker 7 (30:43):
I mean generally speaking, it's going to be anything that
can be affected by like a state and that what
was like And I say that loosely because like your link,
hover and focus are just going to go in your
base styles with your hover and focus. But I'm thinking
like if you're applying and actually not necessarily because you
could apply class a versus class being that class could

(31:05):
still be in the main in the main file. So
not even mostly mostly layout at the end of the day,
mostly layout. It's going to be where where do where
do I want to position web? And how do I
position you know, individual elements before container queries I would
also put I would have also said media quarries in there,
but I would almost say, now, if it's a component,

(31:28):
unless that component is clearly a page, right because angelar
doesn't differentiate between page versus component very well. Unless that
component is very specifically a page and you know it,
you know it's routed, and you know that's that's where
it's going to be. I would say that most things
in a component would probably take a container query because

(31:48):
depending on where you PLoP that component in your application,
if you have responsiveness that needs to be applied and
change of styles that need to apply based on you know,
the width or the height or the whichever direction you're
you're gonna go those that you're more worried about. The containers,
like the actual component's space, not necessarily the page.

Speaker 6 (32:12):
So I would say I.

Speaker 7 (32:13):
Would lean exceptions, of course, but I would lean towards
more container queries in the.

Speaker 6 (32:20):
In the components, unless unless it's a.

Speaker 5 (32:23):
Page, right, Yeah, that makes sense. Yeah, those are like
your page could shrink, and that doesn't necessarily mean that
you want your table to stay at one hundred percent
until it shrinks, you know, like, yeah that makes.

Speaker 10 (32:37):
Exactly Good morning, you know that moment when your coffee
hasn't kicked in yet, but your sack is already blowing
up with Hey did you hear about that new framework
that just dropped? Yeah, me too. That's why I created
the Weekly Depth Spurp, the newsletter that catches you up
on all the web def chaos while you're still on

(32:58):
your first cup. Oh look, another anger feature was just released,
And what's this typescripts doing something again. Look also through
the poor requests and change dot grama so you don't
have to five minutes with my newsletter on Wednesday morning,
and you'll be the most informed person in your stand up.

(33:20):
That's better the Weekly Desperate because your brain deserves a
gentle onboarding to the weeks tech matters. Sign up at
weekly brew dot dev and get your dose of deaf
news with your morning caffeine. No hype, no clickbait, just
the updates that actually matter. Your Wednesday morning self will
thank you.

Speaker 7 (33:39):
The other piece that I would generally put in there
are things related to like if it's I tend not
to do a lot on the route, but you could
totally do things related to that based on what the
route is gonna be, or where it's placed, or does
it have.

Speaker 8 (33:57):
Siblings of X or y or those to things.

Speaker 6 (34:01):
But yeah, those.

Speaker 7 (34:03):
Are those are kind of the But layout, the short
answer is layout.

Speaker 5 (34:07):
Yeah, and that's that tracks with what what like how
my team handles it as well, because we do you know,
we have we'd have design tokens. We have a component
system that's has you know, like it offers us full
featured components that do you know they have their own styles,
but then it's how does that component fit on this

(34:29):
you know, like okay, I need a little more space
between this line of text and the table, and the
table obviously doesn't want to be opinionated that way, So
that makes sense that that would go in the component.

Speaker 7 (34:41):
Yeah, or anythings that's that's like an exception, right, Yeah,
Like let's say this one time because it's the nave bar.
You know, you've got a nave bar component, and because
it's the nav bar, we're not going to put the
underline on the links.

Speaker 6 (34:58):
Right or like something like that.

Speaker 7 (35:00):
Then right, Yeah, that makes sense to be to potentially
be in the component.

Speaker 5 (35:05):
And it's Christmas and therefore I have to override the color.

Speaker 6 (35:08):
Yeah, exactly exactly. And this component we have an Easter egg.

Speaker 5 (35:17):
We used to with our with that Nightmare app I
was on where it had the old component system in it,
Like there would be certain components where we would have
to in each component overright the old style that was
overwriting the correct It was painful.

Speaker 6 (35:37):
I feel the.

Speaker 7 (35:37):
Need to say, regardless of where if it has the
word important, that's the red flag.

Speaker 5 (35:47):
Yeah, I had Okay, so I think we could just
do a whole story, a whole episode of like CSS
horror stories. Because the other app I was working on
it had one style sheet for the entire app. It
was an ASP web forms app, and so it had
one CSS file and the way that everybody handled fixing

(36:08):
the styles was to just go to the bottom of
the file and put it in again and then slap
on brillion.

Speaker 4 (36:15):
That's so so smart, just so smart. Keep adding.

Speaker 3 (36:20):
Man, there was this I'm off topic again, I'm sorry,
I'm in a weird news this morning, there was a
y combinator, a hacker news thing. There was a startup
that built out of a single express node file like
just Maine do ts and it was like whatever, fifty
thousand lines long, and this dude wrote a whole blog
post how they like they built a business.

Speaker 4 (36:43):
And a startup on one file. And he actually kind
of like they since had.

Speaker 3 (36:47):
Like grown and like obviously like hired you know, da
da and all this stuff, and you know are using whatever.
I'm not sure, probably next to es, but like it
was wild because they like he almost like.

Speaker 4 (36:58):
He appreciated the glory days of it.

Speaker 7 (37:00):
It.

Speaker 3 (37:00):
He was like, dude, we just all were hacking together
one file. You just push the file up, boom, done, deployed.
Like I mean, I was like I kind of like
read the article. At first, you know, you're like this is.

Speaker 4 (37:12):
This is crazy, you know, chaos whatever. You know, it's
like almost a clickbait. You're like, this can't be true.

Speaker 9 (37:18):
And then you read the article and you're like, oh, okay,
like I could see like maybe why you might do
that for a particular use case and reason, like there
might be like let's just all get together and hack
on one file and just deploy it up and like
and see what's what happens.

Speaker 5 (37:32):
Let's just like you learn anything about CSS and just
always to the bottom.

Speaker 11 (37:38):
Like it's not like it sounds so funny, Like I know,
I'm like maybe I'm just whatever. But it might work
for a time, you know what I mean, it did,
you know, but yeah it's horrible. But sometimes like horrible
things actually work, you know, and it's just like the
irony in that is all funny, and then you have
to the other side, you know. I've also like been
in the like the over engineering camp and you build

(38:00):
a ghost town, you know what I mean, Like, you know,
a year ago, we had a client build this whole
thing you know what I mean, we engineered the crap
out of it.

Speaker 4 (38:08):
It was a mobile app.

Speaker 3 (38:09):
Everything was great, you know, and that code now is
in a garbage bin somewhere and so it doesn't really matter.

Speaker 4 (38:15):
So I don't know, you know, maybe.

Speaker 3 (38:17):
We should have just shoved it all into one dot
CSS Global dot CSS, just kept slapping.

Speaker 4 (38:21):
It in there and put it out to the market.

Speaker 3 (38:23):
And then when we realized, like, this thing's not going
to go anywhere anyways, and so who cares?

Speaker 4 (38:28):
But okay, so it's really funny.

Speaker 5 (38:31):
Sorry, I feel like we all probably have horror stories
from CSS, and Martine, you do. You work on a
lot of different projects. When you walk into a project
that needs help with CSS, what are some of the
first steps you take to try to make life easier?

Speaker 7 (38:49):
I mean the first time, I'm always introduce query the
number of important because that has been a litmus test
for the health of the code base, because if if
styles were poorly managed, the likelihood of having to resort to.

Speaker 6 (39:03):
That is really, really high.

Speaker 7 (39:06):
The other thing I'll query for is the number of
classes that are set to IDs, because again you're looking
for that top level of specificity, so it means that
somebody decided to punt and went and put the style
on the ID because they knew it important was bad
and couldn't figure out any other way, right, Like, that's

(39:27):
the next level of like, I know I'm not supposed
to use important, it gives me this quigly line, but
if I put it on the ID, it doesn't give
you this quiggly line. But anyway, so I'll query those
two things because that'll generally get me some idea of
what's what, and then my next step is to usually
understand how we got there in terms of is it

(39:48):
lack of skill, is it lack of time?

Speaker 6 (39:50):
Is it churn?

Speaker 7 (39:53):
Because that will that will drastically change my approach to
how I go about and a roach fixing it because
if it's lack of skill, then me fixing it is sure,
I'll fix it, and then you're gonna call me six
months later to fix it again, which is a.

Speaker 6 (40:09):
Great business truck.

Speaker 7 (40:11):
Yeah, it's great for business, not great for your app.
Like you know, if you have to come and call
me to fix it every six months, sure that's great.

Speaker 6 (40:20):
But not not great for you.

Speaker 7 (40:24):
So that's what I'll definitely look at why the codebase
is bad. If it is bad if I'm getting called
and usually it is, but and then figure out and
then figure out how are we getting there? Is it
a copy paste from Pigma issue? Is it a Because
if it's a copy paste from Figma issue, then that

(40:44):
means there's a Pigma file, which means there's a theme
somewhere that then we can go and build and start
fixing what's there the other and then the if the
if it's a if it's simply a lack of time
and we're hacking it as fast as we can, then
then that's.

Speaker 6 (41:02):
Where I will.

Speaker 7 (41:03):
That's where we have to go figure out, Okay, what
is your theme so that I can make this easier
so that you can have the time, because copy paste
takes time. It's a lot, it's a lot more intensive
than saying, hey, if you put these two class names,
then it just works right. So those are the kind
of things I'll look into to figure out and that'll
determine where I go. Often more often than not, unless

(41:28):
somebody has prefixed. Unfortunately, gradually fixing CSS is hard because
you're you're potentially you're especially fixing the base files. That's
the downside to putting a lot of the styles in
the base files.

Speaker 6 (41:44):
Is that.

Speaker 8 (41:46):
The the you're touching everything.

Speaker 7 (41:50):
So one of the ways that it's terrible for load
is i'll like terrible for load. But one of the
ways you can gradually get around to fixing something that's
worked is you create your what will be your base file,
and then you import that in each of the components,
and then put your component styles correctly because then you're overriding,

(42:11):
right And then and then over time, once you've gone
through all of your components, then you remove your base file,
you replace you remove the base file and you replace
it with that import that you did, and and then
you can then you might have a little bit of
tweakach because maybe you had some overrides or whatever, but
it's a lot less ter now. It's terrible for load

(42:34):
on a time because you're essentially loading two main style sheets, right,
the one you're currently operating on that then overriding with
the one you're slowly creating and replacing. But that leads
to less chaos and is one way to gradually approach
it in a component architecture. But that's the only way
I've found too really. The the other to really not

(42:56):
mess with the base now the good news is most
bad code bases have every in the components and not
in the base styles. So that makes that game a
lot easier because you can if that if it's that's
the case and there's very little in the base, that
you write your base and then you go'll fix your
components one after the one after the other. But if
it's if it's the worst case scenarios, it's poorly written

(43:18):
base base file or like your SPX or whatever that
you were just describing, where there's the I mean, at
that point you just nuke the file and start over, honestly,
but the score stirt is an option.

Speaker 5 (43:36):
Yeah. I have found that with the one one good
side of well, there's many good sides of Angular, but
one good side, especially with like legacy Angular, that where
the styles have gotten out of control is that I
have found a lot of the components have they're very
heavy CSS files, and especially if the if the application

(43:59):
has been around for a while, there's almost always dead
classes in there too, like dead dead styles, and so
uh that's I'm sure there's an AI tool now that
could be better than than me at deleting dead styles,
but that was always like, uh, you know, if you

(44:19):
had a bad day. If I had a bad day
at work, Like one of my favorite things to do
is just like open a directory and just start deleting code.
And the CSS files were like a candy jar of
ten code. Well, I can't be breaking out, so every
bit you can erase is is gain in your bundle size.

Speaker 7 (44:39):
So well, because javascripture we have a really good tooling
on like this, this function is never being used, and
this functions never CSS.

Speaker 6 (44:48):
I can't not so much.

Speaker 7 (44:49):
And if you can't write click on the class name
and be like find me all instances, it just doesn't
do that.

Speaker 5 (44:55):
No, you're lucky if you can. When the worst is
when you have like s CSS and it's like and
underscore something. So it's like it just keeps like building
out the longer and longer class name, and so you
have to be very careful going through and making sure
that you understand how CSS works and how it could
possibly be used in a template so or component because

(45:16):
you could also apply it programmatically. So but yeah, okay,
so that's sort of like the worst case scenario. What
when you walk into a like, if you walk into
a project, what are some of the best situations you've
run into.

Speaker 7 (45:34):
The best situations is a well defined theme, Like even
if it's not well defined in code, if it's well
defined in terms of you have brand colors, you have
a general look and feel. You know your corners are
going to have a border radius of four px whatever
whatever the case might be, right, but you have a
well defined notion of what it's supposed to look like

(45:56):
and what how to get there and makes it a
whole lot easier because now you have some that that
style guide is going to tell is going to dictate.

Speaker 8 (46:07):
How that theme is supposed to behave, right, So.

Speaker 7 (46:10):
Best case in like best case scenario, you have that
defined really really well and then and then and then
basically you take that and apply it to your theme.
The other piece is that the theme or the let's
say you have a designer or whatever, that the designs
actually work well with the if you have a UI library,

(46:33):
that they work well with the library that you're using,
Because like, if you're doing something that each of these
each of the libraries kind of have their own kind
of feel. You can kind of tell just by looking
at them what they are, even if they've been themed.
So if you're trying to do like something that looks
like bootstrap and material or vice versa.

Speaker 6 (46:53):
That's going to be a lot harder to do.

Speaker 7 (46:56):
So making sure that whatever the whatever the designs are
are complimentary to the UI library you're using, or vice versa,
right that you're using a ULI library that is going
to work well with the designs you're handed, because I've
seen a lot of churning issues in terms of because
not all libraries are easy to theme. Some are harder

(47:17):
than others. Material has gotten a lot better. It did
not use to be quite as easy.

Speaker 5 (47:23):
I have a little opinion about this.

Speaker 7 (47:26):
I might have one too. I'm let me just put
it this way. I'm extremely happy that they want to
see SS custom properties.

Speaker 6 (47:33):
M hmm, yeah, let's just go with that.

Speaker 7 (47:37):
But yeah, so, but like making sure that those those
jibe right, because if you're fighting your if you're fighting
fighting your UI library the entire time, you're going to
have a lot harder of a time doing it than
uh than if you're not. And then stupid little things
like I will look at component structure because at the
end of the day, if you let's say you create

(47:58):
an input field just for the hell of style it,
at that point it's like, now you're having to make
sure you're reinjecting and giving as options to the component
the same things that an HTML input field would have
out of the box and everything else. So you're essentially
recreating an HTML component.

Speaker 6 (48:14):
Why right, right.

Speaker 7 (48:15):
Because now you're even though it's not strictly a CSS concern,
it's an accessibility concern. It's bloat because you have this
extra component you don't necessarily need when all of this
could have been done by a simple style sheet. So
that's where because either way you're going to have to
style it, whether you're running the styles and the component
or you're going to put it in the bay style sheet,
you're still going to have to sell that component that

(48:36):
you're created just to recreate an HTML element. So those
are I'm going to look for those patterns because then
you're going to have I'm going to basically, as a
side effect, be decreasing your load by new king some
components that you didn't need in the first place because
you could have just used the HTML out of the box.

Speaker 5 (48:54):
Yeah, I think that it's there is sort of I know,
like I love when I build a thing and it
works and it's cool and whatever, but yeah, it is.
There have been plenty of times where I've spent all
this time to I'm gonna build this like accessible thing,
It's gonna be awesome, and I'm like, oh, there's like
literally a native HTML element that does like everything I

(49:15):
needed to do. I have reinvented this wheel for no
reason at all, but look it's cool and delete. Yeah.
I think that's really good advice. And I think that's why,
you know, even though you know, like I don't love
writing CSS myself. It's mostly just I got burned out

(49:37):
doing design. I don't love I don't love it, and
that's fine. I don't have to love it, but I
do need to know when the code I'm writing is
doing something that that I could do easier, right, like
if there's an easier way to do stuff, And so
it is important to pay attention. You don't have to
be a master of CSS, but to pay attention to

(49:57):
what's going on in CSS, what's going on in HTML, accessibility, JavaScript,
all of that. So that definitely makes sense. Okay, So
one of the things you also talked about was when
you walk in and like, is it a skill issue?
How do you help teams get over their skill issues?

Speaker 7 (50:16):
Generally speaking, it depends, and some some clients have asked
me to like legitimately do formal training, which is fine,
we can. We can do you know, basically CSS one
O one or one or two or whatever you know
the case might be, and the other the other ways
to start looking at. I'll generally start like they'll start

(50:36):
running their prs through like anything that's style related. I'll
be the one reviewing the prs and then and knowing
that I'm available if they're while they're developing to help them.
So that's either through pair programming or if they have questions,
so that aspect even before we get to PR, and
then during PR scrutinizing what's being done and making sure

(50:57):
that hey, we're moving two good patterns gradually over time.
So it's generally going to be a combination of the
pair programming, the explaining a concept if somebody has a question,
the and then in the PR going oh, okay, like
this is a really bad anti pattern, let's let's talk
about it, usually at the team level at that point,

(51:19):
because if one person did it, the likelihood of others
on the team also having seen that pattern or there's
a reason that came about or whatever is high so
I'll generally talk about it, you know, with depending on
the I mean that that just depends on what the
issue is. Right, If it's just a hey, please please
use the custom properties, not the color variable or that

(51:40):
kind of stuff, right, it doesn't mean. But if it's
bigger than that, if it's pattern related, or if it's
a concept of like how to use flexbox or how
to use grid or how to do you know, how
to float around a custom shape, I don't know, you know,
those sorts of things, then I'll probably just do a
will do a meeting and kind of talk over how

(52:02):
it works. But that's that's kind of my two. It
depends on the team's needs and how bad the skill
gap is. Right. Sometimes it's just somebody knows CSS, just
hasn't done it in three or four years and therefore
doesn't know flexing grid, and it's just a matter of
bringing them up to what the new properties are. Sometimes

(52:22):
it's they've been through a code camp and it's like
the they'll know nuggets. It's like, well, no, this concept
really really well.

Speaker 6 (52:31):
And then this.

Speaker 7 (52:32):
Concept that you think they should know because it's basic
and core to CSS, and it's like no, no idea
so which is It's something I've seen several times out
of boot camp. It's it's maddening because I can I
can never guess what they know and don't know. It's maddening.
And then so it just depends the approach is going

(52:52):
to depend on the team, what the need is and
how bad the skill gap is.

Speaker 5 (52:57):
Yeah, that makes a lot of sense. I was very
lucky on our team. We all got to take Josh
I cannot say his last name, comeo. He has a
CS course that my team was. They they've ponied up
for it, and that was really good for our team
because it did it leveled us all up. Kind of

(53:19):
is pretty it's a fairly inclusive course. It was a
couple of years ago. Probably, I'm sure things have changed
and I needed to do more. But but yeah, like that,
not every team is going to be able to do
that though, So it's good good to figure out what
your gaps are.

Speaker 7 (53:37):
So the good news about CSS, though, is that like
the skills that you learned five or ten years ago,
and the skills that would have been considered good practice
five or ten years ago are still true today. Yeah,
Like it's not because we have flex and grid and
all the fun fancy new tools, the those foundational bits
that were considered good practice haven't changed. The box small

(54:00):
still the box model, the the inheritance is still inheritance
and still works the exact same way. So all of
those for people who haven't done CSS in a while
but knew it very well, they still do. Right, Yeah,
they might, it's just a matter of if they don't
know the new toys maybe, But like those in CSS

(54:21):
app that was written correctly five years ago, where the
CSS was legit or even ten or fifteen years ago,
it's still gonna be a good It's still gonna be
good code.

Speaker 6 (54:31):
Yeah.

Speaker 5 (54:31):
That makes me And that actually makes me feel better too,
because it's like it it is a time investment. If
you're not using CSS every day. It's kind of like
I forget how parts of Angular work because I don't
do it every day, Like why would I remember how
to do this, because like it's just not something I
do every day. Whereas if you're doing csf every day,

(54:53):
you know, obviously you're going to be a little more practice.
But honestly, most of the apps that I do, we
don't do the fancy stuf like I'm putting patting it
maybe a margin, you know, I don't have to go
in and be like buck shadow and like round this border,

(55:13):
radius this thing and other fancy like I will never design.
I will never be able to render the Mona Lisa
on an HTML page using only CSS Like that is
not the level of patience or skill I will ever have.

Speaker 7 (55:25):
Oh that's that's a whole different piece. The CSSR as
a whole. It might as well be its own skill
and category, like.

Speaker 6 (55:35):
That's a whole.

Speaker 7 (55:36):
Yeah.

Speaker 2 (55:37):
Nope, So I figured out what my what my problem
is is, I have no foundational knowledge. That's fair literally,
what my problem is I never actually learned what the
hell CSS is.

Speaker 4 (55:51):
Jay, you can hire Martine to come into your company.

Speaker 5 (55:57):
Number one, Jay, you have a bad attitude and you
need to learn the CSS.

Speaker 2 (56:03):
It does take.

Speaker 3 (56:05):
It does take some effort, right, I mean it does
like you can kind of hack your way through it
and just kind of figure things out.

Speaker 4 (56:11):
But if if you.

Speaker 3 (56:12):
Want to get better at it, it's one of those
things that just need to kind of go back to
the Okay, how does this actually work? You know, start
to understand some of the basics.

Speaker 5 (56:21):
I think it's kind of depends on where you are
on your team. I'm sorry, like like, yes, I don't
want to talk over you, but like Jay, you do
a lot of like I'm I'm your architects writing like
stores and figuring out how like kind of patterns we
want to follow. Than I am like okay, now, yeah I.

Speaker 10 (56:41):
Don't really buildings, that's right, Yeah, exactly.

Speaker 4 (56:46):
Yeah, you're not expected to know CSFs.

Speaker 3 (56:48):
It's like it's just not on It's not a requirement
for your position, right, you know they're not looking at
the resumes for like whatever staff architect to be like
does he know cs or does she know CSS?

Speaker 4 (57:00):
I need to really make sure that you know they
know their grid.

Speaker 5 (57:03):
And you really do want to one person on your
team that does.

Speaker 2 (57:06):
And I do listening to this, buddy, you're good.

Speaker 5 (57:14):
You know what's weird is our our isn't Andrew to
like we have an Andy on our team and he
had did he did so much work to improve our
style situation, and yeah it must be so to all
the Andrews out there, thank you.

Speaker 2 (57:32):
The best.

Speaker 6 (57:36):
You know, it's a skill. It's a skill and you
have to learn it.

Speaker 7 (57:39):
And I think with the reason CSS gets a bad
rap is because it's just easy.

Speaker 6 (57:45):
It seems easy.

Speaker 7 (57:46):
Because you can you can put a background color and
make it do something and it's not going to crash,
and you're not going to get a compiler air. It's
going to do something, and you can put uh what
what you and you tended to do is a whole
different bargain, but it's gonna do something. And so at
the end of the day, you can script by, especially

(58:09):
if you're not doing anything particularly complex. You can script
by with very mediocre code for a very very long
time and it never make a blip on the radar.
And so you know, there's a lot I think it
gets forgotten that it's a legitimate skill that needs to
be learned and has foundations and principles no different than
your dot Net or your JavaScript or your Java or

(58:32):
your Python or whatever.

Speaker 6 (58:35):
I just think it gets a little bit of a bad.

Speaker 7 (58:37):
Rap because you can get really, really far with it
without ever understanding the core principles. You're shooting yourself in
the foot. But you can get very far with it
without ever understanding it.

Speaker 5 (58:49):
Absolutely okay, So on that note, if you were to
like addressing the audience, we've got lots of people out
there that are like CSS is hard. What are the
skills you would tell people to focus on.

Speaker 7 (59:02):
First, understand the box model and understand how inheritance work,
because everything gets a whole lot easier from there when
you realize that how the box model works. The fact
that you can alter how the box model works by
using box sizing so that you can make your calculations
on your margin and paddings a lot easier because I

(59:23):
pretty much the first thing I do on every box
and box sizing border box. Thank you very much.

Speaker 6 (59:29):
On like that, right that?

Speaker 7 (59:33):
And understanding that inheritance is not magic. It can be calculated.
There's a function, right, it can absolutely be calculating a
versus be what it is. And understanding those those combinators
so like you're what both of them two classes together
without the white space in between, versus with the white

(59:54):
space and you team with this the plus the you know.
Understanding those things will get you really really fine terms
of understanding one what's already out there and two being
able to make better decisions in terms of how to
write your CSS.

Speaker 6 (01:00:08):
But those two, like the.

Speaker 7 (01:00:09):
End ill bel is, if you don't understand the box
modeley don't understand inheritance, you're you're pretty much screwed, like
in terms of truly writing you know and understanding CSS.
If those are the two things, If you don't understand
those two.

Speaker 8 (01:00:22):
You're screwed.

Speaker 5 (01:00:24):
Yeah, that makes sense because those are the those are
the those are the frustrating issues that come in right
where it's like, oh this thing, when I put this thing,
this is much longer, it overflows, or this you know,
it's always something went off the page. Something always goes
off the stupid effing page, and so it's like making

(01:00:45):
sure that doesn't happen.

Speaker 7 (01:00:47):
Or yeah, yeah, yeah, the flow a little bit, so
things like display, how display absolute versus you know not,
and how that ticks out of the flow a little bit.

Speaker 6 (01:01:00):
But I would say you're still box.

Speaker 7 (01:01:03):
Model and inheritance first, and those are the ones people
don't get. And yes it is hard, and yes it
like it is legitimately hard. Yeah, that's that's the answer.
There is No, it's not something people aren't getting. It's
not something like magically whatever you're magically going to wake

(01:01:23):
up one morning and know it it is legitimately hard.

Speaker 5 (01:01:26):
Yeah, that's you know, one of the first it might
even be the first lesson in the course Josh's course
is about the box model, and it literally just goes
through and it's like, this is what the box you know, Like,
did you know that your margins will collapse? You're like,
but why would it do that? Like I know how
math works, and no, that's not how orders or like,
that's not how margins work though, So.

Speaker 7 (01:01:47):
Yeah, and then you've got the exceptions to justify the rules,
because margins will collapse unless you're in on a grid,
for example, or unless you're you know, whatever the case
might be. But yeah, then you then you have the exceptions.

Speaker 5 (01:01:59):
Yeah, yeah, that yeah, that's I think that's really good advice.
Is there any anything new in CSS that has made
you very excited?

Speaker 6 (01:02:11):
I think the container queries are really cool.

Speaker 7 (01:02:14):
Like that was really for me one of the big
and it had and as much as these have been
out for a little bit now has because I used
to always say.

Speaker 6 (01:02:23):
You'll never be able to style something based on it.

Speaker 7 (01:02:26):
Yeah yeah, yeah, based on its parentscy I get to
eat my words on that. But like so I think
has and the container quarries are still I think one
of the biggest new changes or biggest things that came
out in CSS, and quite sometimes like there's been some
some increases in terms of colors and everything else, but impactful.

Speaker 6 (01:02:47):
I think those two, at.

Speaker 7 (01:02:49):
Least on the day to day, I find have been
the most ones, uh for me. But more than anything,
I think it's the amount of things that h the
new HTML things coming out, paired with the CSS and
that ability and those properties are what's got me really
excited because it means I mean, I love Angular, I

(01:03:10):
love JavaScript, don't get me wrong, but it means less JavaScript.

Speaker 5 (01:03:14):
JavaScript is clunky and yeah, like you said, it's I
mean it's threaded. It runs, you know, like it has
to run. It like you can really slow step down.
You know, if you're trying to manipulate the dom too much,
you end up with reflow issues. Like there's all kinds
of things that you can make harder for yourself and
make your app lest performance by trying to do it

(01:03:34):
in JavaScript when you could simply put some CSS or
use a native element.

Speaker 6 (01:03:39):
So exactly, exactly, Thank you.

Speaker 2 (01:03:43):
Thank you our team. That was very informative for me.
I'm still not going to go learn CSS, but I'm
sure everybody else feels a lot better about the CSS now. Accuracy.

Speaker 12 (01:03:53):
You talk about it well if she changed your mind,
I will let me know for sure you made an expert.

Speaker 2 (01:04:01):
Yeah, okay, duly noted. I'll keep that in mind for
the future. Well, thank you again, Thank you Brian, Thank
you Laura for co hosting with me today. Interesting conversation
for sure, there's I mean, you know, as with everything
there's you can spend your whole life learning and writing

(01:04:24):
just CSS, right when it comes to this kind of stuff.

Speaker 5 (01:04:27):
You know what this is not to like ruin the
wrap up here, but this is what I love about
software engineering, And I think what people really need to
hear is you do not have to be an expert
in everything you know, so like you can you can
do quite a bit in your career like you need.
If you see a need on your team and there
is no CSX CSS expert, go be that expert, right, Like,

(01:04:48):
go learn to be that expert. But if you've already
got two CSS experts, like, maybe you focus on something
else like.

Speaker 2 (01:04:54):
You is in not me, right, someone else?

Speaker 5 (01:04:57):
But you have Andrew, so you're good.

Speaker 2 (01:04:58):
I have Andrew exactly. Yeah, I got my CSS expert.
Another shout out to Andrew if you're listening, buddy, awesome. Well,
thank you everyone, I appreciate it, and to our listener,
thanks for tuning in. We look forward to you listening
to the next episode. Whatever that might vibe and subscribe

(01:05:19):
smash slash that like button or whatever buttons or you
can see on your screen right now when you're looking
this podcast now, bye everyone. Thanks.

Speaker 13 (01:05:28):
Hey, this is Prestol. I'm one of the NNGI Champions writers.
In our daily battle to crush out code, we run
into problems and sometimes those problems aren't easily solved. ERGI
coomp broadcasts articles and tutorials from enngie champions like myself
that help make other developers lives just a little bit easier.
To access these articles, visit medium dot com, Forward slash
n g coomp.

Speaker 1 (01:05:50):
Thank you for listening to the Angular Plus Show, a
Chiecoff podcast. We would like to thank our sponsors, the
NGICOMF organizers Joe Eames and Aaron Frost, our producer Born
and our podcast editor and engineer Patrick Kyes. You can
find him at spoonful ofmedia dot com.