skip to main content

Posts tagged “web”, page 2

  1. 5G Will Definitely Make the Web Slower, Maybe
    filamentgroup.com

    Scott Jehl:

    Faster networks should fix our performance problems, but so far, they have had an interesting if unintentional impact on the web. This is because historically, faster network speed has enabled developers to deliver more code to users—in particular, more JavaScript code.

    Ugh. Jeremy Keith comments:

    The longer I spend in this field, the more convinced I am that web performance is not a technical problem; it’s a people problem.

  2. The Myth of the Pixel Perfect Grid
    shkspr.mobi

    Terence Eden explains how different screen technologies, human biology, and fingerprint grease make “pixel perfection” a pointless goal:

    There is no grid. There never has been. You can align to theoretical pixels - but as soon as the image hits a physical screen, it will be adjusted to best fit reality.

    An obsession with pixel perfect rendering is futile.

    Every Layout expands on this idea, specifically as it pertains to CSS:

    Suffice it to say that, while screens are indeed made up of pixels, pixels are not regular, immutable, or constant. A 400px box viewed by a user browsing zoomed in is simply not 400px in CSS pixels. It may not have been 400px in device pixels even before they activated zoom.

    See also: Ian Mallett’s Subpixel Zoo: A Catalog of Subpixel Geometry.

  3. Styling Links with Real Underlines
    css-tricks.com

    Ollie Williams welcomes the new CSS properties for styling underlines:

    Finally we can demarcate links without sacrificing style thanks to two new CSS properties.

    • text-underline-offset controls the position of the underline.
    • text-decoration-thickness controls the thickness of underlines, as well as overlines, and line-throughs.

    I’ve been working on a blog post about this topic, and Ollie does a good job of covering some of the points I want to make. But I want to go further and explore implementation quirks, the details where the new properties don’t quite go far enough, and make a case for why underlines shouldn’t be pixel-aligned.

  4. Introducing caniemail.com
    caniemail.com

    Rémi Parmentier:

    Last march, I wrote a proposal for Can I email, a website similar to caniuse.com dedicated to support in email clients.

    Today, barely six months after, I am really happy and pleased to announce that with the help of my colleagues and members of the email geeks community, we’re officially launching caniemail.com.

    Wow, this was sorely needed.

  5. Less Data Doesn’t Mean a Lesser Experience
    timkadlec.com

    Tim Kadlec explores strategies for dealing with the Save-Data header without degrading the experience, because not every user that enables it will be aware of the potential consequences:

    The possibilities are endless. If you treat data as a constraint in your design and development process, you’ll likely be able to brainstorm a large number of different ways to keep data usage to a minimum while still providing an excellent experience. Doing less doesn’t mean it has to feel broken.

  6. What I Like About Eleventy
    daverupert.com

    Dave Rupert is, like me, a longtime Jekyll user. He’s trying out Eleventy — which I’m super curious about — and getting good results. The massive performance difference when compared to Jekyll is very compelling to me, but so is the flexibility to write little bits of code to extend functionality without much fuss:

    On the Cathedral vs. Bazaar spectrum, Eleventy operates more on the bazaar end. By that I mean it doesn’t prescribe much. You want a bunch of filters? Write your own, Eleventy only comes with two. You want multiple layouts? Write a bit of JS to get those registered. Did you remember to setup an .eleventyignore? Even the Sass and JS pipelines are BYO.

  7. IndieWeb Link Sharing
    mxb.dev

    Max Böck:

    Posting a new short “note” on my site currently requires me to commit a new markdown file to the repository on Github. That’s doable (for a developer), but not really convenient, especially when you’re on the go and just want to share a quick link.

    It me.

    The new link sharing basically has three main parts:

    • a small Javascript bookmarklet to act as a “share button”
    • a form that collects and sends the shared link data, and
    • a serverless function to process it and create a new file.

    Gotta get on this train! I’m already working on it, though my solution will be based on the Micropub spec. But that live preview is sweet and now I want it too.

  8. Ooops, I guess we’re full-stack developers now.
    full-stack.netlify.com

    Chris Coyier’s latest talk puts all the complexity of modern front-end development in perspective:

    All the very huge responsibilities front-end developers already have:

    • Pulling of the design
    • Making the design part of a system
    • Making sure it is accessible
    • Worrying about the performance
    • Testing things across browsers
    • Testing things across devices
    • Sweating the UX

    Oh hello, big pile of new responsibilities

    • Component-driven design, designing our own abstractions
    • Site-level architecture
    • Routing
    • Fetching our own data
    • Talking to APIs
    • Mutating data
    • State management

    Oof.

  9. The Real Dark Web
    sonniesedge.net

    Charlie Owen:

    The vast majority of respondents are still using Sass and vanilla CSS? Wow! This made me pause and think. Because I feel there’s an analogy here between that unseen dark matter, and the huge crowd of web developers who are using such “boring” technology stacks.

    These developers are quietly building their sites and apps, day in, day out. But they are rendered invisible as they are not making use of the cutting-edge technologies that the 1% of the bleeding edge love to talk about.

    They are the 99% of the web universe that is quietly getting on, not blogging about their technology stack, not publishing amazing new tooling. Simply building things.

    Sass and not much else? It me. Though I am using some state-of-the-art tech like the fancy underlines made possible by CSS Text Decoration Module Level 4 😎

  10. Intrinsically Responsive CSS Grid with minmax() and min()
    evanminto.com

    Evan Minto:

    min() accepts one or more values and returns the smallest value. The magic of the function is that, just like calc(), the arguments can use different units, which allows us to return values that change dynamically based on context.

    min() is one of three new comparison functions introduced as part of the CSS Values and Units Module Level 4. There’s also max(), which naturally does the inverse of min(). Finally clamp() is a convenience function that applies both a minimum and a maximum to a single value.

    This is brilliant and I can’t wait until I can change my @supports queries from display: grid to min().

  11. What I Like About Vue
    daverupert.com

    Dave Rupert:

    Upgrading legacy applications was one of the usecases Vue was designed around. It means that developers can piecemeal upgrade bits of an application as necessary.

    In my experience Angular, React, and a lot of other frameworks ultimately require you to go all in early and establish a large toolchain around these frameworks. Angular prescribes a lot with its amazing CLI. React on the other hand doesn’t prescribe anything, but requires you to self-assemble and wield a somewhat complex toolchain. But as Evan put it in his JSConf Asia talk, Vue sits in the middle of the “Cathedral and the Bazaar”. Vue has useful tooling, but it’s all optional and you can use only what you need. In some ways, Vue’s grafting capabilities really does make it seem like a jQuery replacement you can drop in to give your components superpowers as needed.

  12. How to Kill IE11 - What the Deaths of IE6 and IE8 Tell Us About Killing IE
    mike.sherov.com

    Mike Sherov:

    In order to understand how best to kill IE11, we need to look back to how 2 previous versions of IE met their fate: IE6 and IE8. By examining the strategies employed to kill browsers, we can look at current efforts to sunset IE11. We can predict and evangelize for what may ultimately do it in, finally freeing the JS community from the burden of ES5.

    Interesting historical analysis but I think that attempting to “kill” browsers is a misguided goal. I think the right way to move forward here is Oliver Williams’ idea of applying the “mustard cut” technique to all versions of Internet Explorer and serving those users just barebones (but useful) HTML and CSS.