The open source Git project just released Git 2.52 with features and bug fixes from over 94 contributors, 33 of them new. We last caught up with you on the latest in Git back when 2.51 was released.

To celebrate this most recent release, here is GitHub’s look at some of the most interesting features and changes introduced since last time.

Tree-level blame information

If you’re a seasoned Git user, then you are no doubt familiar with git blame, Git’s tool for figuring out which commit most recently modified each line at a given filepath. Git’s blame functionality is great for figuring out when a bug was introduced, or why some code was written the way it was.

If you want to know which commit last modified any portion of a given filepath, that’s easy enough to do with git log -1 -- path/to/my/file, since -1 will give us only the first commit which modifies that path. But what if instead you want to know which commit most recently modified every file in some directory? Answering that question may seem contrived, but it’s not. If you’ve ever looked at a repository’s file listing on GitHub, the middle column of information has a link to the commit which most recently modified that path, along with (part of) its commit message.

The question remains: how do we efficiently determine which commit most recently modified each file in a given directory? You could imagine that you might enumerate each tree entry, feeding it to git log -1 and collecting the output there, like so:

$ git ls-tree -z --name-only HEAD^{tree} | xargs -0 -I{} sh -c '
    git log -1 --format="$1 %h %s" -- $1
  ' -- {}  | column -t -l3 
.cirrus.yml     1e77de10810  ci: update FreeBSD image to 14.3
.clang-format   37215410730  clang-format: exclude control macros from SpaceBeforeParens
.editorconfig   c84209a0529  editorconfig: add .bash extension
.gitattributes  d3b58320923  merge-file doc: set conflict-marker-size attribute
.github         5db9d35a28f  Merge branch 'js/ci-github-actions-update'
[...]

That works, but not efficiently. To see why, consider a case with files A, B, and C introduced by commits C1, C2, and C3, respectively. To blame A, we walk from C3 back to C1 in order to determine that C1 was the most recent commit to modify A. That traversal passed through C2 and C3, but since we were only looking for modifications to A, we’ll end up revisiting those commits when trying to blame B and C. In this example, we visit those three commits six times in total, which is twice the necessary number of history traversals.

Git 2.52 introduces a new command which comes up with the same information in a fraction of the time: git last-modified. To get a sense for how much faster last-modified is than the example above, here are some hyperfine results:

Benchmark 1: git ls-tree + log
  Time (mean ± σ):      3.962 s ±  0.011 s    [User: 2.676 s, System: 1.330 s]
  Range (min … max):    3.940 s …  3.984 s    10 runs

Benchmark 2: git last-modified
  Time (mean ± σ):     722.7 ms ±   4.6 ms    [User: 682.4 ms, System: 40.1 ms]
  Range (min … max):   717.3 ms … 731.3 ms    10 runs

Summary
  git last-modified ran
    5.48 ± 0.04 times faster than git ls-tree + log

The core functionality behind git last-modified was written by GitHub over many years (originally called blame-tree in GitHub’s fork of Git), and is what has powered our tree-level blame since 2012. Earlier this year, we shared those patches with engineers at GitLab, who tidied up years of development into a reviewable series of patches which landed in this release.

There are still some features in GitHub’s version of this command that have yet to make their way into a Git release, including an on-disk format to cache the results of previous runs. In the meantime, check out git last-modified, available in Git 2.52.

[source, source, source]

Advanced repository maintenance strategies

Returning readers of this series may recall our coverage of the git maintenance command. If this is your first time reading along, or you could use a refresher, we’ve got you covered.

git maintenance is a Git command which can perform repository housekeeping tasks either on a scheduled or ad-hoc basis. The maintenance command can perform a variety of tasks, like repacking the contents of your repository, updating commit-graphs, expiring stale reflog entries, and much more. Put together, maintenance ensures that your repository continues to operate smoothly and efficiently.

By default (or when running the gc task), git maintenance relies on git gc internally to repack your repository, and remove any unreachable objects. This has a couple of drawbacks, namely that git gc performs “all-into-one” repacks to consolidate the contents of your repository, which can be sluggish for very large repositories. As an alternative, git maintenance has an incremental-repack strategy, but this never prunes out any unreachable objects.

