Ah, the age-old cry of “Make the logo bigger!”—a phrase that echoes across boardrooms, email threads, and designers’ nightmares.

For decades, graphic designers have faced this seemingly innocent request from clients who are convinced their logo is the single most important element of any design. But let’s dive into the hilarity of this request and why it might just be the design world’s version of asking a chef to “make the salt saltier.”

Act I: The Grand Entrance

Picture this: a beautifully crafted webpage, sleek and modern, where every element is balanced like a Michelangelo fresco. The client takes one look and says, “Wow, this is amazing! But… can we make the logo bigger?”

Bigger? Bolder? Flashier? They might as well ask you to tattoo the logo on the forehead of every visitor. The designer adjusts it, reluctantly, to the size of a medium-sized pizza.

“Still not big enough,” the client insists.

By the end of the meeting, the logo has grown so large it resembles Godzilla rampaging across your meticulously designed Tokyo of whitespace and typography.

Act II: Science vs. Subjectivity

Designers are quick to pull out studies about visual hierarchy, explaining how a logo that’s too big can overshadow the message. But clients have a counterargument: “People won’t know it’s us!”

Ah yes, because your company’s success clearly hinges on whether your logo is visible from outer space. Forget about compelling copy, cohesive branding, or user experience. It’s all about that sweet, sweet real estate—the Helvetica equivalent of owning a penthouse suite on the design canvas.

Act III: The Slippery Slope

Once the logo reaches gargantuan proportions, it opens Pandora’s box.

• “Can we make it spin?”
• “How about if it follows the user’s cursor around the screen?”
• “Could it emit a subtle glow? Like a lighthouse guiding lost consumers?”

At this point, you’ve gone from crafting a masterpiece to leading an avant-garde art project involving flashing lights and motion sickness.

Act IV: The Compromise

Experienced designers have a strategy: they make the logo slightly bigger—just enough to satisfy the client—then distract them with shiny things elsewhere in the design. “Look at this CTA button! Isn’t it amazing?” they’ll say, as the logo hovers ominously at an almost-reasonable size.

Sometimes, though, the client won’t budge. That’s when designers create a separate “Big Logo Concept” that looks like a Times Square billboard ad. The client immediately realizes, “Oh… maybe that is a little much.” Victory!

Epilogue: The Bigger Picture

The obsession with bigger logos is a testament to the love clients have for their brands. They want to be seen, remembered, and cherished. And honestly, who can blame them? It’s like a parent wanting their child to be front and center in every school play, even if they’re playing Tree #4.

So, the next time a client asks to make the logo bigger, remember: it’s not just about the logo. It’s about making them feel seen and heard. And if that means turning their logo into a blimp-sized beacon of self-assurance, well, at least you’ll have a good story for the next designer meet-up.

And hey, if all else fails, you can always charge by the square inch.

If you’ve ever used Reddit to dig for answers or insights, you know how much gold is hidden in its threads—but finding it isn’t always straightforward.

That’s where Reddit Answers, the platform’s new AI-powered feature, steps in. Think of it as your personal guide to navigating Reddit’s vast treasure trove of conversations.

Here’s everything you need to know about Reddit Answers, how it works, and why it might just become your go-to tool for discovering information.

What is Reddit Answers?

Reddit Answers is Reddit’s way of making its platform smarter and easier to use. It takes your questions—anything from “What’s the best way to learn a new language?” to “How do I fix a squeaky door?”—and provides an AI-generated summary based on discussions across Reddit.

But it doesn’t stop there. It also points you to related posts and communities where you can dive deeper into the topic.

Think of it as the lovechild of Google Search and Reddit, combining the search power of AI with the authenticity of real user conversations.

Why Should I Use It?

If you’ve ever felt overwhelmed scrolling through endless Reddit threads, this tool might be just what you need. Here’s how Reddit Answers helps:

