Tag: Browser

What is the Value of Browser Diversity?

In 2018, Rachel Nabors made the point that browser diversity is similar to biological ecosystem diversity. There are literal advantages to more diversity. That article was before the Edge engines were shut, and now the big shakeups at Mozilla have the topic of browser diversity on people’s minds again.

I really like Dave’s take on the matter. The diversity of browser engines makes web tech slow. Frustratingly slow, to many, but that slowness can bring value.

There’s a lot of value in slow thinking. You use the non-lizard side of your brain. You make more deliberate decisions. You prioritize design over instant gratification. You can check your gut instincts and validate your hypothesis before incurring mountains of technical debt.

I’d bet you a dollar that the less engines we have, the faster things get. Fast can be satisfying in the moment, but doesn’t make for the best brisket.

If we do see a major reduction in browser diversity, I think we lose the intentional slowness and the cooperation mechanisms we have in place. Who knows what will happen, but my hope is that just like iron can sharpen iron, maybe chromium can sharpen chromium.

Direct Link to ArticlePermalink

The post What is the Value of Browser Diversity? appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, ,

Can you get valid CSS property values from the browser?

I had someone write in with this very legit question. Lea just blogged about how you can get valid CSS properties themselves from the browser. That’s like this.

That gives you, for example, the fact that cursor is a thing. But then how do you know what valid values are for cursor? We know from documentation that there are values like auto, none, help, context-menu, pointer, progress, wait, and many more.

But where does that list come from? Well, there is a list right in the spec so that’s helpful. But that doesn’t guarantee the complete list of values that any given browser actually supports. There could be cursor: skull-and-crossbones and we wouldn’t even know!

We can test by applying it to an element and looking in DevTools:


But unless we launch a huge dictionary attack against that value, we don’t actually know what values it directly in-browser. Maybe Houdini will help somehow in browsers getting better at CSS introspection?

You can also use the CSS object to run tests like CSS.supports(property, value):


You’d think we could have like CSS.validValues("text-decoration-thickness") and get like ["<length>", "<percentage>", "auto", "from-font"] or the like, but alas, not a thing.

The post Can you get valid CSS property values from the browser? appeared first on CSS-Tricks.

You can support CSS-Tricks by being an MVP Supporter.


, , , ,

Improving Chromium’s browser compatibility in 2020

This is exactly what I love to hear from any browser vendor:

When it comes to browser compatibility, there are still too many missing features and edge-case bugs. But it doesn’t have to be this way. Things can and will get better, if browser vendors can understand what is causing the most pain, and take action to address the causes. In Chrome we’re doing our best to listen, and we’re doing our best to address what we’re hearing. We hope it helps, and we’re looking forward to a more compatible 2021.

I love the nod to that super clever div that looks different in every browser. This is a solid list from Stephen McGruer. My favorite:

Like Flexbox, CSS Grid is an important component of modern layout. Looking at the early survey results it seems like the story for CSS Grid support in Chromium is fairly good (we have our friends from Igalia to thank for that!). There is one clear exception – Chromium still doesn’t support subgrid.

Hopefully, it won’t be an exception for much longer. It’s still early days, but I’m excited to share that a team at Microsoft Edge are working on rearchitecting Chromium’s Grid support to use the new LayoutNG engine – and as part of this are intending to add subgrid support!

Not that anyone should relax, but I think right now is probably the best level of browser compatibility we’ve ever seen.

Direct Link to ArticlePermalink

The post Improving Chromium’s browser compatibility in 2020 appeared first on CSS-Tricks.


, , , ,

How I Put the Scroll Percentage in the Browser Title Bar

Some nice trickery from Knut Melvær.

Ultimately the trick boils down to figuring out how far you’ve scrolled on the page and changing the title to show it, like:

document.title = `$  {percent}% $  {post.title}`

Knut’s trick assumes React and installing an additional library. I’m sure that library does all kinds of smart stuff, but if you’re looking to do this “vanilla” style, I’d probably rock something like this…

const percentLabel = document.querySelector("#percent"); const originalTitle = document.title;  window.addEventListener("scroll", () => {   let scrollTop = window.scrollY;   let docHeight = document.body.offsetHeight;   let winHeight = window.innerHeight;   let scrollPercent = scrollTop / (docHeight - winHeight);   let scrollPercentRounded = Math.round(scrollPercent * 100);   percentLabel.innerHTML = scrollPercentRounded;   document.title = `($  {scrollPercentRounded}%) $  {originalTitle}`; });

Here’s a project, and here’s the deployed site so you can see it in action.

Direct Link to ArticlePermalink

The post How I Put the Scroll Percentage in the Browser Title Bar appeared first on CSS-Tricks.


, , ,

A Guide to Handling Browser Events

In this post, Sarah Chima walks us through how we can work with browser events, such as clicking, using JavaScript. There’s a ton of great info in here! If JavaScript isn’t your strong suit, I think this is the best explanation of event handling that I’ve read in quite some time.

