Tags: rope

81

sparkline

Thursday, September 30th, 2021

Bruce Lawson’s personal site  : Set Safari free!

If Apple allowed Safari to actually compete, it would be better for web developers, businesses, consumers, and for the health of the web. Come on, Apple, set Safari free!

Tuesday, September 28th, 2021

iOS Browser Choice | CSS-Tricks

I have this expensive computer in my pocket and it feels unfair that it is hamstrung in this very specific way of not allowing other browser engines. I also have an Apple laptop and it’s not hamstrung in that way, and I really hope it never is.

Thursday, September 9th, 2021

Chrome is the new Safari. And so are Edge and Firefox. – Hello my name is Niels Leenheer

You may not realise that all browsers on iOS are required to use the same rendering engine as Safari. On other platforms, this is not the case.

A terrific in-depth look at the frustrating state of the web on iOS.

So it’s not just one browser that falls behind. It’s all browsers on iOS. The whole web on iOS falls behind. And iOS has become so important that the entire web platform is being held back as a result.

And this damning assessment is mercifully free of conspiracy theories.

The Safari and Chrome team both want to make the web safer and work hard to improve the web. But they do have different views on what the web should be.

Google is focussing on improving the web by making it more capable.

Safari seems to focus on improving the web as it currently is.

Read the whole thing—it’s excellent!

There can only be one proper solution: Apple needs to open up their App Store to browsers with other rendering engines. Scrap rule 2.5.6 and allow other browsers on iOS and let them genuinely compete. Even though Apple has been forced to compromise on some App Store rules, I have little hope for this to happen.

Tuesday, September 7th, 2021

Bruce Lawson’s personal site  : Briefing to the UK Competition and Markets Authority on Apple’s iOS browser monopoly and Progressive Web Apps

Following on from Stuart’s, here’s Bruce’s presentation to the CMA on Apple’s monopolistic practices and hostility to progressive web apps.

as days pass by — Talking to the Competition and Markets Authority about Apple

What I would like is that I can give users the best experience on the web, on the best mobile hardware. That best mobile hardware is Apple’s, but at the moment if I want to choose Apple hardware I have to choose a sub-par web experience. Nobody can fix this other than Apple, and there are a bunch of approaches that they could take — they could make Safari be a best-in-class experience for the web, or they could allow other people to collaborate on making the browser best-in-class, or they could stop blocking other browsers from their hardware. People have lots of opinions about which of these, or what else, could and should be done about this; I think pretty much everyone thinks that something should be done about it, though.

Friday, July 30th, 2021

Safari isn’t protecting the web, it’s killing it | HTTP Toolkit

I do want to recognize that the Safari/WebKit team are working hard, and I do desperately want them to succeed! Chromium’s domination is bad for everybody, and building a popular browser that’s focused on privacy & security, as they appear to be trying to do, is a fantastic goal. That does not mean their current approach deserves our blind support.

I’m sure the Safari team are working on the issues below already, and I think it’s likely that the problems fundamentally derive from management decisions about company priorities rather than the team themselves.

In the past (the early 2010s) Apple was frequently leading the way on new features, as the very first browser to ship major JavaScript APIs like Web Workers, and the browser driving experimental prefixed features like CSS Canvas backgrounds. It’s exceedingly rare now to see a web feature primarily driven by Apple. Something has changed.

Wednesday, July 7th, 2021

Back to the Bad Old Days of the Web – Jorge Arango

We’ve enjoyed a relatively long period when we didn’t have to think about which browser to use. Alas, that period is ending: I must now keep Chrome running all the time, much like I needed that PC in the early 2000s.

Monday, April 19th, 2021

Home · castastrophe/wc-theming-standards Wiki

I really like the idea of a shared convention for styling web components with custom properties—feels like BEM meets microformats.

Monday, March 29th, 2021

CSS { In Real Life } | Quick Tip: Style Pseudo-elements with Javascript Using Custom Properties

Oh, this is smart! You can’t target pseudo-elements in JavaScript, but you can use custom properties as a proxy instead.

Wednesday, March 17th, 2021

Fluid Space Calculator | Utopia

Type and space are linked, so if you’re going to have a fluid type calculator, it makes sense to have a fluid space calculator too. More great work from Trys and James!

Building Dark Mode | Product Blog • Sentry

Robin makes a good point here about using dark mode thinking as a way to uncover any assumptions you might have unwittingly baked into your design:

Given its recent popularity, you might believe dark mode is a fad. But from a design perspective, dark mode is exceptionally useful. That’s because a big part of design is about building relationships between colors. And so implementing dark mode essentially forced everyone on the team to think long, hard, and consistently about our front-end design components. In short, dark mode helped our design system not only look good, but make sense.