• Saves You Time: Instead of sifting through dozens of posts, you get a quick, curated answer.
• Keeps It Authentic: The insights come straight from Reddit’s communities, meaning they’re packed with real-world advice and experiences.
• Makes Exploring Easier: Want more details? Reddit Answers provides links to the original posts and related communities so you can dive as deep as you want.

For instance, if you’re researching the best gear for a hiking trip, Reddit Answers might summarize advice from multiple communities, then lead you to posts where outdoor enthusiasts discuss their favorite brands and strategies.

How Can You Use Reddit Answers?

As of now, Reddit Answers is available to a limited number of English-speaking users in the U.S. If you’re lucky enough to have access, you can use it to:

1. Ask Broad Questions: Don’t know where to start? Throw in a general query and let Reddit Answers guide you.
2. Explore Communities: Use the links provided to find niche communities full of experts and enthusiasts.
3. Save for Later: Found a goldmine of advice? Bookmark the links to revisit them anytime.

Is It Destroying the Essence of Reddit?

The real magic of Reddit has always been its messiness—the diverse perspectives, the debates, the occasional rabbit holes that lead you to unexpected gems.

Reddit Answers seeks to cut through that chaos, but some might argue that it also filters out the spontaneity and depth that make Reddit special.

If you’re looking for a quick answer, this feature might be perfect. But if you’re the kind of person who values the journey as much as the destination, you might find yourself missing the raw, unedited experience of diving into threads yourself.

To sum up

Right now, Reddit Answers is only available to a limited group of users in the United States, but Reddit plans to roll it out to more regions and languages soon.

Whether it becomes a cornerstone of the Reddit experience will depend on how it evolves. Will it remain a helpful shortcut, or will it fundamentally reshape how people interact with the platform?

There’s also the question of trust. AI is great at summarizing, but it’s not immune to error or bias.

Will Reddit Answers capture the nuances of human conversations, or will it risk misrepresenting them? These are questions Reddit users—and the platform itself—will need to grapple with as the feature grows.

Go to Reddit Answers

The CSS Working Group (CSSWG) meets weekly (or close to it) to discuss and quickly resolve issues from their GitHub that would otherwise be lost in the back-and-forth of forum conversation. While each meeting brings interesting conversation, this past Wednesday (December 4th) was special. The CSSWG met to try and finally squash a debate that has been going on for five years: whether Masonry should be a part of Grid or a separate system.

I’ll try to summarize the current state of the debate, but if you are looking for the long version, I recommend reading CSS Masonry & CSS Grid by Geoff and Choosing a Masonry Syntax in CSS by Miriam Suzanne.

In 2017, it was frequently asked whether Grid could handle masonry layouts; layouts where the columns (or the rows) could hold unevenly sized items without gaps in between. While this is just one of several possibilities with masonry, you can think about the layout popularized by Pinterest:

In 2020, Firefox released a prototype in which masonry was integrated into the CSS Grid layout module. The main voice against it was Rachel Andrew, arguing that it should be its own, separate thing. Since then, the debate has escalated with two proposals from Apple and Google, arguing for and against a grid-integrated syntax, respectively.

There were some technical worries against a grid-masonry implementation that were since resolved. What you have to know is this: right now, it’s a matter of syntax. To be specific, which syntax is

a. is easier to learn for authors and

b. how might this decision impact possible future developments in one or both models (or CSS in general).

In the middle, the W3C Technical Architecture Group (TAG) was asked for input on the issue which has prompted an effort to unify the two proposals. Both sides have brought strong arguments to the table over a series of posts, and in the following meeting, they were asked to lay those arguments once again in a presentation, with the hope of reaching a consensus.

Remember that you can subscribe and read the full minutes on W3C.org

The Battle of PowerPoints

Alison Maher representing Google and an advocate of implementing Masonry as a new display value, opened the meeting with a presentation. The main points were:

1. Several properties behave differently between masonry and grid.
2. Better defaults when setting display: masonry, something that Rachel Andrew recently argued for.
3. There was an argument against display: masonry since fallbacks would be more lengthy to implement, whereas in a grid-integrated the fallback to grid is already there. Alison Maher refutes this since “needing one is a temporary problem, so [we] should focus on the future,” and that “authors should make explicit fallback, to avoid surprises.”
4. “Positioning in masonry is simpler than grid, it’s only placed in 1 axis instead of 2.”
5. Shorthands are also better: “Grid shorthand is complicated, hard to use. Masonry shorthand is easier because don’t need to remember the order.”
6. “Placement works differently in grid vs masonry” and “alignment is also very different”
7. There will be “other changes for submasonry/subgrid that will lead to divergences.”
8. “Integrating masonry into grid will lead to spec bloat, will be harder to teach, and lead to developer confusion.”

alisonmaher: “Conclusion: masonry should be a separate display type”

Jen Simmons, representing the WebKit team and advocate of the “Just Use Grid” approach followed with another presentation. On this side, the main points were:

1. Author learning could be skewed since “a new layout type creates a separate tool with separate syntax that’s similar but not the same as what exists […]. They’re familiar but not quite the same”
2. The Chrome proposal would add around 10 new properties. “We don’t believe there’s a compelling argument to add so many new properties to CSS.”

3. “Chromium argues that their new syntax is more understandable. We disagree, just use grid-auto-flow“
4. “When you layout rows in grid, template syntax is a bit different — you stack the template names to physically diagram the names for the rows. Just Use Grid re-uses this syntax exactly; but new masonry layout uses the column syntax for rows”
5. “Other difference is the auto-flow — grid’s indicates the primary fill direction, Chrome believes this doesn’t make sense and changed it to match the orientation of lines”

6. “Chrome argues that new display type allows better defaults — but the defaults propose aren’t good […] it doesn’t quite work as easily as claimed [see article] requires deep understanding of autosizing”
7. “Easier to switch, e.g. at breakpoints or progressive enhancement”
8. “Follows CSS design principles to re-use what already exists”

The TAG review

After two presentations with compelling arguments, Lea Verou (also a member of the TAG) followed with their input.

lea: We did a TAG review on this. My opinion is fully reflected there. I think the arguments WebKit team makes are compelling. We thought not only should masonry be part of grid, but should go further. A lot of arguments for integrating is that “grid is too hard”. In that case we should make grid things easier. Complex things are possible, but simple things are not so easy.

Big part of Google’s argument is defaults, but we could just have smarter defaults — there is precedent for this in CSS if we decided that would help ergonomics We agree that switching between grid vs. masonry is common. Grid might be a slightly better fallback than nothing, but minor argument because people can use @supports. Introducing all these new properties increasing the API surfaces that authors need to learn. Less they can port over. Even if we say we will be disciplined, experience shows that we won’t. Even if not intentional, accidental. DRY – don’t have multiple sources of truth

One of arguments against masonry in grid is that grids are 2D, but actually in graphic design grids were often 1D. I agree that most masonry use cases need simpler grids than general grid use cases, but that means we should make those grids easier to define for both grid and masonry. The more we looked into this, we realize there are 3 different layout modes that give you 2D arrangement of children. We recommended not just make masonry part of grid, but find ways of integrating what we already have better could we come up with a shorthand that sets grid-auto-flow and flex-direction, and promote that for layout direction in general? Then authors only need to learn one control for it.

The debate

All was laid out onto the table, it was only left what other members had to say.

oriol: Problem with Jen Simmons’s reasoning. She said the proposed masonry-direction property would be new syntax that doesn’t match grid-auto-flow property, but this property matches flex-direction property so instead of trying to be close to grid, tries to be close to flexbox. Closer to grid is a choice, could be consistent with different things.

