interview – CSS-Tricks https://css-tricks.com Tips, Tricks, and Techniques on using Cascading Style Sheets. Sun, 27 Feb 2022 16:04:38 +0000 en-US hourly 1 https://wordpress.org/?v=6.1.1 https://i0.wp.com/css-tricks.com/wp-content/uploads/2021/07/star.png?fit=32%2C32&ssl=1 interview – CSS-Tricks https://css-tricks.com 32 32 45537868 The Making of Atomic CSS: An Interview With Thierry Koblentz https://css-tricks.com/thierry-koblentz-atomic-css/ https://css-tricks.com/thierry-koblentz-atomic-css/#comments Thu, 03 Feb 2022 15:24:01 +0000 https://css-tricks.com/?p=362578 I interviewed Thierry Koblentz, creator of Atomic CSS, to understand the history and background that led to making of the popular CSS framework. Thierry, now retired, has vast experience writing CSS at large scale and has previously worked …

The Making of Atomic CSS: An Interview With Thierry Koblentz originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]> I interviewed Thierry Koblentz, creator of Atomic CSS, to understand the history and background that led to making of the popular CSS framework. Thierry, now retired, has vast experience writing CSS at large scale and has previously worked as a front-end engineer at Yahoo!.

Thierry is widely credited with bringing the concept of Atomic CSS to the mainstream, thanks to his now classic 2013 article on Smashing Magazine, “Challenging CSS Best Practices.” That article paved the way for many popular CSS libraries over the years. In this interview, Thierry returns to chronicle the history of Atomic CSS and reflect on its ongoing legacy.

Photo of Thierry Koblentz smiling.
Thierry Koblentz

Rolling back the years to the early 2000’s, how did you get into web development, especially writing CSS to make a living?

Thierry Koblentz: I taught myself HTML, CSS, and JavaScript as a hobby after moving to the U.S. in 1997.

At the time, I was using FrontPage and was relying heavily on Newsgroups for guidance. I quickly became a regular on Macromedia NewsGroups and on CSS-Discuss. Early on, I espoused the philosophy of the Web Standard Project and got really interested in Accessibility. For years, front-end was nothing more than a hobby for me (my real job was an antique dealer). I would create a website once in a while but I was mostly writing and publishing (many) articles, sharing techniques I’d learned or “discovered.”

This paid off in the form of a phone call from Yahoo! in 2007, asking if I could help fixing and building stylesheets for the Yahoo! Site Solutions (YSS) website builder template. The job description: no HTML, no JavaScript, just CSS! And a lot of it!

What was your day job at Yahoo! like?

TK: My role at Yahoo! changed a lot through the years.

My first job was to create stylesheets (à la CSS Zen Garden) for the YSS template. I then rewrote the markup and styles of the YSS website just before YSS was “shipped” to Bangalore (India) — where I was sent with my colleagues for “transfer of knowledge” purposes.

As a sidenote, it was the challenge of swapping stylesheets to create different designs for YSS that forced us to find a light (non-js) solution for resizing videos on the fly; and that’s how I came up with “Creating Intrinsic Ratios for Video.”

After YSS, I had the opportunity to only work on projects that started from scratch (rewrites or otherwise) and I got more and more involved with Yahoo! FE. I edited and created many internal docs (i.e. CSS Coding Standards); participated in the hiring process (like everybody else in my team); led code review sessions; ran CSS classes and workshops; spoke at FED London; helped other teams with HTML/CSS/accessibility; was involved in decisions regarding technology adoption (i.e. Bootstrap or not Bootstrap); created libraries; reviewed internal papers; wrote proposals; etc.

Another sidenote, during my eight years at Yahoo!, I may have written less than 100 lines of JavaScript. And if I didn’t quit or get fired from my job, it is thanks to Lingyan Zhu and Renato Iwashima; they helped me tirelessly when it came to setting up my environment or dealing with the command line (because, to this day, I am terrible at that).

TK: In the early days, there were neither libraries nor published methodologies; it was the Wild West, everything went: “non-semantic” classes, IDs, CSS hacks, conditional comments, frames, CSS expressions, “JS sniffing,” designing primarily for Internet Explorer, etc. On my old website, I even had this comment:

<!--MSIE5 Mac needs this comment -->

Everything was fair game and everything was abused as we had a very limited set of tools with the demand to do a lot.

But things had changed dramatically by the time I joined Yahoo!. Devs from the U.K. were strong supporters of Web Standards and I credit them for greatly influencing how HTML and CSS were written at Yahoo!. Semantic markup was a reality and CSS was written following the Separation of Concern (SoC) principle to the “T” (which was overzealous for my liking at times though).

YUI had CSS components but did not have a CSS framework yet. There was an in-house CSS library (called Lego) but I never had to use it. Methodologies and libraries, like OOCSS, SMACSS, ECSS (shoutout to Ben), BEM, Bootstrap, Pure, and others would come shortly after.

What led to the idea of Atomic CSS?

TK: Before YSS was moved to India, my manager, Michael Montesano, asked if there was a way for the new team in Bangalore to avoid having to edit the stylesheet, and thus reducing the risks of breakage. I guess the YSS template experience (paying customers complaining about broken pages) made him pretty paranoid when it came to making any change to a stylesheet.

So I created a “utility-sheet” in the spirit of my ez-css library — a sheet meant to let developers achieve their styling without the need to edit or add rules in a stylesheet.

A couple of years later, Michael, then Director of Engineering, asked me if I could redesign Yahoo!’s Home Page using utility classes only, knowing that, once again, we wouldn’t be in charge of the website maintenance. We talked about prioritizing utility classes over semantic classes, something I don’t think existed at such a level at the time. It was a very bold move.

This large scale exercise quickly became a proof of concept that showed the many benefits that came with styling via markup. It checked so many boxes that it was decided that we’d use that “static” stylesheet (called Stencil) to redesign the Yahoo! My Home Page product.

Screenshot of the Atomic CSS homepage. The background is bright blue with white text that says Atomic CSS on Steroids with a Get Started button below. At the bottom is a small blurb that reads CSS for component-based frameworks.

What were the guiding principles while designing Atomic CSS (ACSS) and who were the people involved?

TK: Our Stencil library being static was a great tool to impose/enforce a design style — which we thought Yahoo! was about to adopt across all its properties. We quickly realized that this was not going to happen. Every Yahoo! design team had their own view of what was the perfect font size, the perfect margin, etc., and we were constantly receiving requests to add very specific styles to the library.

That situation was unmaintainable so we decided to come up with a tool that would let developers create their own styles on the fly, while respecting the Atomic nature of the authoring method. And that’s how Atomizer was born. We stopped worrying about adding styles — CSS declarations — and instead focused on creating a rich vocabulary to give developers a wide array of styling, like media queries, descendant selectors, and pseudo-classes, among other things.

With ACSS, developers were free to use whatever they wanted; hence teams were able to adopt different design styles and styles guides while using the exact same library. And there were some immediate benefits that were new to the way developers were used to writing styles. They no longer had to worry about breaking the page with their styling or worry about writing selectors to style their components.

ACSS was built first and foremost to address Yahoo!’s problems and to work in Yahoo!’s environment.

The people involved with Atomic CSS were Renato Iwashima, Steve Carlson, and myself. Renato and Steve created Atomizer.

What misconceptions do people have about CSS when they don’t write CSS for large enterprises?

TK: When I joined Yahoo! in 2007, I quickly learned how enormous a codebase could be. There were teams working across many locations/timezones; a myriad of products; hundreds of shared components; third-party code; A/B testing strategies; scaling as a requirement; different script directions; localization and internationalization; various release cycles; complex deployment mechanisms; tons of metrics; legacies of all sorts; strict coding standards; build processes; politics; and more politics; etc.

Most of that was totally new to me and I had to learn if and how any of it could influence the way I was writing CSS. I started to revisit and challenge all my beliefs as many techniques or methods that were common practice to me seemed to be unfit, or at least counter-productive, for complex apps.