So even if you don’t actually implement dark mode, acting as though it’s there will give you a solid base to build in.

I did something similar with the back end of Huffduffer and The Session—from day one, I built them as though the interface would be available in multiple languages. I never implemented multi-language support, but just the awareness of it saved me from baking in any shortcuts or assumptions, and enforced a good model/view/controller separation.

For most front-end codebases, the design of your color system shows you where your radioactive styles are. It shows you how things are tied together, and what depends on what.

Saturday, December 12th, 2020

What Can You Put in a CSS Variable? / Coder’s Block

A reminder that the contens of custom properties don’t have to be valid property values:

From a syntax perspective, CSS variables are “extremely permissive”.

Thursday, September 24th, 2020

The failed promise of Web Components – Lea Verou

A spot-on summary of where we’ve ended up with web components.

Web Components had so much potential to empower HTML to do more, and make web development more accessible to non-programmers and easier for programmers.

But then…

Somewhere along the way, the space got flooded by JS frameworks aficionados, who revel in complex APIs, overengineered build processes and dependency graphs that look like the roots of a banyan tree.

Alas, that’s true. Lea wonders how this can be fixed:

I’m not sure if this is a design issue, or a documentation issue.

I worry that is a cultural issue.

Using a custom element from the directory often needs to be preceded by a ritual of npm flugelhorn, import clownshoes, build quux, all completely unapologetically because “here is my truckload of dependencies, yeah, what”.

Friday, July 24th, 2020

Custom Property Coverup | Amber’s Website

This is a great bit of detective work by Amber! It’s the puzzling case of The Browser Dev Tools and the Missing Computed Values from Custom Properties.

Who do I know working on dev tools for Chrome, Firefox, or Safari that can help Amber find an answer to this mystery?

Tuesday, July 7th, 2020

Custom properties

I made the website for the Clearleft podcast last week. The design is mostly lifted straight from the rest of the Clearleft website. The main difference is the masthead. If the browser window is wide enough, there’s a background image on the right hand side.

I mostly added that because I felt like the design was a bit imbalanced without something there. On the home page, it’s a picture of me. Kind of cheesy. But the image can be swapped out. On other pages, there are different photos. All it takes is a different class name on that masthead.

I thought about having the image be completely random (and I still might end up doing this). I’d need to use a bit of JavaScript to choose a class name at random from a list of possible values. Something like this:

var names = ['jeremy','katie','rich','helen','trys','chris'];
var name = names[Math.floor(Math.random() * names.length)];
document.querySelector('.masthead').classList.add(name);

(You could paste that into the dev tools console to see it in action on the podcast site.)

Then I read something completely unrelated. Cassie wrote a fantastic article on her site called Making lil’ me - part 1. In it, she describes how she made the mouse-triggered animation of her avatar in the footer of her home page.

It’s such a well-written technical article. She explains the logic of what she’s doing, and translates that logic into code. Then, after walking you through the native code, she shows how you could use the Greeksock library to achieve the same effect. That’s the way to do it! Instead of saying, “Here’s a library that will save you time—don’t worry about how it works!”, she’s saying “Here’s it works without a library; here’s how it works with a library; now you can make an informed choice about what to use.” It’s a very empowering approach.

Anyway, in the article, Cassie demonstrates how you can use custom properties as a bridge between JavaScript and CSS. JavaScript reads the mouse position and updates some custom properties accordingly. Those same custom properties are used in CSS for positioning. Voila! Now you’ve got the position of an element responding to mouse movements.

That’s what made me think of the code snippet I wrote above to update a class name from JavaScript. I automatically thought of updating a class name because, frankly, that’s how I’ve always done it. I’d say about 90% of the DOM scripting I’ve ever done involves toggling the presence of class values: accordions, fly-out menus, tool-tips, and other progressive disclosure patterns.

That’s fine. But really, I should try to avoid touching the DOM at all. It can have performance implications, possibly triggering unnecessary repaints and reflows.

Now with custom properties, there’s a direct line of communication between JavaScript and CSS. No need to use the HTML as a courier.

This made me realise that I need to be aware of automatically reaching for a solution just because that’s the way I’ve done something in the past. I should step back and think about the more efficient solutions that are possible now.

It also made me realise that “CSS variables” is a very limiting way of thinking about custom properties. The fact that they can be updated in real time—in CSS or JavaScript—makes them much more powerful than, say, Sass variables (which are more like constants).

But I too have been guilty of underselling them. I almost always refer to them as “CSS custom properties” …but a lot of their potential comes from the fact that they’re not confined to CSS. From now on, I’m going to try calling them custom properties, without any qualification.

Friday, July 3rd, 2020

Uncommon CSS Properties