astearns: One question I asked is, has anyone changed their mind on which proposal they support? I personally have. I thought that separate display property made a lot more sense, in terms of designing the feature and I was very daunted by the idea that we’d have to consider both grid and masonry for any new development in either seemed sticky to me but the TAG argument convinced me that we should do the work of integrating these things.

TabAtkins: Thanks for setting that up for me, because I’m going to refute the TAG argument! I think they’re wrong in this case. You can draw a lot of surface-level connections between Grid and Masonry, and Flexbox, and other hypothetical layouts but when you actually look at details of how they work, behaviors each one is capable of, they’re pretty distinct if you try to combine together, it would be an unholy mess of conflicting constraints — e.g. flexing in items of masonry or grid or you’d have a weird mish-mash of, “the 2D layout.

But if you call it a flex you get access to these properties, call it grid, access to these other properties concrete example, “pillar” example mentioned in webKit blog post, that wasn’t compatible with the base concepts in masonry and flex because it wants a shared block formatting context grid etc have different formatting contexts, can’t use floats.

lea: actually, the TAG argument was that layout seems to actually be a continuum, and syntax should accommodate that rather than forcing one of two extremes (current flex vs current grid).

The debate kept back and forth until there was an attempt to set a general north star to follow.

jyasskin: Wanted to emphasize a couple aspects of TAG review. It seems really nice to keep the property from Chrome proposal that you don’t have to learn both, can just learn to do masonry without learning all of Grid even if that’s in a unified system perhaps still define masonry shorthand, and have it set grid propertie

jensimmons: To create a simple masonry-style layout in Grid, you just need 3 lines of code (4 with a gap). It’s quite simple.

jyasskin: Most consensus part of TAG feedback was to share properties whenever possible. Not necessary to share the same ‘display’ values; could define different ‘display’ values but share the properties. One thing we didn’t like about unified proposal was grid-auto-flow in the unified proposal, where some values were ignored. Yeah, this is the usability point I’m pounding on

Another Split Decision

Despite all, it looked like nobody was giving away, and the debate seemed stuck once again:

astearns: I’m not hearing a way forward yet. At some point, one of the camps is going to have to concede in order to move this forward.

lea: What if we do a straw poll. Not to decide, but to figure out how far are we from consensus? +1 lea

The votes were cast and the results were… split.

florian: though we could still not reach consensus, I want to thank both sides for presenting clear arguments, densely packed, well delivered. I will go back to the presentations, and revisit some points, it really was informative to present the way it was.

That’s all folks, a split decision! There isn’t a preference for either of the two proposals and implementing something with such mixed opinions is something nobody would approve. After a little over five years of debate, I think this meeting is yet another good sign that a new proposal addressing the concerns of both sides should be considered, but that’s just a personal opinion. To me, masonry (or whatever name it may be) is an important step in CSS layout that may shape future layouts, it shouldn’t be rushed so until then, I am more than happy to wait for a proposal that satisfies both sides.

Further Reading

• Help us choose the final syntax for Masonry in CSS (Jen Simmons and Elika Etemad, with Brandon Stewart)
• Feedback needed: How should we define CSS masonry? (Rachel Andrew, Ian Kilpatrick and Tab Atkins-Bittner)
• Weighing in on CSS Masonry (Keith J. Grant)
• Masonry and good defaults (Rachel Andrew)
• Should masonry be part of CSS grid? (Ahmad Shadeed)

Relevant Issues

• Pinterest/Masonry style layout support #945
• Designer/developer feedback on masonry layout #10233
• Alternative masonry path forward #9041
• CSS Masonry Layout #1003
• Masonry Syntax Debate #11243

CSSWG Minutes Telecon (2024-12-04): Just Use Grid vs. Display: Masonry originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

I had the pleasure of hosting a recent Smashing Magazine workshop on product design, subbing for Vitaly Friedman who usually runs these things.