One “reality check” relates to style abstraction. We all have read articles saying that mapping a M-10 class to margin: 10px was not a good idea as it meant to edit both the HTML and CSS to change the styling. Unfortunately, this is what happens in large/complex projects:

  • Designer: I want a 15px gap
  • Developer: OK, that’s M-3x (5px increment)
  • Designer: Sure, whatever!
  • Developer: Done!
  • Designer: Actually, 15px is a bit too big, can you make it 12px?
  • Developer: No, we don’t have that, it’s either 10px or 15px.
  • Designer: Sorry, that doesn’t work for me. Can we change M-3x to be 12px?
  • Developer: Nope! We can’t do that because other teams expect M-3x to be 15px.
  • Designer: OK, try to figure a way because we want the margin to be 12px. 15px is too much and 10px is too little.
  • Developer: (F*ck this!)

To anticipate such a problem, one needs to understand the designer’s intent behind their request: is the style chosen because of its abstraction, e.g. color primary, or for its specific value, e.g. a margin of 15px in our M-3x case? If a style guide exists to enforce design principles, then classes like M-3x may be OK, but if design teams can request any style they want, then it is much safer to stay away from naming conventions that will lead to ambiguous styling. In my experience, anything ambiguous leads, sooner or later, to breakages.

Relying on the structure of a document or component for its styling — via combinators like > or + — sounds like a clean approach to authoring a stylesheet, but it is ignoring the fact that in a complex environment one cannot assume any specific markup, or construct, to be immutable.

You think z-index is complicated? Think again when you do not even own the scope of the stack your component lives in. That’s one of the most complex issues to address in a large project where teams are in charge of different parts of the page. I once wrote a proposal about this.

Qualifying selectors — like input.required vs. .input.required — may look good and semantic but it creates an unnecessary specificity level — like 0.1.1 vs. 0.2.0 — and prevents markup change; two things easy to avoid by making sure you do not qualify your selector.

Relying on the universal selector, *, for styling global scope? In a very large project, it could mean you are styling someone else’s component. Don’t make styling decisions for people unless you know their requirements.

I am sure you have read that IDs are bad and that specificity is evil but. in fact. high specificity is not as much of a problem as the number of specificity levels your rules create. It is much easier to style within an environment where only two or three levels exist — like 1.1.0, 0.1.0, 0.2.0 — rather than an environment where specificity is rather low but follows a “free for all” approach — like 0.1.0, 0.1.1, 0.2.0, 0.2.1, 0.2.2, etc. — which often comes as a defensive mechanism in large projects as a mean to “sandbox” styles.

Blindly following advice from the CSS community may lead to unpleasant surprises. Never jump on new techniques that have not yet been battle tested. Remember will-change? And always know what every style you use does or may trigger. For example, position can create a stacking context and a containing block, while overflow can create a block-formatting context.

In my experience, knowing CSS inside-out is not enough to write CSS efficiently for a large organization. During my tenure at Yahoo!, I often found myself in contradiction with people I used to be aligned with years before. The environment is brutal and one needs to be very pragmatic to avoid many pitfalls. Next time you look at the source code of a large project and see something that makes no sense to you, remember this tweet from Nicholas Zakas:

How was Yahoo!’s transition to Atomic CSS received internally?

TK: ACSS was well accepted by our My Home Page team, but it didn’t go well outside of that. Our first interaction was with the Sports team based in Santa Monica. Steve and I were in a conference call trying to convince the developers that not following the Separation of Concern’ principle was the way to go and that it would not create chaos.

We pointed them to a piece that Nicolas Gallagher had recently written, thinking that an article from an “outsider” would help, but nope! Things didn’t go well and there was a lot of friction. The main issue was the fact that the library was made of utility classes, but its syntax did not help to ease the conversation.

I recall also meeting with the Mail team who didn’t push back on the idea of Atomic CSS, but wanted to come up with their own JavaScript approach to use “plain” CSS declarations — as they could not stand the ACSS syntax. In any case, the data in favor of the library (~36% less CSS and HTML) was speaking for itself, so ACSS was eventually adopted. And today, seven-plus years later, Yahoo! Home Page, Yahoo! Sports, Yahoo! News, Yahoo! Finance, and other Yahoo! Products are all still using ACSS.

To better understand how an approach like ACSS can benefit projects where component reusability is paramount, copy the markup of a component from Yahoo! Finance and paste it inside Yahoo! News. That component should look like it belongs to the page. This is because ACSS makes these components page agnostic.

How did the idea of using parentheses for class names manifest? Was the syntax inspired from how functions are written?

TK: We had identified — through many iterations — two sets of “candidates” to be used as delimiters for property values: parentheses, (), and brackets, [].

Renato remembers that we picked parentheses over brackets because of familiarity with functions in JavaScript, even if it came at the cost of an extra Shift keystroke. The ACSS syntax was designed to:

  • facilitate the automatic generation of rules, via Atomizer
  • allow developers to create any arbitrary or complex styles they want
  • reduce the learning curve to a minimum

It looks like this:

[<context>[:<pseudo-class>]<combinator>]<Style>[(<value>,<value>?,...)][<!>][:<pseudo-class>][::<pseudo-element>][--<breakpoint_identifier>]

Developers build their classes following the above construct. The core syntax is based on Emmet, a popular toolkit. We adopted the Emmet approach to reduce idiosyncrasies as core classes are explicit property/value pairs rather than arbitrary strings.

We also created a dozen of helper classes. Those apply multiple style declarations and are either shortcuts, like hiding content from sighted users, or hacks, like using .Cf for clearfix. And we gave developers even more latitude through the use of a config file in which they can create variables — like .PrimaryColor — breakpoints, and much more.

People who’ve never worked with ACSS will tell you that the syntax is too weird (at best), but people familiar with it will tell you it’s clever in many ways.

Talk about how your “Challenging CSS Best Practices” article for Smashing Magazine came to fruition?

TK: I had written many articles in various online publications before, so it was natural for me to write an article about this “challenging” approach.

Yahoo! was sponsoring a front-end conference in October 2013 where Renato had a talk scheduled to present our solution, and I was trying to get the article published before that. I chose to not publish it on Yahoo! Developer Network because the website did not offer a comment section. A List Apart could not publish it in time, but Smashing Magazine accelerated its review process to be able to publish the piece before the end of October.

My choice of going with a publisher who had a comment section paid off as the article received 200-plus comments which turned out to be very time consuming — and frustrating — for me who had to respond to them.

Does it feel strange that the article still carries the disclaimer about the techniques discussed, even though it is widely popular in the industry now?

TK: When the article was published, I told Vitaly [Friedman, Smashing Magazine co-founder] that that note sounded like some type of a disclaimer to me; that it would sway people in their reading of the article. But I didn’t really push back as I understood where Vitaly was coming from. I do find it amusing that note is still there now this methodology has become mainstream.

Given that hindsight is 20/20, is there anything that you want to change about Atomic CSS?

TK: There is always room for improvement, even more so when you’ve pioneered the solution. You can’t look at what others have done to learn from their mistakes or shortcomings. You don’t have material to improve upon. So, it’d be pretentious for us to think we nailed it on our first try.

On the Atomic CSS side, we had a lot of experience for having developed and used a “static” stylesheet on a large project for more than a year. But on the dynamic side — the tooling side — it’s not like we could find much inspiration out there. Remember that it took six years for other libraries to follow suit.

In French, we say: essuyer les plâtres.

One mistake we made was to use “Atomic CSS” as the title for acss.io, because as John Polacek pointed out, it created some confusion. We’ve changed that title since then.

The only regret I have is how the community has treated Atomic CSS/ACSS through the years, which recently lead to a weird exchange, where somebody explained to me what “Atomic CSS” means:

The Atomic CSS library [ACSS] uses the name but I think this is misleading, because the feature you’re talking about is the dynamic style generation. “Atomic CSS” as a generic term designates small selectors as atoms, but they’re static.

Talk about being erased. ;)

A big thanks to Thierry for participating in this interview and allowing us to publish it for the community.