Git 2.52 bridges this gap by introducing a new geometric task within git maintenance that avoids all-into-one repacks when possible, and prunes unreachable objects on a less frequent basis. This new task uses tools (like geometric repacking) that were designed at GitHub and have powered GitHub’s own repository maintenance for many years. Those tools have been in Git since 2.33, but were awkward to use or discover since their implementation was buried within git repack, not git gc.

The geometric task here works by inspecting the contents of your repository to determine if we can combine some number of packfiles to form a geometric progression by object count. If it can, it performs a geometric repack, condensing the contents of your repository without pruning any objects. Alternatively, if a geometric repack would pack the entirety of your repository into a single pack, then a full git gc is performed instead, which consolidates the contents of your repository and prunes out unreachable objects.

Git 2.52 makes it a breeze to keep even your largest repositories running smoothly. Check out the new geometric strategy, or any of the many other capabilities of git maintenance can do in 2.52.

[source]

---

The tip of the iceberg…

Now that we’ve covered some of the larger changes in more detail, let’s take a closer look at a selection of some other new features and updates in this release.

• This release saw a couple of new sub-commands be added to git refs, Git’s relatively new tool for providing low-level access to your repository’s references. Prior to this release, git refs was capable of migrating between reference backends (e.g., to have your repository store reference data in the reftable format), along with verifying the internal representation of those references.

  git refs now includes two new sub-commands: git refs list and git refs exists. The former is an alias for git for-each-ref and supports the same set of options. The latter works like git show-ref --exists, and can be used to quickly determine whether or not a given reference exists.

  Neither of these new sub-commands introduce new functionality, but they do consolidate a couple of common reference-related operations into a single Git command rather than many individual ones.

  [source]

• If you’ve ever scripted around Git, you are likely familiar with Git’s rev-parse command. If not, you’d be forgiven for thinking that rev-parse is designed to just resolve the various ways to describe a commit into a full object ID. In reality, rev-parse can perform functionality totally unrelated to resolving object IDs, including shell quoting, option parsing (as a replacement for getopt), printing local GIT_ environment variables, resolving paths inside of $GIT_DIR and so much more.

  Git 2.52 introduces the first step to giving some of this functionality a new home via its new git repo command. The git repo command—currently designated as experimental—is designed to be a general-purpose tool for retrieving pieces of information about your repository. For example, you can check whether or not a repository is shallow or bare, along with what type of object and reference format it uses, like so:

  $ keys='layout.bare layout.shallow object.format references.format'
  $ git repo info $keys
  layout.bare=false
  layout.shallow=false
  object.format=sha1
  references.format=files

  The new git repo command can also print out some general statistics about your repository’s structure and contents via its git repo structure sub-command:

  $ git repo structure
  Counting objects: 497533, done.
  | Repository structure | Value  |
  | -------------------- | ------ |
  | * References         |        |
  |   * Count            |   2871 |
  |     * Branches       |     58 |
  |     * Tags           |   1273 |
  |     * Remotes        |   1534 |
  |     * Others         |      6 |
  |                      |        |
  | * Reachable objects  |        |
  |   * Count            | 497533 |
  |     * Commits        |  91386 |
  |     * Trees          | 208050 |
  |     * Blobs          | 197103 |
  |     * Tags           |    994 |

  [source, source, source]

• Back in 2.28, the Git project introduced the init.defaultBranch configuration option to provide a default branch name for any repositories created with git init. Since its introduction, the default value of that configuration option was “master”, though many set init.defaultBranch to “main” instead.

  Beginning in Git 3.0, the default value for init.defaultBranch will change to “main”. That means that any repositories created in Git 3.0 or newer using git init will have their default branch named “main” without the need for any additional configuration.

  If you want to get a sneak peak of that, or any other planned change for Git 3.0, you can build Git locally with the WITH_BREAKING_CHANGES build-flag to try out the new changes today.

  [source, source]

• By default, Git uses SHA-1 to provide a content-addressable hash of any object in your repository. In Git 3.0, Git will instead use SHA-256 which offers more appealing security properties. Back in our coverage of Git 2.45, we talked about some new changes which enable writing out separate copies of new objects using both SHA-1 and SHA-256 as a transitory step towards interoperability between the two.

  In Git 2.52, the rest of that work towards interoperability begins. Though the changes that landed in this release are focused on laying the groundwork for future interoperability features, the hope is that eventually you can use a Git repository with one hash algorithm, while pushing and pulling from another repository using a different hash algorithm.

  [source]

