370 stories
1 follower

Chrome was delivered without any sprints at all

1 Comment
Chrome was delivered without any sprints at all. The team came in at 9 and left at 5 (figuratively, people actually kept their own ~8h schedules) every workday for a couple years like clockwork. No drama. No broken marriages, no broken families.
It was one of the most formative experiences of my career.
I hear you asking, dear reader, how this miracle came to pass. How did chrome-team manage to deliver high quality software without death marches? Funny you ask... Turns out that software projects actually benefit strongly from having senior technical leadership deeply involved.
By "senior" I mean, as a crude approximation, "old enough to have school aged children at home". By "involved" I mean "typing code" and "reviewing code". I know! In our industry it has been more common for such folks to age out to management and leave the typing to the kids.
I mean even at Google (on a different team) I was a "technical lead" in my 20s, and let me tell you, I had noooo business leading anything technical of any importance. But this is very common!
We would never accept this in other fields. Would you live in a house built entirely by junior carpenters in their late 20s who built one or two houses that barely stood up? Would you drive cars designed and built by junior engineers?
Software engineering is engineering. Like other kinds of engineering, it's a skill you develop over a lifetime, not a decade. When I joined chrome-team I was in my early 30s. And I was on the junior side. Most of the core team had already worked on one or two browsers before!
Having strong technical leadership has lots of advantages, but one of them is it naturally leads to a healthier cadence. These folks typically have to be home for dinner, and they're old enough to know that death marches don't work.
I think a decade or so back, it was harder to staff teams with strong technical leadership, because the industry was growing so fast and was so young. But that's changing now! So if you're building a software project: don't cheat yourself, find experienced engineers to run it...
... and if you're on the younger side, also don't cheat yourself. Find you a team with experienced leaders to learn from.
Well this blew up. No SoundCloud but if you’re of the technically bent, I wrote a little bit more about Chrome’s dev process awhile back: https://aboodman.medium.com/in-march-2011-i-drafted-an-article-explaining-how-the-team-responsible-for-google-chrome-ships-c479ba623a1b Have a nice day!
Also: A few of us started a company building dev tools following the values we learned on Chrome. Replicache makes it easy to add multiplayer, real-time, and offline-first to existing apps. Learn more at http://replicache.dev. We’re in beta and will launch when it’s ready :)

Adblock test (Why?)

Read the whole story
1 day ago
Good words!
Share this story

Zooming Images in a Grid Layout

1 Comment and 2 Shares

Creating a grid of images is easy, thanks to CSS Grid. But making the grid do fancy things after the images have been placed can be tricky to pull off.

Say you want to add some fancy hover effect to the images where they grow and zoom beyond the rows and columns where they sit? We can do that!

Cool, right? If you check the code, you won’t find any JavaScript, complex selectors, or even magic numbers. And this is only one example among many we will explore!

Building the grid

The HTML code to create the grid is as simple as a list of images within a container. We don’t need more than that.

<div class="gallery">
  <!-- etc. -->

For the CSS, we first start by setting the grid using the following:

.gallery {
  --s: 150px; /* controls the size */
  --g: 10px;  /* controls the gap */

  display: grid;
  gap: var(--g);
  width: calc(3*var(--s) + 2*var(--g)); /* 3 times the size plus 2 times the gap */
  aspect-ratio: 1;
  grid-template-columns: repeat(3, auto);

In short, we have two variables, one that controls the size of the images and one that sets the size of the gap between images. aspect-ratio helps keep things in proportion.

You might be wondering why we are only defining three columns but no rows. No, I didn’t forget the rows — we just don’t need to explicitly set them. CSS Grid is capable of automatically placing items on implicit rows and columns, meaning we get as many rows as needed to any number of images we throw at it. We can explicitly define the rows instead but we need to add grid-auto-flow: column to make sure the browser will create the needed columns for us.

Here is an example to illustrate both cases. The difference is that one flows in a row direction an the other in a column direction.

Check out this other article I wrote for more about the implicit grids and the auto-placement algorithm.

Now that we have our grid, it’s time to style the images:

.gallery > img {
  width: 0;
  height: 0;
  min-height: 100%;
  min-width: 100%;
  object-fit: cover;

The hover effect we’re making relies on this CSS. It probably looks weird to you that we’re making images that have both no width or height but have a minimum width and height of 100%. But you will see that it’s a pretty neat trick for what we are trying to achieve.

What I’m doing here is telling the browser that the images need to have 0 width and height but also need to have a minimum height equal to 100%… but 100% of what? When using percentages, the value is relative to something else. In this case, our image is placed inside a grid cell and we need to know that size to know what’s 100% is relative to.

The browser will first ignore min-height: 100% to calculate the size of the grid cells, but it will use the height: 0 in its calculation. That means our images will not contribute to the size of the grid cells… because they technically have no physical size. This will result in three equal columns and rows that are based on the size of the grid (which we defined on the .gallery’s width and aspect-ratio). The height of each grid cell is nothing but the variable --s we defined (same for the width).

Now that we have the dimensions of our grid’s cells, the browser will use it with min-height: 100% (and min-width: 100%) which will force the images to completely fill the space of each grid cell. The whole thing may look a bit confusing but the main idea is to make sure that the grid defines the size of the images rather than the other way around. I don’t want the image to define the size of the grid and you will understand why after adding the hover effect.

Creating the hover effect

What we need to do is increase the scale of the images when they’re hovered. We can do that by adjusting an image’s width and height on :hover:

.gallery {
  --f: 1.5; /* controls the scale factor */

.gallery img:hover{
  width:  calc(var(--s) * var(--f));
  height: calc(var(--s) * var(--f));

I added a new custom variable, --f, to the mix as a scale factor to control the size on hover. Notice how I’m multiplying the size variable, --s, by it to calculate the new image size.

But you said that the image size needs to be 0. What is going on? I am lost…

What I said is still true but I am making an exception for the hovered image. I am telling the browser that only one image will have a size that’s not equal to zero — so it will contribute to the dimension of the grid — while all the others remain equal to 0.

The left side shows the grid in its natural state without any hovered images, which is what the right side is showing. All the grid cells on the left side are equal in size since all the images have no physical dimensions.

On the right side, the second image in the first row is hovered, which gives it dimensions that affect the grid cell’s size. The browser will make that specific grid cell bigger on hover, which contributes to the overall size. And since the size of the whole grid is set (because we set a fixed width on the .gallery), the other grid cells will logically respond by becoming smaller in order to keep the .gallery‘s overall size in tact.

That’s our zoom effect in action! By increasing the size of only one image we affect the whole grid configuration, and we said before that the grid defines the size of the images so that each image stretches inside its grid cell to fill all the space.

To this, we add a touch of transition and use object-fit to avoid image distortion and the illusion is perfect!

I know that the logic behind the trick is not easy to grasp. Don’t worry if you don’t fully understand it. The most important is to understand the structure of the code used and how to modify it to get more variations. That’s what we will do next!

Adding more images

We created a 3×3 grid to explain the main trick, but you have probably guessed that we there’d no need to stop there. We can make the number of columns and rows variables and add as many images as we want.

.gallery {
  --n: 3; /* number of rows*/
  --m: 4; /* number of columns */
  --s: 150px; /* control the size */
  --g: 10px;  /* control the gap */
  --f: 1.5;   /* control the scale factor */

  display: grid;
  gap: var(--g);
  width:  calc(var(--m)*var(--s) + (var(--m) - 1)*var(--g));
  height: calc(var(--n)*var(--s) + (var(--n) - 1)*var(--g));
  grid-template-columns: repeat(var(--m),auto);

We have two new variables for the number of rows and columns. Then we simply define the width and height of our grid using them. Same for grid-template-columns which uses the --m variable. And just like before, we don’t need to explicitly define the rows since the CSS Grid’s auto-placement feature will do the job for us no matter how many image elements we’re using.

Why not different values for the width and height? We can do that:

.gallery {
  --n: 3; /* number of rows*/
  --m: 4; /* number of columns */
  --h: 120px; /* control the height */
  --w: 150px; /* control the width */
  --g: 10px;  /* control the gap */
  --f: 1.5;   /* control the scale factor */

  display: grid;
  gap: var(--g);
  width:  calc(var(--m)*var(--w) + (var(--m) - 1)*var(--g));
  height: calc(var(--n)*var(--h) + (var(--n) - 1)*var(--g));
  grid-template-columns: repeat(var(--m),auto);

.gallery img:hover{
  width:  calc(var(--w)*var(--f));
  height: calc(var(--h)*var(--f));

We replace --s with two variables, one for the width, --w, and another one for the height, --h. Then we adjust everything else accordingly.

So, we started with a grid with a fixed size and number of elements, but then we made a new set of variables to get any configuration we want. All we have to do is to add as many images as we want and adjust the CSS variables accordingly. The combinations are limitless!

What about a full-screen version? Yes, that’s also possible. All we need is to know what values we need to assign to our variables. If we want N rows of images and we want our grid to be full screen, we first need to solve for a height of 100vh:

var(--n) * var(--h) + (var(--n) - 1) * var(--g) = 100vh

Same logic for the width, but using vw instead of vh:

var(--m) * var(--w) + (var(--m) - 1) * var(--g) = 100vw

We do the math to get:

--w: (100vw - (var(--m) - 1) * var(--g)) / var(--m)
--h: (100vh - (var(--n) - 1) * var(--g)) / var(--n)


It’s the same exact HTML but with some updated variables that change the grid’s sizing and behavior.

Note that I have omitted the formula we previously set on the .gallery‘s width and height and replaced them with 100vw and 100vh, respectively. The formula will give us the same result but since we know what value we want, we can ditch all that added complexity.

We can also simplify the --h and --w by removing the gap from the equation in favor of this:

--h: calc(100vh / var(--n)); /* Viewport height divided by number of rows */
--w: calc(100vw / var(--m)); /* Viewport width divided by number of columns */

This will make the hovered image grow a bit more than the previous example, but it is no big deal since we can control the scale with the --f variable we’re using as a multiplier.

And since the variables are used in one place we can still simplify the code by removing them altogether:

It’s important to note this optimization applies only to the full-screen example and not to the examples we’ve covered. This example is a particular case where we can make the code lighter by removing some of the complex calculation work we needed in the other examples.

We actually have everything we need to create the popular pattern of expanding panels:

Let’s dig even deeper

Did you notice that our scale factor can be less than 1? We can define the size of the hovered image to be smaller than --h or --w but the image gets bigger on hover.

The initial grid cell size is equal to --w and --h, so why do a smaller values make the grid cell bigger? Shouldn’t the cell get smaller, or at least maintain its initial size? And what is the final size of the grid cell?

We need to dig deeper into how the CSS Grid algorithm calculates the size of the grid cells. And this is involves understanding CSS Grid’s default stretch alignment.

Here’s an example to understand the logic.

On the left side of the demo, I defined a two-column with auto width. We get the intuitive result: two equal columns (and two equal grid cells). But the grid I set up on the right side of the demo, where I am updating the alignment using place-content: start, appears to have nothing.

DevTools helps show us what’s really happening in both cases:

In the second grid, we have two columns, but their widths equal zero, so we get two grid cells that are collapsed at the top-left corner of the grid container. This is not a bug but the logical result of the grid’s alignment. When we size a column (or row) with auto, it means that its content dictates its size — but we have an empty div with no content to make room for.

But since stretch is the default alignment and we have enough space inside our grid, the browser will stretch both grid cells equally to cover all that area. That’s how the grid on the left winds up with two equal columns.

From the specification:

Note that certain values of justify-content and align-content can cause the tracks to be spaced apart (space-around, space-between, space-evenly) or to be resized (stretch).

Note the “to be resized” which is the key here. In the last example, I used place-content which is the shorthand for justify-content and align-content

And this is buried somewhere in the Grid Sizing algorithm specs:

This step expands tracks that have an auto max track sizing function by dividing any remaining positive, definite free space equally amongst them. If the free space is indefinite, but the grid container has a definite min-width/height, use that size to calculate the free space for this step instead.

“Equally” explains why we wind up with equal grid cells, but it applies to “the free space” which is very important.

Let’s take the previous example and add content to one of the divs:

We added a square 50px image. Here’s an illustration of how each grid in our example responds to that image:

In the first case, we can see that the first cell (in red) is bigger than the second one (in blue). In the second case, the size of the first cell changes to fit the physical size of the image while the second cell remains with no dimensions. The free space is divided equally, but the first cell has more content inside which makes it bigger.

This is the math to figure out our free space:

(grid width) - (gap) - (image width) = (free space)
200px - 5px - 50px = 145px 

Divided by two — the number of columns — we get a width of 72.5px for each column. But we add the size of the image, 50px, to the first column which leaves us with one column at 122.5px and the second one equal to 72.5px.

The same logic applies to our grid of images. All the images have a size equal to 0 (no content) while the hovered image contributes to size — even if it’s just 1px — making its grid cell bigger than the others. For this reason, the scale factor can be any value bigger than 0 even decimals between 0 and 1.

To get the final width of the grid cells, we do the same calculation to get the following:

(container width) - (sum of all gaps) - (hovered image width) = (free space)

The width of container is defined by:

var(--m)*var(--w) + (var(--m) - 1)*var(--g)

…and all the gaps are equal to:

(var(--m) - 1)*var(--g)

…and for the hovered image we have:


We can calculate all of that with our variables:

var(--m)*var(--w) - var(--w)*var(--f) = var(--w)*(var(--m) - var(--f))

The number of columns is defined by --m ,so we divide that free space equally to get:

var(--w)*(var(--m) - var(--f))/var(--m)

…which gives us the size of the non-hovered images. For hovered images, we have this:

var(--w)*(var(--m) - var(--f))/var(--m) + var(--w)*var(--f)
var(--w)*((var(--m) - var(--f))/var(--m) + var(--f))

If we want to control the final size of the hovered image, we consider the above formula to get the exact size we want. If, for example, we want the image to be twice as big:

(var(--m) - var(--f))/var(--m) + var(--f) = 2

So, the value of our scale multiplier, --f, needs to be equal to:

var(--m)/(var(--m) - 1)

For three columns we will have 3/2 = 1.5 and that’s the scale factor I used in the first demo of this article because I wanted to make the image twice as big on hover!

The same logic applies to the height calculation and in case we want to control both of them independently we will need to consider two scale factors to make sure we have a specific width and height on hover.

.gallery {
  /* same as before */
   --fw: 1.5; /* controls the scale factor for the width */
   --fh: 1.2; /* controls the scale factor for the height */

  /* same as before */

.gallery img:hover{
  width:  calc(var(--w)*var(--fw));
  height: calc(var(--h)*var(--fh));

Now, you know all the secrets to create any kind of image grid with a cool hover effect while also having control of the sizing you want using the math we just covered.

Wrapping up

In my last article, we created a complex-looking grid with a few lines of CSS that put CSS Grid’s implicit grid and auto-placement features to use. In this article, we relied on some CSS Grid sizing trickery to create a fancy grid of images that zoom on hover and cause the grid to adjust accordingly. All of this with a simplified code that is easy to adjust using CSS variables!

In the next article, we will play with shapes! We will combine CSS grid with mask and clip-path to get fancy grid of images.

Zooming Images in a Grid Layout originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Read the whole story
7 days ago
This is an amazing effect!
Share this story

Toyota offers to buy back its recalled bZ4X electric SUVs

1 Comment
Photo by Abigail Bassett for The Verge

Toyota is offering to buy back its bZ4X electric SUV crossovers after recalling the vehicle in June, as first reported by Electrek. The recall, which Toyota issued not even two months after the bZ4X’s release, involves loose hub bolts on the steering wheel that could cause it to detach while driving.

Toyota initially advised bZ4X owners not to drive the vehicle, and suggested that they notify their local Toyota dealer so they can pick up and store the car while they wait on a fix. The company would then provide customers with a free loaner car in return.

But a letter to customers obtained by Electrek and confirmed by The Verge reveals that Toyota is also offering to throw in a few extra freebies in exchange for the inconvenience,...

Continue reading…

Read the whole story
9 days ago
Wow! This has to be costing a ton. Really annoying for those customers too.
Share this story

How I Added Scroll Snapping To My Twitter Timeline

1 Comment

CSS Scroll Snap allows websites to snap the web page or any other scroll container to a specific scroll position when the user performs a scrolling operation. This feature has been supported in all modern browsers for over two years, but many websites that could benefit from it are still not using it.

Scroll snapping is probably most associated with horizontal carousels (see Chris’s CSS-only approach) and particular web pages divided into full-screen slides. But why stop there? I believe that snapping can improve the scrolling experience on any web page that lays out items in a grid or feed.

For example, most shopping websites show products in a grid. Ideally, the user would like to jump between the grid rows with minimal effort. The user can press Space to scroll the page by roughly one screen (viewport height), but depending on the height of the grid rows, the scroll position will eventually get “out of sync” with the grid, and the user will have to re-adjust it manually.

If we add scroll snapping to this page, the user can consistently scroll to the next row with the Space key (pressing Shift + Space will scroll to the previous row). It’s pretty effortless.

I think that scroll snapping would be a welcome addition to this website. And it’s not even that complicated to implement. The CSS code that I used for this example is relatively simple:

html {
  scroll-snap-type: y proximity;

.product-item {
  scroll-snap-align: start;
  scroll-margin-top: 75px; /* height of web page’s sticky header */

You don’t have to wait if a website you visit regularly hasn’t yet added scroll snapping and you think it would improve your scrolling experience. You can add scroll snapping yourself — with user styles.

Adding user styles to websites

In the video above, you can see that I selected a user.css file in Safari’s advanced preferences. This file is a user style sheet. It contains CSS styles that I’ve written, stored in a local .css file, and added to Safari. These “user styles” are then applied to every web page I open in Safari.

Chrome and Firefox do not allow users to select a user style sheet. Firefox supported a similar feature called userContent.css in the past, but that feature was deprecated and disabled by default in 2019. I recommend the Stylus browser extension for these two browsers (and other Chromium-based browsers).

One significant advantage of Stylus is that it allows you to write user styles for specific websites and URLs. Safari’s user style sheet applies to all websites, but this can be worked around, e.g., by using the new :has() pseudo-class to create selectors that only match specific websites.

The Stylus extension has been reviewed by both Chrome and Firefox teams and received a badge that denotes high standards.

The CSS Cascading module defines a User Origin for styles the user adds. Safari’s user style sheet belongs to this origin, but the Stylus extension injects user styles to the Author Origin, where the website’s style sheets live. Specifically, Stylus inserts user styles directly to the page via a <style> element at the end of <html> which makes it the final style sheet on the page. Technically, this means styles added via Stylus are classified as author styles since they’re not in the User Origin, but I will continue to call them user styles because the user adds them.

However, it’s worth keeping this distinction in mind because it affects the cascade. When selector specificity is equal, a real user style is weaker than the page’s own style. This makes user styles an excellent fit for user defaults. Under the same conditions, a style added via Stylus is stronger than the page‘s style, so Stylus cannot as easily be used to define user defaults.

If we add !important to the mix, both real user styles and styles added via Stylus are stronger than the page’s styles. So when you want to impose your user styles on a website, it doesn’t matter if you use Safari’s “Style sheet” option or the Stylus extension. Your !important styles will win either way.

In the next section, I will use a set of !important user styles to enforce scroll snapping on the timeline page of Twitter’s website. My goal is to speed up the process of reading my Twitter timeline by avoiding awkward scroll positions where the topmost tweet is only partially on screen.

Scroll snap for Twitter’s timeline

After some experimentation, I’ve settled on the following CSS code. These styles work well in Firefox, but I’ve experienced some issues in Chrome and Safari. I will describe these issues in more detail later in the article, but for now, let’s focus on the behavior in Firefox.

html {
  scroll-snap-type: y mandatory !important;

/* tweets in the timeline are <article> elements */
article {
  scroll-snap-align: start !important;

/* un-stick the sticky header and make it “snappable” as well */
[aria-label="Home timeline"] > :first-child {
  position: static !important;
  scroll-snap-align: start !important;

/* hide the “new Tweets available” floating toast notification */
[aria-label="New Tweets are available."] {
  display: none !important;

It is necessary to add !important to each declaration because all the user styles must win over the web page’s own styles for our custom scroll snapping implementation to work correctly. I wish that instead of repeatedly writing !important, I could just put my user styles in an “important layer,” but such a CSS feature does not exist (yet).

Watch the video below to see my scroll snap user styles in action. Notice how each press on the Space key scrolls the next set of tweets into view, and the first tweet of each set is aligned to the top edge of the viewport. This allows me to read my timeline more quickly. When I need to go back to the previous set of tweets, I can press Shift + Space.

What I like about this type of scroll snapping is that it allows me to predict how far the page will scroll whenever I press Space. Each scroll distance equals the combined heights of the visible tweets that are entirely on the screen. In other words, the partially visible tweet at the bottom of the screen will move to the top of the screen, which is precisely what I want.

I know in advance that pressing Space will scroll Dave’s tweet to the top of the screen.

To try out my scroll snap user styles on your own Twitter timeline, follow these steps:

  1. Install the Stylus extension with Firefox Add-ons or the Chrome Web Store.
  2. Navigate to your Twitter timeline at https://twitter.com/home.
  3. Click the Stylus icon in the browser’s toolbar and click “this URL” in the pop-up.
  4. Stylus will open a code editor in a new browser tab. Copy-paste my scroll snap user styles into the editor and press the Save button in the sidebar on the left. The styles will be applied to your Twitter timeline immediately (no need to reload the page).
  5. You can update the styles at any time. Click the Stylus icon and the Pencil icon to open the editor again.

Inability to override snapping

My implementation of scroll snapping for Twitter’s timeline has one major flaw. If a tweet is taller than the viewport, it is impossible to scroll the page to reveal the bottom part of that tweet (e.g., if you want to like or retweet that tweet) because the browser forcefully snaps the page to show the top of the tweet (or the top of the following tweet).

The severity of this problem depends on the user’s display. Viewing Twitter’s timeline on a large desktop monitor at a small page zoom factor, you may not encounter any tweets taller than the viewport.

I have asked the CSS Working Group if it would be possible to add a mechanism allowing the user to override the browser’s mandatory scroll snapping. I should probably mention that this problem could, at least in theory, be resolved by switching from mandatory to proximity snapping. I’ve tested proximity snapping in Chrome and Firefox, and I found it inconsistent and confusing. The browser would often snap when I didn’t expect it to, and vice versa. Maybe Twitter’s code is interfering with the proximity algorithm, the browsers are still a bit buggy, or perhaps I’m just “scrolling it wrong,” if that’s even possible. I don’t know.

But the main reason why I went with mandatory snapping is that I wanted to avoid situations where the topmost tweet is only partially on screen after a scroll. The type of fast-scrolling between sets of tweets that I’ve shown in the video above is only possible with mandatory snapping.

If you, like me, prefer mandatory snapping, I can suggest the following two workarounds for the “tall tweet” problem:

  • You can open the tweet on its own page and return to the timeline afterward.
  • If you only want to click the Like or Retweet buttons, you can Shift-click the tweet to select it and then press L to like it, or T followed by Enter to retweet it.

Issues in Chrome and Safari

My scroll snap user styles produce noticeably different scroll snapping behaviors in Chrome, Safari, and Firefox. Those differences are in part since the exact implementation of the snapping mechanism is left up to the browser:

The CSS Scroll Snap Module intentionally does not specify nor mandate any precise animations or physics used to enforce snap positions; this is left up to the user agent.

The current version of Safari has a bug that prevents scroll snapping from working correctly on the Twitter timeline. I have reported this bug.

In Chrome, I have encountered the following problems:

  • The scrolling operations animate inconsistently. Sometimes the animation is slow, sometimes it’s instant, and sometimes it starts slow but is then cut short. I found this irritating.
  • The scrolling operations animate too slowly in general. I performed a test in Chrome and Firefox (20 Space presses), and it took me 70% more time to cover the same distance on my Twitter timeline in Chrome than in Firefox (18.5 seconds in Chrome vs. 11 seconds in Firefox).
  • When I scroll using my laptop’s trackpad, the page flickers a lot. When I attempt to scroll fast by holding down the Space key, the page scrolls very slowly and oscillates. I suspect that both issues are caused by the same algorithm. It seems that Chrome re-snaps at a very high rate in these cases. I have reported this bug.

These browser bugs and differences between browsers can be a problem for websites considering implementing scroll snapping. For example, a web developer might hold back because they don’t like how scroll snapping behaves in one particular browser. Browsers can mitigate this problem by becoming more interoperable. In fact, Scroll Snap is one of the areas of focus of the cross-browser Interop 2022 effort.

Another way the situation could be improved is by introducing new CSS properties that would make scroll snapping more configurable. This could include the duration of the snapping animation, the length of the proximity threshold for snapping, and a mechanism to override mandatory snapping.

To snap or not to snap?

I’ve been using my scroll snap user styles on Twitter’s timeline for a couple of weeks, and I don’t want to go back. The ability to quickly flip through my feed with only the Space key is just on another level.

However, I consider this an advanced feature that probably isn’t for everyone. There’s a reason why I’ve enabled it only on the timeline (/home path) and nowhere else on Twitter’s website. Snapping is a significant change in how the page scrolls, and it takes some time to get used to. It can work great for a specific use case, but it can also get in the way and frustrate the user.

Websites with feeds should therefore consider offering scroll snapping only as an optional feature, after careful consideration and plenty of testing in different browsers and with different input methods (mouse, keyboard, trackpad, touch screen, etc.).

Before you go…

Finally, I highly recommend installing and trying out the Stylus browser extension. Web developers (or anyone who knows CSS) have the power to style any website in their browser. You can apply minor improvements and fixes to your favorite websites. I mostly use it to hide page elements that I find annoying, such as sticky headers, video pop-ups, and vote counts.

But more importantly, Stylus allows you to quickly test new CSS features on any website and report browser bugs, if necessary. By doing this, you can help make the web platform a little better.

How I Added Scroll Snapping To My Twitter Timeline originally published on CSS-Tricks. You should get the newsletter.

Read the whole story
10 days ago
scroll snapping looks really useful for lists.
10 days ago
Wow, I had no idea this was possible!
Share this story

The OG Social Network: Other People’s Websites

1 Comment

“Organize the world's information and make it universally accessible and useful.”

That’s Google’s stated mission.

But what if the world's information becomes locked in disparate silos, inaccessible to a search engine? Is there a future where Google dies on the vine, not enough content to make their engine useful?

Walled social networks were always a problem for Google.

But now there’s Slack. Discord. Substack. Newsletters. Paywalls. All walled and inaccessible to Google — an existential problem.

Perhaps history will conclude killing Google reader killed Google, an overly-simplistic conclusion but poetically ironic nonetheless.

Google+ was Google trying to mimic the walled garden of Facebook — their “how” of extracting value from the people of the internet.

But they already had an answer for Facebook’s News Feed in front of them: Blogger / Google Reader, the read / write of the internet.

The mistake was killing Reader to make Plus a success. Google’s judo move would’ve been to embrace the open web as a social network. Not their network but our network.

They provide the tools – Reader, Blogger, Search — we provide the personal websites. The open, accessible, indexable web as The Next Great Social Network.

A dream? Alas.

Google has stood on top of the success of communities. Groups of people who write content and curate interestingness by linking to other things for humans. Could PageRank have been invented today?

So much online activity is less public now as companies strive to capture the value we create being online with each other — the value I’m creating right now by writing this and linking to other things, things not on Discord or Slack or Confluence but on other peoples’ websites.

Other people’s websites are the OG social network, and the optimist in me is going to riff on MLK’s quote: the social arc of the internet is long, but it bends towards individual websites.

Adblock test (Why?)

Read the whole story
11 days ago
Killing reader was a crime and a terrible mistake.
Share this story

Saturday Morning Breakfast Cereal - Weird

2 Comments and 6 Shares

Click here to go see the bonus panel!

If you've ever watched a scientist scowl at an excel spreadsheet for 16 hours in a single sitting, you'll wonder where this whole concept of loving your work ever came from.

Today's News:
Read the whole story
11 days ago
So true!
Share this story
1 public comment
11 days ago
This is deeply true for me. I don't love the energy industry. But my god, do I have opinions about transmission regulation.
Washington, District of Columbia
Next Page of Stories