The Making of Atomic CSS: An Interview With Thierry Koblentz originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]> https://css-tricks.com/thierry-koblentz-atomic-css/feed/ 2 362578 An Interview With Elad Shechter on “The New CSS Reset” https://css-tricks.com/an-interview-with-elad-shechter-on-the-new-css-reset/ https://css-tricks.com/an-interview-with-elad-shechter-on-the-new-css-reset/#comments Tue, 19 Oct 2021 14:48:40 +0000 https://css-tricks.com/?p=353462 Hey folks! Elad reached out to me to show me his new CSS reset project called the-new-css-reset. It’s quite interesting! I thought a neat way to share it with you is not only to point you toward it, but …

An Interview With Elad Shechter on “The New CSS Reset” originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]> Hey folks! Elad reached out to me to show me his new CSS reset project called the-new-css-reset. It’s quite interesting! I thought a neat way to share it with you is not only to point you toward it, but to ask Elad some questions about it for your reading pleasure.

Here’s the entire code for the reset up front:

/*** The new CSS Reset - version 1.2.0 (last updated 23.7.2021) ***/

/* Remove all the styles of the "User-Agent-Stylesheet", except for the 'display' property */
*:where(:not(iframe, canvas, img, svg, video):not(svg *)) {
  all: unset;
  display: revert;
}

/* Preferred box-sizing value */
*,
*::before,
*::after {
  box-sizing: border-box;
}

/*
  Remove list styles (bullets/numbers)
  in case you use it with normalize.css
*/
ol, ul {
  list-style: none;
}

/* For images to not be able to exceed their container */
img {
  max-width: 100%;
}

/* Removes spacing between cells in tables */
table {
  border-collapse: collapse;
}

/* Revert the 'white-space' property for textarea elements on Safari */
textarea {
  white-space: revert;
}

First, when talking about “CSS resets” we have two approaches:

  • Nicolas Gallagher’s Normalize.css is the gentle approach. Normalize.css is fixing differences between the implementation in different browsers.
  • Eric Meyer’s CSS Reset is the hard approach, saying that in most cases we don’t want basic styles from the browsers, like the font-size value we get from elements like <h1> through <h6>, or the default styles for the <ul> and <ol> list elements. For example, we use the list only for the semantic meaning, and because it helps in other ways for accessibility and SEO.

I love Normalize.css. I think it’s a must-have in any project, even if you prefer the CSS Reset idea.

And why is Normalize.css so important? Normalize.css touches shadow DOM elements that the CSS Reset doesn’t. When looking at Normalize.css, you will find special pseudo-classes like ::-moz-focus-inner, ::-webkit-file-upload-button, and more. It covers so many bases and that’s why I believe Normalize.css is a must-have in any project.

I love the hard CSS Reset as well. I think in most cases we don’t want the basic styles of the browser, and if we need it in a specific place, we will define it according to our need. This brings me to the point that I’m using both Normalize.css and CSS Reset combined. So, Normalize.css is first to load, followed by the hard CSS Reset.

So, why we need a new CSS reset? The CSS resets we have are built on old CSS features. But in the last several years, we’ve gotten new features built specifically for resetting things in CSS, and this got me thinking that now we can create a much more valid CSS reset using these new cutting-edge CSS features.

It seems to me the juiciest bit here is that very first ruleset. Let’s start with that first CSS property and value: all: unset;. That’s what is doing the heavy lifting in this CSS reset yes? How does that work?

all is the most exceptional CSS property because it allows us to reset all the properties that exist in the CSS all at once.

The property accepts several keywords. The two basics are initial and inherit; there are two smarter ones, which are unset and revert. To understand what all: unset does, we need to jump to the fundamental behavior of our CSS properties.

In CSS, we have two groups of properties:

  • Inherited properties group: These are properties that have inheritance by default — mainly typography properties.
  • Non-inherited properties group: These are all other properties that don’t inherit by default, for example, the Box Model properties that include padding, border, and margin.

Like typography properties, we want to keep the inherit behavior when we try to reset them. So, that’s where we’re able to use the inherit keyword value.

/* Will get values from the parent element value */
font-size: inherit;  
line-height: inherit;
color: inherit;

For the other properties in the non-inherited properties group, we want to get their initial value in most cases. It is worth mentioning that the initial keyword computes differently for different properties.

max-width: initial; /* = none */ 
width: initial; /* auto */
position: initial; /* = static */

After we understand the fundamentals as well as the inherit and initial keyword values, we understand that if we want to reset all of properties together, we can’t use them directly with the all property. That’s because, if we reset all of the properties to the initial value, i.e. all: initial, we lose the inherent behavior on the inherited properties group. And suppose we reset all properties with the inherit value. In that case, all the properties get an inheritance — even Box Model properties, which we want to avoid.

That’s why we have the unset value. unset resets the property according to its type. If we use it on an inherited property, it’s equal to inherit; if we use it on a natural non-inherited, it equals initial.

max-width: unset; /* = initial = none */
font-size: unset; /* = inherit = get parent element value */

This brings us back to the main feature of my CSS reset. What all: unset does is reset all the inherited properties to the inherit value, and all the other properties in the non-inherited properties group to their initial value.

This operation removes all the default user-agent-stylesheet styles that the browser is adding. To understand these substantial new CSS powers, all of this happened while I was doing only one operation to all HTML elements.

/* 
  Reset all: 
  - Inherited properties to inherit value
  - Non-inherited properties to initial value
*/
* {
  all: unset;
}

And then you follow it up with display: revert; — does all: unset; do things to the display property that would be undesirable?

Short answer: yes. The display property represents the basic structure which we do want to get from our user-agent stylesheet. As we saw in most of our properties, the unset value is doing an excellent job for us, and we reset all properties in one operation.

Now, to understand what the unique revert keyword value is doing for the display property, let’s talk about the two types of styles that we are getting from our browsers. The styles we are getting from our browsers are built from two layers:

  • Layer 1, the CSS initial value: As we already saw, the first layer is the initial values of all our properties in CSS, including the inherit behavior on some of the properties.
  • Layer 2, the user-agent stylesheet: These are the styles that the browser defines for specific HTML elements.

In most cases, when we want to reset things, we want to remove the basics styles of Layer 2. And when we do reset with all: unset, we remove all the styles of the user-agent stylesheet.

But the display property is exceptional. As we already saw, every property in CSS has only one initial value. This means that if we reset the display property to its initial, like on a <div> element or any other HTML element, it always returns the inline value.

Continuing with this logic, we connect the <div> element to the default display: block declaration, which we get from browsers. But we only get this behavior because of Layer 2, the user-agent stylesheet, which defines them. It’s built on the same idea that the font-size is bigger on heading elements, <h1> to <h6>, than any other HTML elements.

div { 
  display: unset; /* = inline */ 
}
span { 
  display: unset; /* = inline */ 
}
table { 
  display: unset; /* = inline */ 
}
/* or any other HTML element will get inline value */

This is, of course, unwanted behavior. The display property is the only exception we want to get from our browser. Because of that, I’m using the unique keyword value revert to bring back the default display value from the user-agent stylesheet..

The revert value is unique. First, it checks if there is a default style for the specific property in the user-agent stylesheet for the specific HTML element it is sitting on, and if it finds it, it takes it. If it doesn’t find it, revert works like the unset value, which means that if the property is an inherited property by default, it uses the inherit value; if not, it uses the initial value.

A diagram of all the CSS reset keywords

Then those two rules are within a ruleset with a selector where you select almost everything. It looks like you’re selecting everything on the page via the universal tag selector (*), but then removing a handful of things. Is that right? Why target those specific things?

When I started to imagine “The New CSS Reset” I didn’t think I would need exceptions. It was a lot more straightforward in my imagination.

But when I started to create experiences, I was replacing my old CSS reset with my new CSS reset (without all the exceptions), and I saw some things that broke my old projects, which I tested.

The main things that broke were elements that can get sizes via width and height attributes — elements like <iframe>, <canvas>, <img>, <svg>, and <video>. Unfortunately, when I reset everything, the width and height of those elements are defined by the auto value, which is stronger and removes the effect of the elements’ width and the height attributes.

This can be problematic because we want the exact size to come from the HTML element in cases where we add the dimensions via the HTML width and height attributes. We prefer to get it from the HTML, not from the CSS, because when it comes from the CSS, it can cause glitches when the page is loading.