• Speaking of other bleeding-edge changes in Git, this release is the first to (optionally) use Rust code for some internal functionality within Git. This mode is optional and guarded behind a new WITH_RUST build flag. When built with this mode enabled, Git will use a Rust implementation for encoding and decoding variable-width integers.

  Though this release only introduces a Rust variant of some minor utility functionality, it sets up the infrastructure for much more interesting parts of Git to be rewritten in Rust.

  Rust support is not yet mandatory, so Git 2.52 will continue to run just fine on platforms that don’t have a Rust compiler. However, Rust support will be required for Git 3.0, at which point many more components of Git will likely depend on Rust code.

  [source, source, source]

• Long-time readers may recall our coverage of changed-path Bloom filters within Git from back in 2.28. If not, a changed-path Bloom filter is a probabilistic data structure that can approximate which file path(s) were modified by a commit (relative to its first parent). Since Bloom filters never have false negatives (i.e. indicating a commit did not modify some path when it in fact did), they can be used to accelerate many path-scoped traversals throughout Git (including last-modified above!).

  More recently, we covered new ways of using Bloom filters within Git, like providing multiple paths of interest at the same time (e.g., git log /my/subdir /my/other/subdir) which previously were not supported with Bloom filters. At that time, we wrote that there were ongoing discussions about supporting Bloom filters in even more of Git’s expressive pathspec syntax.

  This release delivers the result of those discussions, and now supports the performance benefits of using Bloom filters in even more scenarios. One example here is when a pathspec contains wildcards in some, but not all of its components, like foo/bar/*/baz, where Git will now use its Bloom filter for the non-wildcard components of the path. To read about even more scenarios that can now leverage Bloom filters, check out the link below.

  [source]

• This release also saw a number of performance improvements across many areas of the project. git describe learned how to use a priority queue to speed up performance by 30%. git remote picked up a couple of new tricks to optimize renaming references with its rename sub-command. git ls-files can keep the index sparse in cases where it couldn’t before. git log -L became significantly faster by avoiding some unnecessary tree-level diffs when processing merge commits. Finally, xdiff (the library that powers Git’s file-level diff and merge engine) benefitted from a pair of optimizations (here, and here) in this release, and even more optimizations that will likely land in a future release.

  [source, source, source, source]

• Last but not least, some updates to Git’s sparse-checkout feature, which learned a new “clean” sub-command. git sparse-checkout clean can help you recover from tricky cases where some files are left outside of your sparse-checkout definition when changing which part(s) of the repository you have checked out.

  The details of how one might get into this situation, and why recovering from it with pre-2.52 tools alone was so difficult, are surprisingly technical. If you’re interested in all of the gory details, this commit has all of the information about this change.

  In the meantime, if you use sparse-checkout and have ever had difficulty cleaning up when switching your sparse-checkout definition, give git sparse-checkout clean a whirl with Git 2.52.

  [source]

…the rest of the iceberg

That’s just a sample of changes from the latest release. For more, check out the release notes for 2.52, or any previous version in the Git repository.

The post Highlights from Git 2.52 appeared first on The GitHub Blog.

Microsoft 365 Copilot Connectors provide a way of making data outside of Microsoft 365 available to Copilot.

Although Microsoft 365 Copilot is probably best known for its ability to interact with Microsoft 365 data, businesses typically also have data stored in other data sources.

What if Copilot could read your Google Drive or Salesforce records just as easily as your SharePoint files?

Microsoft 365 Copilot was originally designed to act as a tool for interacting with documents and data stored within the Microsoft ecosystem. Realistically however, nearly every business has data that lives in other locations. For example, an organization might have data residing within the Google platform or within a SaaS application such as Salesforce.

This is where Microsoft 365 Copilot connectors come into play. Copilot connectors make it so that Copilot can interact with data that is stored outside of the Microsoft ecosystem.

If your data lives everywhere, why shouldn’t your AI assistant?

The main benefit to using Copilot Connectors is that connectors can bring all of an organization’s data together in one place, making it easier for users to interact with that data.

It’s not magic – it’s plumbing. But very smart plumbing.

When an organization uses a Copilot connector to link to an external data source, the data within that external data source is ingested into Microsoft Graph, where it resides alongside native Microsoft data, such as the data associated with applications such as SharePoint or Outlook.

When a user attempts to locate data using Microsoft Search, the search is able to return results from both Microsoft and external data sources. As an example, the search results might include data from sources such as the Microsoft 365 applications (Outlook, SharePoint, etc.) as well as business data from external sources such as ServiceNow, MediaWiki, Salesforce, or Jira.

Better still, because Copilot is designed around Microsoft Graph, it means that the user’s Copilot prompts will automatically take into account data that is stored natively in the Microsoft cloud, as well as data that has been pulled in from other sources and is now referenced within the Microsoft Graph. To put it another way, users no longer need to search every app or data source separately, users can receive aggregated search results within Microsoft Search.

Microsoft further enhances the search experience by accompanying Copilot responses with a list of references. These references display the data source and a document preview.

Without Copilot connectors

• Search each app individually
• Switch tools constantly
• Miss insights due to data fragmentation

With Copilot connectors

• One unified search
• AI understands the meaning, not just keywords
• External + Microsoft data appear together

Semantic indexing – Copilot doesn’t just read your data, it interprets it

In order for Microsoft Copilot to work properly with external data sources, it needs to do more than to simply ingest the data into Microsoft Graph. Copilot must actually understand the data. Otherwise, it will be unable to properly answer user’s natural language queries pertaining to that data.

Semantic indexing helps Copilot to understand what you mean, not just the words that you type. To understand why this is important, imagine for a moment that you are looking for a recipe online using your favorite search engine. If you enter a generic phrase such as “blackberry dessert”, you are probably going to get results such as blackberry cobbler, blackberry pie, and blackberry ice cream. It’s likely a safe bet that none of those web pages included the phrase “blackberry dessert” and yet the search engine found the recipes anyway because it understood that a pie is a dessert.

This is layer of understanding is exactly what semantic indexing provides to Microsoft Copilot. Semantic indexing helps Copilot to find what you are looking for, even when your query is a little bit vague. This level of understanding goes a long way toward making Microsoft Search more useful and delivering better overall satisfaction with the search experience for your end users.

At a minimum, Copilot connectors index each document’s title and content. However, some connectors index additional pieces of information.

Semantic labels – When keywords fail, labels guide Copilot to the right shelf.

Semantic labels can also help Copilot to deliver better results for natural language queries. It is worth noting that semantic labels exist separately from semantic indexing and do not affect the indexing process.

A semantic label is essentially a tag that can help make it easier to locate certain information. This tagging process is somewhat similar to putting a sticky note on a book as a way of helping to remember where you found information that you want to come back to later on.

Semantic labels are useful for delivering better results from topic and keyword searches or for searches in which the system needs to understand the contextual relationship between various data sources.

While semantic labels can be useful, there are some types of searches that simply do not benefit from their use. For example, if you are performing a multi-parameter query or a query that is based on something other than topics or keywords, then semantic labels won’t help you.

If for example, you were to search for all of the projects assigned to a particular user, then semantic labels will not typically be used, because semantic labels focus on content and keywords, not on metadata.

What types of Copilot connectors are available?

In order for an organization to access business data stored outside of the Microsoft ecosystem using Copilot, the organization will need a connector that is specifically designed to work with the external service. Fortunately, Microsoft provides over 100 prebuilt connectors that are available within the Copilot Connectors gallery.

A few of the available prebuilt connectors include:

Category	Example Connectors
Productivity	Google Drive, Box
CRM	Salesforce
ITSM	ServiceNow
Microsoft Native	Azure, SharePoint

Not surprisingly, there are also prebuilt connectors that can link to native Microsoft content sources, such as Microsoft Azure.

Custom Copilot connectors

Although the Microsoft Copilot Connectors gallery contains numerous connectors that are ready to use, there is not a readily available connector for every conceivable data source. Fortunately, however, Microsoft provides an Application Programming Interface (API) that you can use to build your own custom Copilot connectors that you can use as a toolkit to link Copilot to various external items. Some organizations have gone as far as to make the creation of copilot connectors part of their DevOps workflows.

If you aren’t a developer, you may be able to link Copilot to external content sources without having to know how to use an API or a Software Development Kit (SDK). Many software vendors and independent experts have created their own custom Copilot connectors and made them available for download on GitHub.

Data access permissions – If you can’t access it, neither can Copilot. It’s as simple as that.

Microsoft 365 Copilot is designed to respect access control permissions that have been put in place. That way, a user cannot use Copilot to gain access to information that they would not ordinarily have access to. In order to do so, admins register an external connection to an app or a data source. And then use the Admin Center to grant permissions through Microsoft Entra.

Because Microsoft Entra handles the user authentication process, it understands which users are signed in and which source systems and resources those users have access to. The end result is that Copilot respects all of the access controls that have been put in place, meaning that users will never be exposed to data that they can’t already access.

The post Introducing Microsoft 365 Copilot Connectors: What You Need to Know appeared first on Petri IT Knowledgebase.

This is a series! It all started a couple of articles ago, when we found out that, according to the State of CSS 2025 survey, trigonometric functions were the “Most Hated” CSS feature.

I’ve been trying to change that perspective, so I showcased several uses for trigonometric functions in CSS: one for sin() and cos() and another on tan(). However, that’s only half of what trigonometric functions can do. So today, we’ll poke at the inverse world of trigonometric functions: asin(), acos(), atan() and atan2().

Inverse functions?

Recapping things a bit, given an angle, the sin(), cos() and tan() functions return a ratio presenting the sine, cosine, and tangent of that angle, respectively. And if you read the last two parts of the series, then you already know what each of those quantities represents.

What if we wanted to go the other way around? If we have a ratio that represents the sine, cosine or tangent of an angle, how can we get the original angle? This is where inverse trigonometric functions come in! Each inverse function asks what the necessary angle is to get a given value for a specific trigonometric function; in other words, it undoes the original trigonometric function. So…

• acos() is the inverse of cos(),
• asin() is the inverse of sin(), and
• atan() and atan2() are the inverse of tan().

They are also called “arcus” functions and written as arcos(), arcsin() and arctan() in most places. This is because, in a circle, each angle corresponds to an arc in the circumference.

The length of this arc is the angle times the circle’s radius. Since trigonometric functions live in a unit circle, where the radius is equal to 1, the arc length is also the angle, expressed in radians.

Their mathy definitions are a little boring, to say the least, but they are straightforward:

• y = acos(x) such that x = cos(y)
• y = asin(x) such that x = sin(y)
• y = atan(x) such that x = tan(y)

acos() and asin()

Using acos() and asin(), we can undo cos(θ) and sin(θ) to get the starting angle, θ. However, if we try to graph them, we’ll notice something odd:

The functions are only defined from -1 to 1!

Remember, cos() and sin() can take any angle, but they will always return a number between -1 and 1. For example, both cos(90°) and cos(270°) (not to mention others) return 0, so which value should acos(0) return? To answer this, both acos() and asin() have their domain (their input) and range (their output) restricted:

• acos() can only take numbers between -1 and 1 and return angles between 0° and 180°.
• asin() can only take numbers between -1 and 1 and return angles between -90° and 90°.

This limits a lot of the situations where we can use acos() and asin(), since something like asin(1.2) doesn’t work in CSS* — according to the spec, going outside acos() and asin() domain returns NaN — which leads us to our next inverse function…

atan() and atan2()

Similarly, using atan(), we can undo tan(θ) to get θ. But, unlike asin() and acos(), if we graph it, we’ll notice a big difference:

This time it is defined on the whole number line! This makes sense since tan() can return any number between -Infinity and Infinity, so atan() is defined in that domain.

atan() can take any number between -Infinity and Infinity and returns angles -90° and 90°.

This makes atan() incredibly useful to find angles in all kinds of situations, and a lot more versatile than acos() and asin(). That’s why we’ll be using it, along atan2(), going forward. Although don’t worry about atan2() for now, we’ll get to it later.

Finding the perfect angle

In the last article, we worked a lot with triangles. Specifically, we used the tan() function to find one of the sides of a right-angled triangle from the following relationships:

To make it work, we needed to know one of its sides and the angle, and by solving the equation, we would get the other side. However, in most cases, we do know the lengths of the triangle’s sides and what we are actually looking for is the angle. In that case, the last equation becomes:

Triangles and Conic Gradients

Finding the angle comes in handy in lots of cases, like in gradients, for instance. In a linear gradient, for example, if we want it to go from corner to corner, we’ll have to match the gradient’s angle depending on the element’s dimensions. Otherwise, with a fixed angle, the gradient won’t change if the element gets resized:

.gradient {
  background: repeating-linear-gradient(ghostwhite 0px 25px, darkslategray 25px 50px);
}

This may be the desired look, but I think that most often than not, you want it to match the element’s dimensions.

Using linear-gradient(), we can easily solve this using to top right or to bottom left values for the angle, which automatically sets the angle so the gradient goes from corner to corner.

.gradient {
  background: repeating-linear-gradient(to top right, ghostwhite 0px 25px, darkslategray 25px 50px);
}

However, we don’t have that type of syntax for other gradients, like a conic-gradient(). For example, the next conic gradient has a fixed angle and won’t change upon resizing the element.

.gradient {
  background: conic-gradient(from 45deg, #84a59d 180deg, #f28482 180deg);
}

Luckily, we can fix this using atan()! We can look at the gradient as a right-angled triangle, where the width is the adjacent side and the height the opposite side:

Then, we can get the angle using this formula:

.gradient {
  --angle: atan(var(--height-gradient) / var(--width-gradient));
}

Since conic-gradient() starts from the top edge — conic-gradient(from 0deg) — we’ll have to shift it by 90deg to make it work.

.gradient {
  --rotation: calc(90deg - var(--angle));
  background: conic-gradient(from var(--rotation), #84a59d 180deg, #f28482 180deg);
}

You may be wondering: can’t we do that with a linear gradient? And the answer is, yes! But this was just an example to showcase atan(). Let’s move on to more interesting stuff that’s unique to conic gradients.

I got the next example from Ana Tudor’s post on “Variable Aspect Ratio Card With Conic Gradients”:

Pretty cool, right?. Sadly, Ana’s post is from 2021, a time when trigonometric functions were specced out but not implemented. As she mentions in her article, it wasn’t possible to create these gradients using atan(). Luckily, we live in the future! Let’s see how simple they become with trigonometry and CSS.

We’ll use two conic gradients, each of them covering half of the card’s background.

To save time, I’ll gloss over exactly how to make the original gradient, so here is a quick little step-by-step guide on how to make one of those gradients in a square-shaped element:

Since we’re working with a perfect square, we can fix the --angle and --rotation to be 45deg, but for a general use case, each of the conic-gradients would look like this in CSS:

.gradient {
  background: 
    /* one below */
    conic-gradient(
      from var(--rotation) at bottom left,
      #b9eee1 calc(var(--angle) * 1 / 3),
      #79d3be calc(var(--angle) * 1 / 3) calc(var(--angle) * 2 / 3),
      #39b89a calc(var(--angle) * 2 / 3) calc(var(--angle) * 3 / 3),
      transparent var(--angle)
    ),
    /* one above */
    conic-gradient(
      from calc(var(--rotation) + 180deg) at top right,
      #fec9d7 calc(var(--angle) * 1 / 3),
      #ff91ad calc(var(--angle) * 1 / 3) calc(var(--angle) * 2 / 3),
      #ff5883 calc(var(--angle) * 2 / 3) calc(var(--angle) * 3 / 3),
      transparent var(--angle)
    );
}