I count at least three clever CSS techniques I didn’t know about.

Saturday, June 13th, 2020

CSS Custom Properties Fail Without Fallback · Matthias Ott – User Experience Designer

Matthias has a good solution for dealing with the behaviour of CSS custom properties I wrote about: first set your custom properties with the fallback and then use feature queries (@supports) to override those values.

Thursday, June 11th, 2020

CSS custom properties and the cascade

When I wrote about programming CSS to perform Sass colour functions I said this about the brilliant Lea Verou:

As so often happens when I’m reading something written by Lea—or seeing her give a talk—light bulbs started popping over my head (my usual response to Lea’s knowledge bombs is either “I didn’t know you could do that!” or “I never thought of doing that!”).

Well, it happened again. This time I was reading her post about hybrid positioning with CSS variables and max() . But the main topic of the post wasn’t the part that made go “Huh! I never knew that!”. Towards the end of her article she explained something about the way that browsers evaluate CSS custom properties:

The browser doesn’t know if your property value is valid until the variable is resolved, and by then it has already processed the cascade and has thrown away any potential fallbacks.

I’m used to being able to rely on the cascade. Let’s say I’m going to set a background colour on paragraphs:

p {
  background-color: red;
  background-color: color(display-p3 1 0 0);
}

First I’ve set a background colour using a good ol’ fashioned keyword, supported in browsers since day one. Then I declare the background colour using the new-fangled color() function which is supported in very few browsers. That’s okay though. I can confidently rely on the cascade to fall back to the earlier declaration. Paragraphs will still have a red background colour.

But if I store the background colour in a custom property, I can no longer rely on the cascade.

:root {
  --myvariable: color(display-p3 1 0 0);
}
p {
  background-color: red;
  background-color: var(--myvariable);
}

All I’ve done is swapped out the hard-coded color() value for a custom property but now the browser behaves differently. Instead of getting a red background colour, I get the browser default value. As Lea explains:

…it will make the property invalid at computed value time.

The spec says:

When this happens, the computed value of the property is either the property’s inherited value or its initial value depending on whether the property is inherited or not, respectively, as if the property’s value had been specified as the unset keyword.

So if a browser doesn’t understand the color() function, it’s as if I’ve said:

background-color: unset;

This took me by surprise. I’m so used to being able to rely on the cascade in CSS—it’s one of the most powerful and most useful features in this programming language. Could it be, I wondered, that the powers-that-be have violated the principle of least surprise in specifying this behaviour?

But a note in the spec explains further:

Note: The invalid at computed-value time concept exists because variables can’t “fail early” like other syntax errors can, so by the time the user agent realizes a property value is invalid, it’s already thrown away the other cascaded values.

Ah, right! So first of all browsers figure out the cascade and then they evaluate custom properties. If a custom property evaluates to gobbledygook, it’s too late to figure out what the cascade would’ve fallen back to.

Thinking about it, this makes total sense. Remember that CSS custom properties aren’t like Sass variables. They aren’t evaluated once and then set in stone. They’re more like let than const. They can be updated in real time. You can update them from JavaScript too. It’s entirely possible to update CSS custom properties rapidly in response to events like, say, the user scrolling or moving their mouse. If the browser had to recalculate the cascade every time a custom property didn’t evaluate correctly, I imagine it would be an enormous performance bottleneck.

So even though this behaviour surprised me at first, it makes sense on reflection.

I’ve probably done a terrible job explaining the behaviour here, so I’ve made a Codepen. Although that may also do an equally terrible job.

(Thanks to Amber for talking through this with me and encouraging me to blog about it. And thanks to Lea for expanding my mind. Again.)

Saturday, June 6th, 2020

Hybrid positioning with CSS variables and max() – Lea Verou

Yet another clever technique from Lea. But I’m also bookmarking this one because of something she points out about custom properties:

The browser doesn’t know if your property value is valid until the variable is resolved, and by then it has already processed the cascade and has thrown away any potential fallbacks.

That explains an issue I was seeing recently! I couldn’t understand why an older browser wasn’t getting the fallback I had declared earlier in the CSS. Turns out that custom properties mess with that expectation.

Monday, June 1st, 2020

Global and Component Style Settings with CSS Variables — Sara Soueidan

Sara shares how she programmes with custom properties in CSS. It sounds like her sensible approach aligns quite nicely with Andy’s CUBE CSS methodology.

Oh, and she’s using Fractal to organise her components:

I’ve been using Fractal for a couple of years now. I chose it over other pattern library tools because it fit my needs perfectly — I wanted a tool that was unopinionated and flexible enough to allow me to set up and structure my project the way I wanted to. Fractal fit the description perfectly because it is agnostic as to the way I develop or the tools I use.