The only way I found to remove the reset effect for all those particular elements is to put them under the :not() selector. In this case, my new CSS reset is harmful and not helpful, and because of that, I removed the effect for these specific elements.

Keeping specificity at a minimum seems important in a reset, so you don’t find yourself fighting the reset itself. Is that the idea behind :where()?

Yes, the idea of the :where() is to remove the specificity. We don’t need to describe more significant specificity in our CSS only to override the CSS reset.

In general, I think we will soon see a lot more cases of :where() wrapping things to remove their specificity, and not only to replace multiple selectors.

It looks like some extra special care for children of <svg> is in there. What is that about?

The second case, :not(svg *) is done with a separate :not() only because it is for a different issue. Touching the inner elements of an SVG can break the visual image, and this is one of those things that there isn’t any reasonable cause to interrupt the browser.

Let the image be an image. I say.

After the big resetting part, it goes into some bits that are more opinionated. For example, there are no browser disagreements about the initial value of box-sizing, but you’re changing it anyway. I’m a fan of that one myself, but I’m curious about the philosophy of what goes into a reset and what doesn’t.

In general, when it comes to a CSS reset, I think it is an opinion thing. For example, Eric Meyer’s CSS Reset chooses to remove the styles of specific things, and other things like the display property, are uninterrupted, which as you already saw, I totally agree with.

About box-sizing, yes, that is opinionated. I have been a web developer for 15 years. In that time, I’ve seen many web developers struggling to understand the default behavior of box-sizing, which I got so used to in the past. When there were talking about adding it to the CSS Reset many years ago, web developers, many of whom had been in the industry for a long time, were afraid of this change because, in general, people are scared of change.

But these days, I almost do not see any project that isn’t resetting all elements to box-sizing: border-box. A browser’s engines can’t fix the default awkward behavior of the default box-sizing: content-box, because if they do so, they will break support for older websites. But for newer projects, including this piece is a must since we’re left to solve it on our own.

And again, this is totally opinionated.

Two other rulesets, the removing of list styles and collapsing borders, are also in the Eric Meyer’s reset, so they have been around a long time! Starting with the list styles, I can see wanting to wipe those out as lists are often used for things that don’t need a marker, like navigation. But it feels a bit contentious these days, as list-style: none; wipes out the semantics of a list, as well on iOS. Any concerns there?

The short answer: no. No concerns on my end. Here’ why.

If we choose not to reset list-style, it means we can’t use list elements for navigation. This also means that we won’t get any semantics for any other browsers.

And now, if I need to choose between most browsers gaining these semantics, and no browsers gaining these semantics, I’m choosing the former, as more browsers gain from it than they lose.

Can you see yourself adding to this over time? Like if you find yourself doing the same things on projects over and over? Setting the max-width on images feels like that to me. Again, it’s not something browsers disagree on now, but also something that pretty much every project does.

Of course. If this reset is missing something that I didn’t consider, I will add it and release a new version. But it needs to be like your example of max-width where there is no good case where we want an image to overflow its container.

Have you seen this new Cascade Layers stuff? Any thoughts on how that might factor in to CSS resets down the road?

I didn’t think about it until you asked me. The Cascade Layers module is an exciting feature. It still doesn’t have any support, but most browser engines have already put this feature under a flag, and this means that there is a good chance that we will see this feature one year from now supported in all evergreen browsers.

For those who haven’t heard about Cascade Layers yet, the idea is that @layer can override styles without creating stronger specificity because every layer that loads after it is automatically stronger than the previous layers.

When this feature arrives, we will load the “reset” layers first. For example: first, Normalize.css, then the-new-css-reset, and then the @layer styles of the project.

@layer normalize; /* Create 1st layer named “normalize” */
@layer the-new-css-reset; /* Create 2nd layer named “the-new-css-reset” */
@layer project-styles; /* Create 3rd layer named “project-styles” */

This should make sure that the bottom layer always beats the top. This also means that removing specificity with :where(), like I did, will no longer be necessary.

@layer is one of the most exciting future features coming to CSS, thanks to Miriam Suzanne, who is doing, as always, a fantastic job.

Thanks for taking the time Elad!

An Interview With Elad Shechter on “The New CSS Reset” originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]> https://css-tricks.com/an-interview-with-elad-shechter-on-the-new-css-reset/feed/ 23 353462 Honeypot DEVS ANSWER https://css-tricks.com/honeypot-devs-answer/ https://css-tricks.com/honeypot-devs-answer/#respond Fri, 02 Apr 2021 19:34:37 +0000 https://css-tricks.com/?p=337154 I did this thing for Honeypots YouTube Channel. I had heard of Honeypot through these mini documentaries they have done, like about Vue.js, GraphQL, and Ember.js. They do a great job, so I was happy to …

Honeypot DEVS ANSWER originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]> I did this thing for Honeypots YouTube Channel. I had heard of Honeypot through these mini documentaries they have done, like about Vue.js, GraphQL, and Ember.js. They do a great job, so I was happy to shoot them over some answers to questions for this series.

Here’s a TLDR-ish transcript:

What’s the best way to stay up to date with new technologies?

Don’t worry about it much. If you’re actively building websites and solving problems that come up day to day, you’re doing the job and that’s what’s important. If you’re really worried you’re only ever using outdated tech, go to a conference once a year and see what people are talking about.

What are your top tips for career advancement?

Writing! You don’t have to blog, even though I like that idea. You can write to your co-workers, or even keep a private log. Writing really opens doors and makes you a better thinker.

What strengths are most important for a developer?

Communication trumps raw technical skill. One developer alone can never do as much as a high functioning team, and communication is what makes a team high functioning.

What what the proudest moment of your career?

I tend to look back at things that took a long time and didn’t involve just me. CodePen will be 10 years old next year. That’s something to be proud of.

When did you realize you wanted to be a developer?

I had a good teacher in high school. I’m sure they don’t even remember me, but I was highly into the computer programming class they taught. I’d come to school early to use the computer lab. I’d stay after school. I’d take my study halls there. Working on a program, with the guidance of that teacher, was deeply fun. While I ended up abandoning computer science in college for art, my career now I find was a way to marry my love of computer nerdery and art.

Honeypot DEVS ANSWER originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]> https://css-tricks.com/honeypot-devs-answer/feed/ 0 337154 Behind the Source: Cassie Evans https://css-tricks.com/behind-the-source-cassie-evans/ Tue, 02 Jun 2020 23:37:36 +0000 https://css-tricks.com/?p=312208

I feel like the tech industry takes itself far too seriously sometimes. I get frustrated by all the posturing and gatekeeping – “You’re not a real developer unless you use x framework”, “CSS isn’t a real programming language”.

I think

…

Behind the Source: Cassie Evans originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]>

I feel like the tech industry takes itself far too seriously sometimes. I get frustrated by all the posturing and gatekeeping – “You’re not a real developer unless you use x framework”, “CSS isn’t a real programming language”.

I think this kind of rhetoric often puts new developers off, and the ones that don’t get put off are more inclined to skip over learning things like semantic markup and accessibility in favour of learning the latest framework.

Having a deeper knowledge of HTML and CSS is often devalued.

Posturing and gatekeeping, indeed. I’ve yet to witness a conversation where discussing what is or isn’t “real” programming was fruitful for anybody.

Related sentiment from Mehdi Zed about PHP:

Most developers who hate PHP hate it out of elitism or ignorance. Either way it’s dumb.

To Shared Link — Permalink on CSS-Tricks

Behind the Source: Cassie Evans originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]> 312208 Uses This https://css-tricks.com/uses-this/ https://css-tricks.com/uses-this/#comments Thu, 30 Jan 2020 16:50:01 +0000 https://css-tricks.com/?p=302546 A little interview with me over on Uses This. I’ll skip the intro since you know who I am, but I’ll republish the rest here.

What hardware do you use?

I’m a fairly cliché Mac guy. After my first …

Uses This originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]> A little interview with me over on Uses This. I’ll skip the intro since you know who I am, but I’ll republish the rest here.

What hardware do you use?

