• Note - Posted on

    The reasonable man adapts himself to the world; the unreasonable man persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man.

    I learned about this quote by George Bernard Shaw from Veritasium’s video on The World’s Most Important Machine

    It instantly reminded me of the Kaun Hai Tu scene from Gully Boy, where Murad embodies Shaw’s “unreasonable man.” In this scene, Murad is confronted by his father after quitting his job to pursue his dream. The father tries to convince Murad that his dreams need to match his reality. Murad then answers that he will change his reality to match his dreams.

  • How to choose your Baseline target | Articles | web.dev

    Jeremy Wagner and Rachel Andrew explain how to use analytics to select a Baseline target and what to do when you don’t have any real user data.

    In cases where there isn’t any real user data:

    […] you can get a general idea of support for different Baseline targets through RUM Archive Insights, even allowing you to filter down to the country level.

    They also address a practical follow-up question: what to do about features that don’t meet your chosen Baseline target.

    Baseline doesn’t prescribe a specific path here, but the authors suggest a useful framework for categorizing features based on their “failure mode”:

    • Enhancement: If the feature is used in an unsupported browser, the experience is not broken. The experience could possibly be degraded, but may not likely be noticeable to the user. Example: loading="lazy".
    • Additive: The feature provides some additive benefits that may be noticeable—such as changes in page styling or some functionality. The difference may not be noticeable to users if the feature is unsupported, barring comparison in a browser that does support it. Example: Subgrid
    • Critical: If the feature is unsupported, the user will have a negative user experience—possibly even one that’s broken altogether. Example: File System Access API used as a central and necessary feature.

    They also highlight Clearleft’s browser support policy, where they target Baseline Widely available while still evaluating whether newer features can be used as progressive enhancements before ruling them out entirely.

  • Jason Pamental - The Life of <p> - YouTube

    I just saw Jason Pamental’s excellent talk on ‘The Life of <p>’. In this talk, Jason traces the evolution of paragraph design in print and shows how those typographic ideas can be applied using CSS.

    There’s one moment during the Q&A where Jason mentions:

    […] you see the page gets small, but they don’t change the scale of the headers. So you end up with like an <h1> with one word per line. It’s a really awkward break. So I think proportion with varying screen size is probably the most overlooked thing right now that I’d want to see people think about more.

    I wasn’t a web developer 10 years ago when Jason gave this talk, but with over five years of experience now, it’s striking that I only became aware of proportional type scaling as an idea in the last couple of years. Nowadays, I use utopia.fyi to create fluid type (and space) scales across viewport ranges, which helps address the problem Jason mentioned.

  • Browser support at Clearleft

    Underlying our browser support policy are two foundational principles:

    1. Website content and core functionality should be accessible to everyone.
    2. It’s okay for websites to look different in different browsers.

    If content is unreadable in some browsers, that’s a bug that we will fix.

    If content is displayed slightly differently in some browsers, we consider that to be a facet of the web, not a bug. This means that there will sometimes be subtle visual and functional differences from browser to browser. We deem this acceptable provided content and core functionality are unaffected.

  • Note - Posted on

    Earlier this month, I noted down Jason’s advice on how to get hired as a developer. I’d also like to add the following point from @brandon:

    use the product

    this is one of the first questions i ask in the interview anyways, ship and share something you’ve built on top of cloudflare. this alone will set you apart from most of the candidates, and it will show you are genuinely interested.

    This complements Jason’s advice well, because it turns “show your work” into something concrete and product-specific.

  • Note - Posted on

    Today I learned that on macOS, with the default scrollbar setting enabled, classic scrollbars are shown automatically when a mouse is connected. I used to believe that, mouse or not, users needed to explicitly change the scrollbar appearance to get the classic scrollbars.

    This is relevant for everyone who builds websites because when classic scrollbars are shown, the value of 100vw includes the scrollbar width. This can cause an unexpected horizontal overflow if the layout relies on 100vw for full-width elements. Additionally, they affect media queries, which assume scrollbars don’t exist when evaluating viewport width.

    Having said that, these aren’t new issues. Classic scrollbars are shown by default on Windows, where the same behaviours apply.

    Further reading:

  • The f*** off contact page - Nic Chan

    Instead of seeing us as people who brought valuable knowledge and expertise to the project, they saw us as the hands that would execute their vision.

    The above bit from Nic captures a dynamic I want to address upfront with clients, so they never treat me as just a pair of hands.

    Then there’s the this bit, which really resonated with me (because I’ve been there too and it sucks):

    While I personally believe in the value of good design, I also believe there are a lot of smoke-and-mirrors in the industry, and I hated the thought that I might have inadvertently contributed to it. Even if the client is happy, it didn’t meet my internal bar for a quality product worth sticking my name on, and I feel like I’ve let down both the client and the end-users.

    Nic mentions how they hope to avoid similar situations in the future by blogging:

    By blogging, I’m putting a body of work out there that communicates my values and ethos. While much of the details of my client work has to remain private, these posts can be public, and hopefully they can help me find people who resonate with what I have to offer. Or you know, just be bold enough to communicate ‘Fuck off’ to those who don’t!

  • Selector scoping in element.querySelector() and element.querySelectorAll()

    I was reading the MDN docs for element.querySelector() and learnt something totally unexpected about selector scope when this method is called on an element.

    Let’s say I have the following HTML:

    <div>
    	<p>This is a paragraph and it has a <span>span inside</span> it.</p>
    </div>
    
    <script>
    	const baseElement = document.querySelector('p');
    	// Note: We are querying relative to the <p> element, not the document
    	const matchedSpan = baseElement.querySelector('div span');
    	console.log(matchedSpan);
    </script>

    Once the above JavaScript is executed, what do you expect to happen?

    I expected it to log null to the console. My reasoning was simple: I am calling the method on baseElement (the <p> tag), and that paragraph clearly does not contain a <div> inside it.

    But here’s what actually gets logged to the console:

    <span>span inside</span>

    This surprisingly returns the <span> from inside the <p>.

    Why does this happen? MDN explains it like this:

    […] selectors is first applied to the whole document, not the baseElement, to generate an initial list of potential elements. The resulting elements are then examined to see if they are descendants of baseElement.

    Note: element.querySelectorAll() also applies selector scoping in the same manner.

    If we want to restrict the selector to the element on which it is called then we should use the :scope pseudo-class.

    const scopedQuery = baseElement.querySelector(':scope div span');
    console.log(scopedQuery); // Returns null, as expected

    As mentioned in the MDN docs for :scope, this works because:

    When used within a DOM API call — such as querySelector(), querySelectorAll(), matches(), or Element.closest():scope matches the element on which the method was called.

  • Note - Posted on

    I’m a web designer-developer who has mostly designed and built marketing websites for small to medium-sized businesses. I started designing because my clients didn’t have a designer and expected me to handle everything. But I’ve always felt like an imposter. It’s not a nice feeling.

    I’m really determined to change that, which is why I just bought Scott Riley’s course, Mindful Design. Piccalilli is running a Black Friday sale on all their courses, including Mindful Design, and I can wholeheartedly recommend them.

  • HTML and Typescript.

    Mandy Michael uses a brilliant analogy to explain why developers must get to know the HTML elements available to them and use the appropriate one for their content.

    In TypeScript, we have the concept of an any type. When you assign a type of any it means the content can be anything. […] But if everything is typed as any then you lose the benefits of the language.

    This is the same with HTML. If you use the <div> everywhere, you aren’t making the most of language. Because of this it’s important that you actively choose what the right element is and don’t just use the default <div>.

    This reminded me of the following quote by Jen Simmons from their HTML course:

    HTML syntax itself is fairly simple. The trickier part is knowing which tags to use when.

  • Safari drops support for the theme-color meta tag

    The <meta name="theme-color"> tag is no longer supported in Safari 26 on macOS and iOS.

    If a fixed or sticky element touches the top or bottom edge of the window, then and only then, Safari extends that element’s background color into the corresponding top or bottom bar. Otherwise, on iOS, the bars remain translucent and have no solid color background.

    As Wenson Hseih explained on WebKit Bugzilla:

    A solid background color extension (“top bar tint”) is only needed in cases where there’s a viewport-constrained (fixed or sticky) element near one of the edges of the viewport that borders an obscured content inset (such as the top toolbar on macOS, or compact tab bar on iOS), in order to avoid a gap above or below fixed elements in the page that would otherwise appear when scrolling. This color extension behaviour is more critical on iPhone, where there’s a much “softer” blur effect underneath the browser UI (and so more of the page underneath is otherwise directly visible).