And we can get those --angle and --rotation variables the same way we did earlier — using atan(), of course!

.gradient {
  --angle: atan(var(--height-gradient) / var(--width-gradient));
  --rotation: calc(90deg - var(--angle));
}

What about atan2()?

The last example was all abou atan(), but I told you we would also look at the atan2() function. With atan(), we get the angle when we divide the opposite side by the adjacent side and pass that value as the argument. On the flip side, atan2() takes them as separate arguments:

• atan(opposite/adjacent)
• atan2(opposite, adjacent)

What’s the difference? To explain, let’s backtrack a bit.

We used atan() in the context of triangles, meaning that the adjacent and opposite sides were always positive. This may seem like an obvious thing since lengths are always positive, but we won’t always work with lengths.

Imagine we are in a x-y plane and pick a random point on the graph. Just by looking at its position, we can know its x and y coordinates, which can have both negative and positive coordinates. What if we wanted its angle instead? Measuring it, of course, from the positive x-axis.

Well, remember from the last article in this series that we can also define tan() as the quotient between sin() and cos():

Also recall that when we measure the angle from the positive x-axis, then sin() returns the y-coordinate and cos() returns the x-coordinate. So, the last formula becomes:

And applying atan(), we can directly get the angle!

This formula has one problem, though. It should work for any point in the x-y plane, and since both x and y can be negative, we can confuse some points. Since we are dividing the y-coordinate by the x-coordinate, in the eyes of atan(), the negative y-coordinate looks the same as the negative x-coordinate. And if both coordinates are negative, it would look the same as if both were positive.