I’m a fairly cliché Mac guy. After my first Commodore 64 (and then 128), the only computers I’ve ever had have been from Apple. I’m a longtime loyalist in that way and I don’t regret a second of it. I use the 2018 MacBook Pro tricked out as much as they would sell it to me. It’s the main tool for my job, so I’ve always made sure I had the best equipment I can. A heaping helping of luck and privilege have baked themselves into moderate success for me such that I can afford that.

At the office, I plug it into two of those LG UltraFine 4k monitors, a Microsoft Ergonomic Keyboard, and a Logitech MX Master mouse. I plug in some Audioengine A2s for speakers. Between all those extras, the desk is more cluttered in wires than I would like and I look forward to an actually wireless future.

I’m only at the office say 60% of the time and aside from that just use the MacBook Pro as it is. I’m probably a more efficient coder at the office, but my work is a lot of email and editing and social media and planning and such that is equally efficient away from the fancy office setup.

And what software?

  • Notion for tons of stuff. Project planning. Meeting notes. Documentation. Public documents.
  • Things for personal TODO lists.
  • BusyCal for calendaring.
  • 1Password for password, credit cards, and other secure documents and notes.
  • Slack for team and community chat.
  • WhatsApp for family chat.
  • Zoom for business face-to-face chat and group podcasting.
  • Audio Hijack for locally recording podcasts.
  • FaceTime for family face to face chat.
  • ScreenFlow for big long-form screen recordings.
  • Kap for small short-form screen recordings.
  • CleanMyMac for tidying up.
  • Local for local WordPress development.
  • VS Code for writing code.
  • TablePlus for dealing with databases.
  • Tower for Git.
  • iTerm for command line work.
  • Figma for design.
  • Mailplane to have a tabbed in-dock closable Gmail app.
  • Bear for notes and Markdown writing.

What would be your dream setup?

I’d happily upgrade to a tricked out 16″ MacBook Pro. If I’m just throwing money at things I’d also happily take Apple’s Pro Display XDR, but the price on those is a little frightening. I already have it pretty good, so I don’t do a ton of dreaming about what could be better.

Uses This originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]> https://css-tricks.com/uses-this/feed/ 1 302546 “All these things are quite easy to do, they just need somebody to sit down and just go through the website” https://css-tricks.com/all-these-things-are-quite-easy-to-do-they-just-need-somebody-to-sit-down-and-just-go-through-the-website/ https://css-tricks.com/all-these-things-are-quite-easy-to-do-they-just-need-somebody-to-sit-down-and-just-go-through-the-website/#comments Wed, 08 Jan 2020 20:23:23 +0000 https://css-tricks.com/?p=300918 I saw a video posted on Twitter from Channel 5 News in the UK (I have no idea what the credibility of them is, it’s an ocean away from me) with anchor Claudia Liza asking Glen Turner and Kristina Barrick …

“All these things are quite easy to do, they just need somebody to sit down and just go through the website” originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]> I saw a video posted on Twitter from Channel 5 News in the UK (I have no idea what the credibility of them is, it’s an ocean away from me) with anchor Claudia Liza asking Glen Turner and Kristina Barrick questions about website accessibility.

Apparently, they often post videos with captions, but this particular video doesn’t (ironically). So, I’ve transcribed it here as I found them pretty well-spoken.

[Claudia Liza]: … you do have a visual impairment. How does that make it difficult for you to shop online?

[Glen Turner]: Well, I use various special features on my devices to shop online to make it easier. So, I enlarge the text, I’ll invert the colors to make the background dark so that I don’t have glare. I will zoom in on pictures, I will use speech to read things to me because it’s too difficult sometimes. But sometimes websites and apps aren’t designed in a way that is compatible with that. So sometimes the text will be poorly contrasted so you’ll have things like brown on black, or red on black, or yellow on white, something like that. Or the menu system won’t be very easy to navigate, or images won’t have descriptions for the visually impaired because images can have descriptions embedded that a speech reader will read back to them. So all these various factors make it difficult or impossible to shop on certain websites.

[Claudia Liza]: What do you need retailers to do? How do they need to change their technology on their websites and apps to make it easier?

It’s quite easy to do a lot of these things, really. Check the colors on your website. Make sure you’ve got light against dark and there is a very clear distinctive contrast. Make sure there are descriptions for the visually impaired. Make sure there are captions on videos for the hearing impaired. Make sure your menus are easy to navigate and make it easy to get around. All these things are quite easy to do, they just need somebody to sit down and just go through the website and check that it’s all right and consult disabled people as well. Ideally, you’ve got disabled people in your organization you employ, but consult the wider disabled community as well. There is loads of us online there is loads of us spread all over the country. There is 14 million of us you can talk to, so come and talk to us and say, “You know, is our website accessible for you? What can we do to improve it?” Then act on it when we give you our advice.

[Claudia Liza]: It makes sense doesn’t it, Glen? It sounds so simple. But Christina, it is a bit tricky for retailers. Why is that? What do other people with disabilities tell you?

So, we hear about content on websites being confusing in the way it’s written. There’s lots of information online about how to make an accessible website. There’s a global minimum legal standard called WCAG and there’s lot of resources online. Scope has their own which has loads of information on how to make your website accessible.

I think the problem really is generally lack of awareness. It doesn’t get spoken about a lot. I think that disabled consumers – there’s not a lot of places to complain. Sometimes they’ll go on a website and there isn’t even a way to contact that business to tell them that their website isn’t accessible. So what Scope is trying to do is raise the voices of disabled people. We have crowdsourced a lot of people’s feedback on where they experience inaccessible websites. We’re raising that profile and trying to get businesses to change.

[Claudia Liza]: So is it legal when retails aren’t making their websites accessible?

Yeah, so, under the Equality Act 2010, it’s not legal to create an inaccessible website, but what we’ve found is that government isn’t generally enforcing that as a law.

[Claudia Liza]: Glenn, do you feel confident that one day you’ll be able to buy whatever you want online?

I would certainly like to think that would be the case. As I say, you raise enough awareness and get the message out there and alert business to the fact that there is a huge consumer market among the disabled community, and we’ve got a 274 billion pound expenditure a year that we can give to them. Then if they are aware of that, then yeah, hopefully they will open their doors to us and let us spend our money with them.

“All these things are quite easy to do, they just need somebody to sit down and just go through the website” originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]> https://css-tricks.com/all-these-things-are-quite-easy-to-do-they-just-need-somebody-to-sit-down-and-just-go-through-the-website/feed/ 3 300918 Interviewing for a Technical Position Doesn’t Have to Be Scary https://css-tricks.com/interviewing-for-a-technical-position-doesnt-have-to-be-scary/ https://css-tricks.com/interviewing-for-a-technical-position-doesnt-have-to-be-scary/#comments Fri, 26 Apr 2019 14:35:53 +0000 http://css-tricks.com/?p=286607 Jacob Schatz (@jakecodes) is a staff engineer over at GitLab and was kind enough to share how he conducts job interviews for technical positions and his thinking process for them. Technical interviews are talked about often and can …

Interviewing for a Technical Position Doesn’t Have to Be Scary originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]> Jacob Schatz (@jakecodes) is a staff engineer over at GitLab and was kind enough to share how he conducts job interviews for technical positions and his thinking process for them. Technical interviews are talked about often and can be a touchy subject for some, so it’s worth noting that this article expresses Jacob’s own opinions and are not necessarily shared by his employer.

Are you an interviewee who is terrified, exhausted, sad, or disappointed? I’d love to change that stigma.

I believe that people can have a great interview experience, and that I can simultaneously find the right candidate. Both things can happen at the same time! After your interview process is over, in a perfect world, regardless of outcome, you should feel good about yourself and the process. You might feel sad that you didn’t get the job or excited to start your new job, but you should understand why in either situation.

At GitLab, I was put in charge of hiring very early on, and as such, I’ve seen thousands of resumes. When I first joined, I was asked to hire and form a team of front-end developers. I was employee #29 (we now have 500+), and I was the first front-end developer, so there was no hiring process for our team. We gradually created a process.

