Tag: Browser

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.


, ,

Weekly Platform News: CSS font-style: oblique, webhin browser extension, CSS Modules V1

In this week’s roundup, variable fonts get oblique, a new browser extension for linting, and the very first version of CSS Modules.

Use font-style: oblique on variable fonts

Some popular variable fonts have a 'wght' (weight) axis for displaying text at different font weights and a 'slnt' (slant) axis for displaying slanted text. This enables creating many font styles using a single variable font file (e.g., see the “Variable Web Typography” demo page).

You can use font-style: oblique instead of the lower-level font-variation-settings property to display slanted text in variable fonts that have a 'slnt' axis. This approach works in Chrome, Safari, and Firefox.

/* BEFORE */ h2 {   font-variation-settings: "wght" 500, "slnt" 4; }  /* AFTER */ h2 {   font-weight: 500;   font-style: oblique 4deg; }

See the Pen
Using font-style: oblique on variable fonts
by Šime Vidas (@simevidas)
on CodePen.

The new webhint browser extension

The webhint linting tool is now available as a browser devtools extension for Chrome, Edge, and Firefox (read Microsoft’s announcement). Compared to Lighthouse, one distinguishing feature of webhint are its cross-browser compatibility hints.

In other news…

  • CSS Modules V1 is a new proposal from Microsoft that would extend the JavaScript modules infrastructure to allow importing a CSSStyleSheet object from a CSS file (e.g., import styles from "styles.css";) (via Thomas Steiner)
  • Web apps installed in the desktop version of Chrome can be uninstalled on the about:apps page (right-click on an app’s icon to reveal the Remove... option) (via Techdows)
  • Because of AMP’s unique requirements, larger news sites such as The Guardian should optimally have two separate codebases (one for the AMP pages and one for the regular website) (via The Guardian)

Read more news in my new, weekly Sunday issue. Visit webplatform.news for more information.

The post Weekly Platform News: CSS font-style: oblique, webhin browser extension, CSS Modules V1 appeared first on CSS-Tricks.


, , , , , , , ,

Don’t comma-separate :focus-within if you need deep browser support

I really like :focus-within. It’s a super useful selector that allows you to essentially select a parent element when any of its children are in focus.

Say you wanted to reveal some extra stuff when a <div> is hovered…

div:hover {   .extra-stuff {      /* reveal it */   } }

That’s not particularly keyboard-friendly. But if something in .extra-stuff is tab-able anyway (meaning it can be focused), that means you could write it like this to make it a bit more accessible:

div:hover, div:focus-within {   .extra-stuff {      /* reveal it */   } }

That’s nice, but it causes a tricky problem.

Browsers ignore entire selectors if it doesn’t understand any part of them. So, if you’re dealing with a browser that doesn’t support :focus-within then it would ignore the CSS example above, meaning you’ve also lost the :hover state.


div:hover {   .extra-stuff {      /* reveal it */   } } div:focus-within {   .extra-stuff {      /* reveal it */   } }

That is safer. But it’s repetitive. If you have a preprocessor like Sass…

@mixin reveal {   .extra-stuff {      transform: translateY(0);   } } div:hover {   @include reveal; } div:focus-within {   @include reveal; }

See the Pen
Mixing for :focus-within without comma-separating
by Chris Coyier (@chriscoyier)
on CodePen.

I’d say it’s a pretty good use-case for having native CSS mixins.

The post Don’t comma-separate :focus-within if you need deep browser support appeared first on CSS-Tricks.


, , , , , ,

The Browser Can Remember Edited Content

You can make the text inside any HTML element editable by adding the contenteditable attribute.

<div contenteditable>   Hey, I'm like a textarea kinda now! </div>

I wouldn’t say there are wheelbarrows full of use-cases for that, but it’s neat. One possible use might be an in-progress design in which editing the content from the design itself is useful either for you, or for someone else (a client?) who needs to change the text.

So, great, contenteditable. Now someone can click into the text and edit it.

There is nothing permanent about those changes. Refresh the page, look in another browser or whatever. Those edits are gone.

Say you wanted to do a little better job and make the changes persistent. You aren’t trying to build a CMS here, or save the data through an authenticated connection to a database or anything. You just wanna make the edits to the text are maintained if the page refreshes.

One way is to chuck the data from the text changes you make into localStorage.

  1. When text is edited (on blur of the element), save the data to localStorage using a namespace and the
    ID of the element as the key.
  2. When the page loads, look through localStorage and see if there are any keys that match elements on the page and, if so, replace the content.
const editables = document.querySelectorAll("[contenteditable]");  // save edits editables.forEach(el => {   el.addEventListener("blur", () => {     localStorage.setItem("dataStorage-" + el.id, el.innerHTML);   }) });  // once on load for (var key in localStorage) {   if (key.includes("dataStorage-")) {     const id = key.replace("dataStorage-","");     document.querySelector("#" + id).innerHTML = localStorage.getItem(key);   } }

See the Pen
localStorage + contenteditable
by Chris Coyier (@chriscoyier)
on CodePen.

This reminds me of a few other things…

  • document.designMode = "on" is like a shortcut for making every element on the page behave like it has contenteditable.
  • Mavo is a little bit like this concept only with authentication, true data storage options, and editing UI.
  • If performance is a concern, KV storage is supposed to be a speeder async version of localStorage.

The post The Browser Can Remember Edited Content appeared first on CSS-Tricks.


, , ,

Browser Diversity Commentary, Regarding the Edge News

Still no word from the horse’s mouth about the reported EdgeHTML demise, but I hear that’s coming later today. The blog posts are starting to roll in about the possible impact of this though.

Andre Garzia: While we Blink, we loose the Web:

Even though Opera, Beaker and Brave are all doing very good work, it is still Chrome engine behind them and that limits the amount of stuff they can build and innovate. It is like as if they were building cars, there is a lot they can do without actually changing the engine itself, and thats what the Web Browsers are becoming, everyone is working on parts of the car but all the engines are now Chrome and believe me, you don’t want all the engines to be the same, not even if they are all Gecko or if somehow we resurrect Presto, we want diversity of engines and not monoculture.

Tim Kadlec, Risking a Homogeneous Web:

I can understand the logic. Microsoft can’t put as many folks on Edge (including EdgeHTML for rendering and Chakra for JavaScript) as Google has done with Chromium (using Blink for rendering and V8 for JavaScript), so keeping up was always going to be a challenge. Now they can contribute to the same codebase and try to focus on the user-focused features. Whether this gets people to pay more attention to their next browser or not remains to be seen, but I get the thinking behind the move.

The big concern here is we’ve lost another voice from an engine perspective.

Ferdy Christant, The State of Web Browsers:

Edge is doomed. It was doomed and its next version will be equally doomed from the start. For the simple reason that Microsoft has close to no say in how browsers get installed: on mobile as a default app, and on desktop via web services under the control of Google. Switching to Chromium makes no difference in market share, as the only way to compete now is through the browser’s UI, not via the engine. Which isn’t a competition at all, since browser UI is a commodity.

I’ll link up the official statements as they come out.

The post Browser Diversity Commentary, Regarding the Edge News appeared first on CSS-Tricks.


, , , , ,