To compensate for this, we have atan2(), and since it takes the y-coordinate and x-coordinate as separate arguments, it’s smart enough to return the angle everywhere in the plane!

Let’s see how we can put it to practical use.

Following the mouse

Using atan2(), we can make elements react to the mouse’s position. Why would we want to do that? Meet my friend Helpy, Clippy’s uglier brother from Microsoft.

Helpy wants to always be looking at the user’s mouse, and luckily, we can help him using atan2(). I won’t go into too much detail about how Helpy is made, just know that his eyes are two pseudo-elements:

.helpy::before,
.helpy::after {
  /* eye styling */
}

To help Helpy, we first need to let CSS know the mouse’s current x-y coordinates. And while I may not like using JavaScript here, it’s needed in order to pass the mouse coordinates to CSS as two custom properties that we’ll call --m-x and --m-y.

const body = document.querySelector("body");

// listen for the mouse pointer
body.addEventListener("pointermove", (event) => {
  // set variables for the pointer's current coordinates
  let x = event.clientX;
  let y = event.clientY;

  // assign those coordinates to CSS custom properties in pixel units
  body.style.setProperty("--m-x", `${Math.round(x)}px`);
  body.style.setProperty("--m-y", `${Math.round(y)}px`);
});

Helpy is currently looking away from the content, so we’ll first move his eyes so they align with the positive x-axis, i.e., to the right.