When an event occurs, the browser creates an event object and passes it as an argument to the event handler. This event object contains details of the event. For instance, you might want to know which button was clicked or which key was pressed or the mouse coordinates when the event occurred. You can get all of these from the event object.

Sarah also links to this really good primer on bubbling and capturing that’s worth checking out, too.

Direct Link to ArticlePermalink

The post A Guide to Handling Browser Events appeared first on CSS-Tricks.


, , ,

Browser Version Release Spectrum

Whenever a browser upgrades versions, it’s a little marketing event, and rightly so. Looks like for Firefox it’s about once a month, Chrome is ~6 weeks, and Safari is once a year.

Chrome 80 just dropped, as they say, and we get a video and blog post. What strikes me about releases like this these days is that there isn’t big flagship features that we’re all collectively interested in as developers. Maybe a little great divide stuff going on, but more broadly, just different front-end developers (the people who care about browsers) work on different things and so care about different things.

Let me try to illustrate that with a feature rundown of this release:

  • Content Indexing is a way to access metadata of files your browser has cached (that you specifically cached). Seems like a great idea, but I’ve never really dealt with offline stuff like this seriously so it’s not really in my wheelhouse.
  • Web Workers can use ES modules now. That’s cool, I didn’t even know they couldn’t.
  • Optional chaining in JavaScript, like obj?.name?.first. Love it. Super useful. Probably the feature that most JavaScript developers are applauding. But Chrome is first out of the gate here, so if you’re into it, you’d better be Babel-ing. We also get ?? .
  • Origin Trials are like feature flags I guess, except you opt-in from a website and not just on your local browser. Totally new to me, but sounds like they have been effective in gathering and refining new APIs.
  • Periodic background sync. Jeremy laid out how useful this in his article where he called it “silent push”. You can also schedule notifications, making them more resilient to offline situations.
  • HTTP content tries to auto-upgrade to HTTPS if the site is HTTPS. Great idea. I use the Cloudflare setting for this, but makes sense it moves to the browser level.
  • JavaScript can gzip streams. I understand what gzip is, but feel like this is over my head. There is a bunch of other stuff totally outside my wheelhouse too, like Decoding Encrypted Media and others.
  • Contact Picker API. Very much like this, in the same way I like the Web Payments API. If I can build a UI that helps users fill out forms faster and more accurately, that’s great. That’s why I use 1Password. I use it just as much for filling out address and credit card forms as I do for passwords.
  • SameSite cookies. Scares me. I know that we need to update our cookies on CodePen to make sure it has this value but I haven’t researched it deep enough yet, and 80 is already shipping.
  • Actual CSS stuff! line-break: anywhere; and overflow-wrap: anywhere; I can’t seem to grok the difference. This stuff is already very complicated.
  • Nothing HTML related. Poor HTML never gets nuthin’.

And then the two that really caught my eye!

  • SVG favicons. Awesome. We already ship one for CodePen because it looks so nice on Safari. Although Safari supports it with <link rel="mask-icon" href="..."> and Chrome is supporting it with <link rel="icon" href="..."> so I’m not quite sure what to do there. I guess since Firefox supports SVG with rel="icon", just ship SVG for both?
  • Text fragments. How cool. I had no idea this was coming. People have been talking about this for at least a decade. The idea is linking to things on a page without needing a name or id to link down to, just using text. The syntax is funky:
https://site.com/#:~:text=Links to first occurance of this text.

Here’s a video from Stefan Judis:

Especially notable to me: it links you to the middle of the page, not headbutting the top. I much prefer this.

The post Browser Version Release Spectrum appeared first on CSS-Tricks.


, , ,

“Browser Functions”

Serverless functions are fairly straightforward. Put a bit of back-end language code, like Node, in the cloud and communicate with it via URL. But what if that URL didn’t run a back-end language, it ran an actual browser? Richard Young:

We can now do full stack development using just Web APIs. Need to read/write network resources? Use the fetch API. Need to cache some data? Use localStorage. Need to blur an image? Use a CSS filter on an img tag. Need to manage sessions? Use cookies. Need multi-threading? Use Web Workers. Need native compiled speed (or a language other than JavaScript)? Use WebAssembly.

Clever. Browsers are getting so capable it makes sense to leverage the things they are good at.

Direct Link to ArticlePermalink

The post “Browser Functions” appeared first on CSS-Tricks.



Things you can do with a browser in 2020

I edit a good amount of technical articles about the web, and there is a tendency for authors to be super broad in their opening sentence, like “What we’re able to do on the web has expanded greatly over the years.”

I tend to remove stuff like that because it usually doesn’t serve the article well, even though I understand the sentiment.

Just look at Luigi De Rosa’s list here. I’d bet a lot of you didn’t know the browser could do all that stuff — push notifications! Native sharing menus! Picture-in-picture!

It’s mostly JavaScript stuff, a little CSS, and notably absent: anything in HTML.

Direct Link to ArticlePermalink

The post Things you can do with a browser in 2020 appeared first on CSS-Tricks.


, ,

Weekly Platform News: Upgrading Navigations to HTTPS, Sale of .org Domains, New Browser Engine