What? A front-ender interviewing really smart people about their processes for user research, documenting requirements, and scaling teams around usability? I was a product designer once upon a time and even though it’s been a long time since I’ve flexed that muscle, it was a hoot learning from the guests, which included: Chris Kolb, Kevin Hawkins, and Vicky Carmichael.

The videos are barred from embedding, so I’ll simply link ’em up directly to YouTube:

• Chris Kolb: All Users Are Stupid
• Kevin Hawkins: Scaling International User Research
• Vicky Carmichael: Design By Doing

I also moderated a follow-up discussion with Chris and Kevin following the presentations.

A few of my choice takeaways:

• Small teams have the luxury of being in greater, more intimate contact with customers. Vicky explained how their relatively small size (~11 employees) means that everyone interfaces with customers and that customer issues and requests are handled more immediately.
• Large teams have to be mindful of teams forming into individual silos. A silo mentality typically happens when teams scale up in size, resulting in less frequent communication and collaboration. Team dashboards help, as do artifacts from meetings in multiple formats, such as AI-flavored summaries, video recordings, and documented decisions.
• Customers may appear to be dumb, but what looks like dumbness is often what happens when humans are faced with a lack of time and context. Solving “dumb” user problems often means coming at the problem in the same bewildered context rather than simply assuming the customer “just doesn’t get it.”

Smashing Meets Product Design originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

In 2024, CSS has introduced a suite of features that significantly enhance web design capabilities, offering developers more control and flexibility.

The “CSS Wrapped 2024” initiative by Chrome DevRel highlights 17 notable additions across components, interactions, and developer experience.

Components Enhancements

• Field Sizing: The field-sizing property allows form elements like textarea, select, and input to automatically adjust their size based on content, eliminating the need for JavaScript workarounds.
• Animate to height: auto: With the interpolate-size property, developers can smoothly transition elements to intrinsic sizes such as height: auto, min-content, and max-content, enabling more dynamic layouts.
• Exclusive
  : Enhancements to the

  element now support exclusive behavior, allowing only one disclosure to be open at a time, which is particularly useful for accordion interfaces.
• Styleable
  : Developers can now apply custom styles to the

  and

  elements, providing greater design flexibility.
• Anchor Positioning: The new anchor positioning feature enables precise placement of elements relative to anchors, facilitating complex overlay designs.

Interaction Improvements

• Custom Scrollbars: CSS now allows for the styling of scrollbars, enabling designs that align with the overall aesthetic of the website.
• Cross-Document View Transitions: This feature facilitates seamless transitions between different documents, enhancing user experience during navigation.
• Scroll-Driven Animations: Developers can create animations that respond to scroll events, adding interactivity and engagement to web pages.
• Scroll Snap Events: New events provide better control over scroll snapping behavior, improving the precision of scroll interactions.

Developer Experience Enhancements

• Backdrop Inheritance: This feature allows elements to inherit backdrop styles, ensuring consistent theming across components.
• light-dark() Function: The light-dark() function enables responsive design adjustments based on the user’s theme preference, enhancing accessibility.
• @property: This at-rule allows for the definition of custom properties with specific syntax and inheritance rules, improving CSS variable management.
• Popover API: The Popover API provides a standardized way to create and manage popover elements, streamlining the development of interactive components.
• @starting-style: This at-rule defines the initial styles of an element before any animations, ensuring consistent animation behavior.
• ruby-align: Enhancements to the ruby-align property improve the rendering of East Asian typography, supporting better internationalization.
• paint-order: The paint-order property allows developers to control the painting order of fill, stroke, and markers, providing finer control over SVG rendering.
• CSSOM Nested Declarations: Support for nested declarations in the CSS Object Model (CSSOM) simplifies the manipulation of nested styles via JavaScript.

These advancements reflect the collaborative efforts of browser engineers, specification writers, and the developer community, marking a significant leap forward for CSS in 2024.

For a comprehensive overview and demos of these features, visit the CSS Wrapped 2024 page.