.helpy::before,
.helpy::after {
  rotate: 135deg;
}

Once there, we can use atan2() to find the exact angle Helpy has to turn so he sees the user’s mouse. Since Helpy is positioned at the top-left corner of the page, and the x and y coordinates are measured from there, it’s time to plug those coordinates into our function: atan2(var(--m-y), var(--m-x)).

.helpy::before,
.helpy::after {
  /* rotate the eyes by it's starting position, plus the atan2 of the coordinates */
  rotate: calc(135deg + atan2(var(--m-y), var(--m-x)));
}

We can make one last improvement. You’ll notice that if the mouse goes on the little gap behind Helpy, he is unable to look at the pointer. This happens because we are measuring the coordinates exactly from the top-left corner, and Helpy is positioned a little bit away from that.

To fix this, we can translate the origin of the coordinate system directly on Helpy by subtracting the padding and half its size:

Which looks like this in CSS:

.helpy::before,
.helpy::after  {
  rotate: calc(
    135deg +
      atan2(
        var(--m-y) - var(--spacing) - var(--helpy-size) / 2,
        var(--m-x) - var(--spacing) - var(--helpy-size) / 2
      )
  );
}

This is a somewhat minor improvement, but moving the coordinate origin will be vital if we want to place Helpy in any other place on the screen.