In this week’s roundup: DuckDuckGo gets smarter encryption, a fight over the sale of dot org domains, and a new browser engine is in the works.

Let’s get into the news!

DuckDuckGo upgrades and open-sources its encryption

DuckDuckGo has open-sourced its “Smarter Encryption” technology that enables upgrading from HTTP to HTTPS, and Pinterest (a popular social network) is already using it for outbound traffic — when people navigate from Pinterest to other websites — with great results: Their outbound HTTPS traffic increased from 60% to 80%.

DuckDuckGo uses its crawler to automatically generate and maintain a huge list of websites that support HTTPS, approximately 12 million entries. For comparison, Chromium’s HSTS Preload List contains only about 85 thousand entries.

(via DuckDuckGo)

Nonprofits oppose the sale of the .org domain

A coalition of organizations consisting of EFF, Wikimedia, and many others, are urging the Internet Society to stop the sale of the nonprofit organization that operates the .org domain to an investment firm.

Non-governmental organizations (NGOs) all over the world rely on the .org top-level domain. […] We cannot afford to put them into the hands of a private equity firm that has not earned the trust of the NGO community.

In a separate blog post, Mark Surman (CEO of Mozilla Foundation) urges the Internet Society to “step back and provide public answers to questions of interest to the public and the millions of organizations that have made dot org their home online for the last 15 years.”

(via Elliot Harmon)

A new browser engine is in development

Ekioh (a company from Cambridge, U.K.) is developing an entirely new browser engine for their Flow browser, which also includes Mozilla’s SpiderMonkey as its JavaScript engine. The browser can already run web apps such as Gmail (mostly), and the company plans to release it on desktop soon.

(via Flow Browser)

More news…

Read more news in my weekly newsletter for web developers. Pledge as little as $ 2 per month to get the latest news from me via email every Monday.

More News →


, , , , , , , , , ,

Browser Engine Diversity

We lost Opera when they went Chrome in 2013. Same deal with Edge when it also went Chrome earlier this year. Mike Taylor called these changes a “Decreasingly Diverse Browser Engine World” in a talk I’d like to see.

So all we’ve got left is Chrome-stuff, Firefox-stuff, and Safari-stuff. Chrome and Safari share the same lineage but have diverged enough, evolve separately enough, and are walled away from each other enough that it makes sense to think of them as different from one another.

I know there are fancier words to articulate this. For example, browser engines themselves have names that are distinct and separate from the names of the browsers.

Take Chrome, which is based on the open-source project Chromium, which uses the rendering engine Blink and the JavaScript engine V8.

Firefox uses Gecko as its browser engine, which is turning into Quantum, which has sub-parts like Servo for CSS and rendering.

Safari uses WebKit as a browser engine, which has parts like WebCore and JavaScriptCore.

It’s all kinda complicated and I’m not even sure I quite understand it all. My brain just thinks of it as everything under the umbrella of the main browser name.

The two extremes of looking at this from the perspective of decreasing diversity:

  • This is bad. Decreased diversity may hinder ecosystems from competing and innovating.
  • This is good. Cross-engine problems are a major productivity loss for the world. Getting down to one ecosystem would be even better.

Whichever it is, the ship has sailed. All we can do is look forward.

Random thoughts:

  • Perhaps diversity has just moved scope. Rather than the browser engines themselves representing diversity, maybe forks of the engnies we have left can compete against each other. Maybe starting from a strong foundation is a good place to start innovating?
  • If, god forbid, we got down to one browser engine, what happens to the web standards process? The fear would be that the last-engine-standing doesn’t have to worry about interop anymore and they run wild with implementations. But does running wild mean the playing field can never be competitive again?
  • It’s awesome when browsers compete on features that are great for users but don’t affect web standards. Great password managers, user protection features, clever bookmarking ideas, reader modes, clean integrations with payment APIs, free VPNs, etc. That was Opera’s play, and now we see many more in the same vein. Vivaldi is all about customization, Brave doubles down on privacy and security, and Puma is about monetization.

Brian Kardell wrote about some of this stuff recently in his “Beyond Browser Vendors” post. An interesting point is that the remaining browser engines are all open source. That means they can and do take outside contributions, which is exactly how CSS Grid came to exist.

Most of the work on CSS Grid in both WebKit and Chromium (Blink) was done, not by Google or Apple, but by teams at Igalia.

Think about that for a minute: The prioritization of its work was determined in 2 browsers not by a vendor, but by an investment from Bloomberg who had the foresight to fund this largely uncontroversial work.

And now, that idea continues:

This isn’t a unique story, it’s just a really important and highly visible one that’s fun to hold up. In fact, just in the last 6 months engineers as Igalia have worked on CSS Containment, ResizeObserver, BigInt, private fields and methods, responsive image preloading, CSS Text Level 3, bringing MathML to Chromium, normalizing SVG and MathML DOMs and a lot more.

What we may have lost in browser engine diversity we may gain back in the openness of browser engines and outside players stepping up.

The post Browser Engine Diversity appeared first on CSS-Tricks.


, ,