This article is aimed at both the interviewee, and interviewer. For the interviewee, I want you to know what a perfect interview can be like. Interviewing should not be scary or intimidating. This is a guide you can follow to do your part in creating the perfect interview. If you are an interviewer, maybe you have perfected your process. This is my view on how interviews can go in a perfect world. There are all different types of interviews, and this article focuses on interviewing developers of all experience levels. Over the years, I’ve latched on to some great processes, and this article is a behind-the-scenes look at that process for both sides of the candidacy.

Before I begin, it’s important to remember that everyone is human and humans are not perfect. There are no perfect developers. Treat everyone like a regular human being. It’s OK to be amazed at what some people are doing, but not OK to worship others. Talent is both congenital and acquired and you can acquire it too. Your interviewer and you are both imperfect. Interviews should not be focused around perfection. Here’s what interviews should be.

Five things I look for in a candidate

The GitLab Values cover a lot of great points and you should read it. This is loosely based on those.

As an interviewer, I can only focus on so many things at once while being a productive, active listener. But I do have five specific things I am try to focus on:

  1. Does this person have a “good head on their shoulders”?
  2. Is this person technically where they need to be for this role?
  3. Is this person going to be self sufficient in this role?
  4. Does this person communicate well and will they communicate well with the team?
  5. Does this person handle positive and negative feedback well?

There are other things I’m looking for, of course, but these five things are enough to get you the job you want if you’re interviewing with me.

Forget nervousness. I won’t ever hold it against you. I know you may be nervous, and that’s totally fine. There is the rare occasion that nervousness becomes a debilitating factor, and in those cases, I just ask that you reschedule. Just don’t hang up on me!

Recognize there’s going to be bias

We have training on bias at GitLab. One thing I learned from the training is that everyone is biased, whether or not you think you are. At one point, I had the idea of doing blind interviews like they do for some orchestras. We never implemented it (and it would be tough) but that’s why I keep a list of questions and a summary of what I want to cover in each interview. Each interview has a script I can follow. Everything is as repeatable and similar as possible. As the interview progresses, I’ll be able to tell if I can hit the harder questions. Harder questions are not there to disqualify people, but to qualify people. If you get to my hard questions it means you have a ton of experience and knowledge under your belt. It’s really important to know that I must ask trivia questions in some form but I don’t qualify candidates based on trivia questions. It’s about figuring the depth of your JavaScript knowledge and programming in general.

That being said, there is still one trivia question no one has ever gotten right. I’ll just keep asking it, and I am sure some day, someone will get it. Trivia questions are fun, because I am a major JavaScript dork. I just love talking about all the ins and outs of JavaScript. I am looking for people that can be my coding buddy. Hiring people is about finding other people you can work with, not people that will work for you.

I want to know you’re technically sound

This may be people’s worst fear. The part of the interview where we ask questions like, “Why are manholes round?” The truth is that some companies may ask the medium-to-hard questions from LeetCode, and some may never ask any technical questions.

What I’m looking for in your skillset

Experience speaks louder than any technical interview question I can ask. For example, if I’m hiring for a front-end engineering role and someone tells me they built their own cool things that we can talk about, then that’s awesome. I still may need to throw some more questions their way after that, or maybe the demo answers all my questions (though unlikely, but possible). But if we can walk through the code of something that you are super proud of, that’s great.

It’s helpful if you can tell me about something that you built for another company where I can see your code, or you can explain it sufficiently enough. What were the challenges? How did you deal with 10,000 comments? How did you deal with mobile? What were some challenges? I’ll give you an example: You built the comment system for GitLab. For the comment system, an interesting challenge was dealing with loading users for the @ drop-down to mentioning other users. It turns out that the JSON payload for that drop-down can get quite large and loading it on page load makes the page load significantly slower. But loading that data on the first @ keypress is also slow because the payload can be more than 10 MB. We want the user to have a seamless experience and not realize the data needs time to load. So, a good way to talk about that experience would be to describe some of the approaches you considered, like:

  1. Load the data when the comment box first appears in the viewport.
  2. Load the data on the user’s first mouseover of the textarea.
  3. Load the data once the user starts scrolling with enough momentum.

That last one isn’t a boring solution, but is something I’ve heard someone say in an interview.

I might ask about algorithms and data structures

Hey interviewers, are you hiring someone for your marketing site? Don’t ask them the hardest algorithms and data structure questions. Yes, algorithms and data structures play a huge part in everything, but it’s more important that the candidate knows about responsive design, and maybe animations, and performance. Since we are talking about performance, they should know about Big O notation. They should know what causes re-paints. Look at Firefox Monitor and compare it to Salesforce. Everything about the Firefox site is much more snappy. Why is it more snappy? Why is the Salesforce site so chunky and slow? Resize them… oy vey! Big O would probably help you explain some parts, but being able to explain the whole picture is important.

Quick aside on Big O notation since I brought it up.

Big O is a way of describing the time your code will run in and/or the memory space your code will take up in a worst case scenario. I think it’s really great to learn, and helps out in every day programming. You can and should learn it, which might take about an hour. After one hour, done or not, you’ll more than likely be prepared for any legitimate Big O question that interviewers would ask.

Big O is not something you need to take a course on. Here are some articles that can explain it to you in under an hour:

OK, back to algorithms and data structures in interviews.

Since there’s a chance these types of questions will come up, it’s worth doing a little homework in advance. There are two typical gold standards when studying for interviews that ask about algorithms and data structures.

There are many other things that are recommended for algorithm and data structure, heavy coding interviews, but rather than memorizing every example in the world (which won’t solve any problems for you), it’s better to learn how to solve these problems.

As I said above, front-end engineers should learn Big O for their health, because it’s good for you, like eating your Wheaties. Interviewers should not ask extensive algorithms and data structure questions unless the job requires extensive knowledge of them. If I was designing a front-end framework, say like Vue, it would be important to optimize a DOM diffing algorithm or at least understand the implementation of the algorithm you are using. But does that mean I would ask seven extra hard questions from a CTCI? No. You are testing for understanding, not for memorization. When people work through these questions (when I ask them), I want to see that they thought through the problem and we worked it out together more than I want to see that they got the right answer. It’s all about figuring out what you will be able to do, as an engineer, when you get the job — not what you memorized yesterday. A person who has knowledge of algorithms is going to be better at implementing them than someone who has to learn them on the job.

Are you hiring someone to build a dependency management system? This person needs to know a lot about algorithms and data structures.

These are two extreme ends of the spectrum, but in my opinion, not everyone needs to know how to write a red-black tree from scratch — but everyone should understand Big O. However, it will dramatically improve your skills as a software developer to learn typical algorithms and data structures.

When I do ask algorithm and data structure questions here are a few I do ask:

  • What is a linked list and can you show me how to implement one with and without an array in JavaScript?
  • What is the difference between BFS and DFS and can you implement one of them?

Getting these wrong will not disqualify anyone. Remember, I don’t use trivia to qualify people.

Do you have a good head on your shoulders?

There are a lot of soft skills I’m looking for as well during the interview. It’s my way of determining whether you have a “good head on your shoulders.”

Pedantically speaking, that means you make good decisions, but it’s much more than that to me. People who have a good head on their shoulders make sound decisions. It’s good to have different opinions than me, but there is a standard of knowledge we should agree on. For example, we should all agree that laying out an entire blog with only absolute positioning is a bad idea. That is not a sound decision.

But I might create a scenario like this to check on those skills:

Let’s go into CodePen and create a static blog homepage. We’ll need a navigation menu, and we’ll need a place for the title and article, and then at the bottom let’s have some comments and a footer.

I’d then talk you through different ways you could create the navigation and the pros and cons to each. For a lot of the front-end developers I hire, I’d like to know that they know some core JavaScript so I might ask them add some small functionality using only vanilla JavaScript.

When a framework does everything for you, you don’t need to do things yourself. I want to know that you get the whole picture.

A “good head on you shoulders” is a fancy way of telling me that you have your crap together. This is not an exhaustive list, but are the types of things that catch my attention:

  • You take care of yourself
  • You speak professionally (this has more of an impact than most people know)
    • Leave out super personal details
    • Answer questions succinctly
    • Take time to think
    • Say, “I don’t know,” when you don’t know
    • Be confident, but not cocky, even if you aren’t
  • You finish what you start
  • You are honest
  • You are able to say no
  • You know what you want and you want to help others get what they want
  • You’ll disagree and even debate, but know when to let something go
  • You are able to effectively communicate in an interview
    • Is this conversation easy or exhausting?
    • Are you fluent in English? Accents are totally OK!
    • Do you grasp the concepts being discussed?
  • You’re a kind person.