Extra: Getting the viewport (and anything) in numbers

I can’t finish this series without mentioning a trick to typecast different units into simple numbers using atan2() and tan(). It isn’t directly related to trigonometry but it’s still super useful. It was first described amazingly by Jane Ori in 2023, and goes as follows.

If we want to get the viewport as an integer, then we can…

@property --100vw {
  syntax: "<length>;";
  initial-value: 0px;
  inherits: false;
}

:root {
  --100vw: 100vw;
  --int-width: calc(10000 * tan(atan2(var(--100vw), 10000px)));
}

And now: the --int-width variable holds the viewport width as an integer. This looks like magic, so I really recommend reading Jane Ori’s post to understand it. I also have an article using it to create animations as the viewport is resized!

What about reciprocals?

I noticed that we are still lacking the reciprocals for each trigonometric function. The reciprocals are merely 1 divided by the function, so there’s a total of three of them:

• The secant, or sec(x), is the reciprocal of cos(x), so it’s 1 / cos(x).
• The cosecant, or csc(x), is the reciprocal of sin(x), so it’s 1 / sin(x).
• The cotangent, or cot(x) is the reciprocal of tan(x), so it’s 1 / tan(x).

The beauty of sin(), cos() and tan() and their reciprocals is that they all live in the unit circle we’ve looked at in other articles in this series. I decided to put everything together in the following demo that shows all of the trigonometric functions covered on the same unit circle:

That’s it!

Welp, that’s it! I hope you learned and had fun with this series just as much as I enjoyed writing it. And thanks so much for those of you who have shared your own demos. I’ll be rounding them up in my Bluesky page.

---

The “Most Hated” CSS Feature: asin(), acos(), atan() and atan2() originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.