On that last point: kindness doesn’t mean you are a pushover. Kindness is a major part of challenging others and giving feedback.

I want to see that you are self-sufficient

It seems obvious now, but I am convinced — after working at GitLab — that self-sufficiency is what interviewers should seek in everyone being hired. Self-sufficiency plays a big part in your role in the company.

For example, to go extreme, think about a GM, who may have the least amount of external direction of anyone on a team. Everyone has responsibilities, but a GM must often be good at many things, including (but not limited to) marketing, sales, and management. All this changes based on the size of the team. Their role may be the most vague. They are very self-sufficient. A senior developer (in my opinion) should be able to take on an entire large piece of functionality and implement it properly.

This is not to say a developer shouldn’t communicate during the process. They should ask questions, and pair with other people to find the best way forward.

Reviewing an interviewee’s code has the opportunity to be boring (in a good way) as we know what to expect from them. We are relying on them to mentor less experienced developers. Junior developers should be self sufficient too, but probably won’t take on large initiatives alone. Junior developers often work great in small chunks. For example, it might be a great thing for a junior developer to take on the smaller tasks that a senior developer has on a larger project. Senior developers can also mentor junior developers and nudge them in the right direction to help them become more self-sufficient, which is a great thing for both parties — and also a great thing for the manager, as they can delegate more work to a senior developer.

If you are a front-end developer and need hand-holding at this point in your career, that is totally 100% OK, and everyone has been there. Or, if you are applying to a lot of places and not getting anywhere, and are extremely frustrated: I suggest that you become a little more self-sufficient before you apply. One way I suggest to become more self-sufficient and nab that job you want: Forget code examples, little shopping cart apps, and their ilk, as they don’t fair well for job interviews. Build something full-fledged for someone and do it for cheap or free. Find a church, synagogue, homeless shelter or someone near you and offer to make them a website.

Just remember that free clients are often the worst clients. It will be worth it when you can say that you’ve done work for a few clients. For bonus points, document your work in a few blog posts. This stuff looks great on resumes and will make you stick out from the rest. I know that anyone can get an easy website through Wix or other site building platforms, but there’s nothing like a wonderful custom-designed website. I think I made around 10 or so websites before I had my first programming job. I could fill a book with crazy stories from those times.

Communication and feedback is key

This is another point that seems obvious, but is hard to do right. Communication is well documented in the GitLab Handbook so I won’t cover it, except to say that I follow GitLab’s values and we are looking for others who desire to follow those values as well. Positive and negative feedback is also well documented in the GitLab Handbooks, so I won’t cover it here.

How I go about the rest of the interview

Because we interview a lot of candidates at GitLab, we follow a common flow so we can repeat it easily. I won’t go into specifics about our interview process, because it’s constantly evolving. But, in general, this is the flow I follow.

Tell me about yourself

You’ll get asked the famous question that goes along the lines of “tell me about yourself,” “tell me what you’ve been doing,” or “tell me about your time at [Company Name].” When I ask this question, I am trying to find the connection between the job you applied for and the jobs you’ve had in the past. It’s good to find the common ground ahead of time.

Like, for example, as an employee of GitLab, if I were personally applying to a FAANG as a front-end engineer, I am sure both GitLab and that company are trying to get page load times to be faster. Maybe I noticed there were 26K event listeners on a page when I first joined GitLab and was able to reduce it down to 0, decrease the loading time by 50%, down to a speed of 200ms. I am sure this would be something relevant to the conversation.

So, as an interviewee, I might say something like this:

“Hi! I am a front-end engineer at GitLab, I’ve been here for 3.5 years and during my tenure I’ve made a ton of huge improvements, some of the areas I loved working on are performance, UX design implementation, and architectural design.

You don’t want to get into tons of details at this point, but it’s good to give the interviewer some facts to work with. It is frustrating when I ask this question and someone goes into a 10-minute detailed account of their entire career.

What made you apply to our company?

The interviewer might ask, “What made you decide to apply to our company?” Hopefully, you are excited to work at this company — otherwise, why bother applying for it?

For some reason or another, this question often sends a candidate into overdrive and they wind up mixing up the name our company. That’s perfectly normal behavior, especially if your company sounds like another company.

What I’m looking for at this point is to see whether you are just looking for a job or that you’re really excited to work with us. We want people who really want to work with us. This is when I can also see if a person knows anything about our company. For example, some people like our values, have read them and want to work at a company with these values. Some people want to solve big problems like the ones we are tackling. Some people have seen talks and read articles from our team and would love to work around smart people like them.

What are your five things?

Lastly, I like to ask if a candidate has any questions for me. This is an important part of the interview, and you should extensively think this through beforehand. Your goal is to make me respond with: “Oooohhh, great question!” On one hand, I am truly trying to answer any questions you have, so don’t be shy. On the other hand, I am also trying to gauge your interest in the job, so something like, “Uh, I dunno,” is usually a big bummer to hear because it signals that maybe you’ve tuned out, or the job is not interesting to you. that’s can leave an undesirable aftertaste.

Look up your interviewers and find out about them. Doing this in advance can be an eye-opening exercise. You might find out about their customer acquisition strategy which could lead to a ton of other interesting questions. If the company is a startup, do they plan on being acquired, or do they want to IPO? When you have a clear, well-thought question, it makes you sound professional, which again, is one of the things I listed as important.

If you can’t think of any questions to ask, then do you really want this job in the first place? If the interviewer has a personal website, go check it out, and if nothing else, you can ask them about the comic book they wrote and posted to their website.

But I’d advise:

  1. Ask the interview questions that you are generally interested about. Think about this before the interview because a really thoughtful question generally improves your candidacy quite a bit.
  2. What are you, the candidate, looking for in a company? What does this person, the interviewer, need to prove to you in order for you to take this job?
  3. Do these people have a good head on their shoulders like you do? It works both ways, you know.
  4. Does this look like a fun job? Do you even want a fun job?
  5. Who would you report to? Did you talk to them? Will you get a chance to during the interview process?
  6. Are you underrepresented? Like, are you replacing someone or filling a new role? How many others will be doing what you’re doing? What signs should other underrepresented people look out for? What signs would show you that this is a good environment for you?

Don’t ask about money or benefits at this point; those things can (and likely should) be covered with a recruiter introduction call before you get to a person like me.

Conclusion

Interviewing, unlike programming, is not an exact science. You’re trying to prove that you are excited about the prospect of working with a company. You want to prove this to the interviewer and yourself. Hopefully, you want a job that is interesting. This guide isn’t a script to follow, but more of a few loose ideas to help you get into the mindset of the interviewer, with a few tips for other interviewers strung in there as well. Maybe I pointed out things you might not have known before.

Just remember that, in theory, interviewing should not be a scary process, but more of a find-some-buddies-to-work-with process.

Interviewing for a Technical Position Doesn’t Have to Be Scary originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]> https://css-tricks.com/interviewing-for-a-technical-position-doesnt-have-to-be-scary/feed/ 4 286607 An Interview with Håkon Wium Lie https://css-tricks.com/interview-hakon-wium-lie/ Mon, 18 Apr 2016 19:40:40 +0000 http://css-tricks.com/?p=240639 Håkon Wium Lie is one of the co-inventors of the original CSS specification. This interview digs into the past and future of CSS:

If CSS hadn’t been developed, designers might have gone elsewhere, explains Lie. HTML could have turned into

…

An Interview with Håkon Wium Lie originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]> Håkon Wium Lie is one of the co-inventors of the original CSS specification. This interview digs into the past and future of CSS:

If CSS hadn’t been developed, designers might have gone elsewhere, explains Lie. HTML could have turned into more of a page description language, akin to PDF. Indeed, designers had already started making pictures out of their documents. “Because that meant you could control every pixel in there. So you could get the fonts, colours, you needed. You still see some of them around. If that had become the norm, we could have ended up with the web being a giant fax machine.”

To Shared Link — Permalink on CSS-Tricks

An Interview with Håkon Wium Lie originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]> 240639 An Interview with Andy Fitzsimon about logomono https://css-tricks.com/an-interview-with-andy-fitzsimon-about-logomono/ Mon, 15 Feb 2016 15:28:00 +0000 http://css-tricks.com/?p=238003 I got an email from Andy Fitzsimon the other day about some projects he’s working on. One of which was logomono, something I thought looked pretty interesting and shared the other day. I thought, rather than trying to …

An Interview with Andy Fitzsimon about logomono originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]> I got an email from Andy Fitzsimon the other day about some projects he’s working on. One of which was logomono, something I thought looked pretty interesting and shared the other day. I thought, rather than trying to figure things out and re-explain them myself, I’d just ask Andy himself to answer my questions. Interview style.

My questions as headers; Andy’s replies follow.

Can you give us a quick explanation of exactly what logomono is and what the motivation is behind it?

logomono is a big(ish) and growing GitHub repo of one-color SVG logos. The project exists to promote care for how we use and reference logos on the web.

The site also covers some techniques, a few tools, and some tutorials aimed at making it easier for designers and developers to use logos.

To keep things super simple, all the SVG’s are made of only a few flat <path>s and no color.

The first thing presented on the logomono homepage is an idea for making logos work on dark or light backgrounds. Is that a problem you’ve faced? Do you think that’s a prereq for any truly robust logo?

For so many existing logos, inverting correctly is certainly a polite and a nice thing to consider. It is a feature of logos that is largely ignored today. If the logo you use features shading (or a handful of other considerations), there likely a different version and you should use on dark backgrounds. For logo designers, it’s a commitment to make multiple variants of logos to work for both light and dark situations, but it’s a fairly common need. Remember your logos aren’t always exclusively used by you.

logomono was was born from frustrations at my day job as a brand manager at Red Hat. Shadowman (the icon in the Red Hat logo) has a shadow cast over his eyes. It doesn’t really work when the same fills are inverted on dark. He’d be more a laser-eyed man with those dark bits filled in white.

The same can be said for my two favourite open source project logos:
Inkscape (which features inky the splotchy mountain) and Linux (with Tux the penguin)

We know Penguins have black wings and white bellies. We know that ice caps on mountains need to be lighter than the mountain. It’s amazing that this detail can be so looked over.

To help with this problem, we could tell this a million times to a million designers through our lifetimes. Or, we could write it down and try make it useful enough to remember. That’s why logomono exists.

At work I’m always getting proofs of things from customers, partners or staff using a wrongly inverted one color Red Hat logo. It hurts double time. One, because it’s the wrong logo. Two, because some poor bugger had to go to the effort of making it from the full color logo they probably found on Wikimedia. Maybe they even guff up the coordinates. Maybe our logo loses it’s nose.

Some designers search “one color [company name] logo” and find the right thing for the right background. But today, all they get are sites like Brands of the World and Wikimedia. Not to mention there are nasty sites out there with downloadable files created from auto-traced vectors and very old logo versions that just won’t die. I want to proactively serve them the better versions. I want to raise awareness that inversion is a thing the folks behind the logo would like to be considered.

Being mono-color is part of the deal, too. In my case, I want our red hat to be, well, red, but when stacked next to other company logos I can understand the the need for visual harmony.

It looks like an inversion-ready logo requires some hide/show flip-flopping and sometimes additional elements. Is resource size any concern there? Or the embedding technique?

I suggest two optional classes for potentially three types of <path>s:

  1. Normal paths. No classes needed. They should show all the time. Usually logo text and, for many brands, the entire logo outline. Nike, IBM, Intel… You lucky brands!
  2. Only light backgrounds. Use class="only-light-background" for shapes that should be rendered as darker fills on lighter backgrounds.

    Think: anything with eyes. You want the path that draws the pupils dark. Look at brand marks for Hadoop, Tux, or even companies without mascots like Ford that prefer their name be written as light text and inverted accordingly.

  3. Only dark backgrounds. Use class="only-dark-background" for paths that only work as a light fills on a dark background.

Defaulting to the assumption of a light background is how we’re storing them in the repo. That way the files are still usable in their raw form. That means inline style="display: none;" is in use on the paths for only dark backgrounds. This can be removed in the build process.

How you use logomono could be different depending on what you need to do. If you have some interactivity that inverts the background, then it makes sense to keep all paths together in the SVG and overwrite the display, opacity or visibility values in your CSS to flip the light and darks as you need them.

If you only need one version (a dark or light version) then you could use logomono logos but have a tool like Gulp or Grunt run a task that strips the paths you don’t need.

You suggest using a viewBox but not height or width attributes. Is that recommended in production, or do you mean those can be added later? I’ve found without a default width/size, the SVG will be as-wide-as-it-can-be until CSS resizes it, which can be an unfortunately janky loading experience.

It’s to keep the repo lean and mean. We want width and height to stay away until the user knows what they want.

If you take every logomono file and add some random dimensional attributes like width="100px" height="76px" to the <svg>, nothing will break. You’ll have every logo in the size you declared and avoid the janky load. That can’t be said for a folder full of different sized logos. We can’t know your preferred dimensions ahead of the time, so we don’t add them (but you can).

Sites like Slides.com do this in a nice way, if you upload a viewbox-only SVG, the importer adds width and height attributes using the viewbox dimensions.

Another thing you recommend is 4% spacing around the logo because of aliasing. Can you elaborate on that? I would worry that aligning logo exactly to an edge then requires potentially frustrating pixel by pixel nudging.

This is something I’d like more feedback on. The problem is antialiasing overflows.

At first I was like “let’s make the source repo SVG’s go straight up against the wall: 0 0 min and max of their viewBox!”.

My thinking was that we could always use post processing to add the same gap dims to the viewbox to avoid antialiasing overflows. So for example, say a logo has viewBox=”0 0 120 150″. The processing makes it viewbox="-4 -4 124 154". Say another has viewBox="0 0 50 70". It becomes viewBox="-4 -4 54 74". This dodges the potential overflows.

But then I got thinking that adding and removing 4 to each axis in the viewBox would be different for SVG’s that have “big” coordinate systems versus “small” coordinate systems. Maybe it has to be based on a calculated percentage of the total of the viewBox lengths.

Then I realized doing all this in post processing would mean the source logos in repo would all be prone to the scaling aliasing issues as-is, which is a no-go because these files must be useful in their own right.

Then I got to thinking that this “4%” suggestion gives logo contributors a very small amount of discretion for optical adjustments.

Even if we lived in a magical land where scaled SVG had no hard edge aliasing problem, logos are like typography. Round forms and angles like O’s and W’s need to be nudged over the perceived edge lines to appear straight. 4% seemed like the easiest compromise.

For now, we’re throwing this whole idea into the “too hard basket”. Maybe we’ll re-compute the coordinates for the existing logos, but not today.

We designers are doomed to do the nudging when we layout our work. Hopefully with 4% as a general rule this becomes as minimal as possible. For the life of me, I can’t find out the right way to store and respect all the balancing factors at play that designers want to juggle:

  • Logo and text along a baseline
  • Thickness and weight balance
  • Left/Right optical alignment

All while making these files “raw” enough to be basic building blocks of the web: easy to contribute; easy to use. At least now they’ll be close enough for forgiving eyes to deal with. Nudge away, soldier!

Maybe in the future when the web has wonderful things like element media queries we can expand logomono to include a general rule of thumb for vertically or horizontally stacked logos, or logos that collapse to an icon. For today, let’s keep things simple.

Can anyone contribute? If they can, what would be the most useful work?

Anyone can contribute:

  • Mono-color Logos. By far the most useful contribution. Find the logos that are missing and send a pull request. Boolean those clip paths, outline that text, combine those duplicate control points.
  • Tool and project page improvements.
  • Awareness that some logos need inversion love.

It helps greatly if you are responsible for the brand in question so that the files can be optimised exactly as you want. But don’t let that stop you if you’re looking to add another logo.

An Interview with Andy Fitzsimon about logomono originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

]]> 238003