As a high school kid, I would always question why I was learning Trigonometric functions and if I’d ever use them in real life problem solving. Those mysterious squiggly functions that haunted me during high school are back. But this time, they’re not here to make me cry over a calculator but it’s here to make CSS come alive!

Surprise, surprise — those Math class nightmares didn’t stay behind. The 2025.stateofcss lists Trigonometric functions among the ‘Most Hated Feature’

In this 2 (or even 3) part series, we will uncover some real use cases for CSS trigonometric functions and hopefully, you might even start looking forward to a little CSS trigonometry. In this article, I will cover the most popular functions of the ‘most hated’ feature: Sin()and Cos()

The Basics — What do Sin() and cos() even do?

If you slept through trigonometry, here’s the cheat sheet:

• Sin(0)gives you how high you are on a circle (the Y-axis).
• Cos(0)gives you how wide you are on a circle (the X-axis).

In CSS they work just like how they do in Math — you give them an angle, and they return a number between -1 and 1.

You can then multiply that by a length to create oscillation or circular movement.

Use cases

The best way to understand trigonometry is by actually ‘seeing’ it.

1. Circular layouts — The easiest way to understand Sin() and Cos()

Let’s arrange some dots evenly around a circle using only CSS and some math.

<div class="parent-container">
  <div class="circle"></div>
  <div class="circle"></div>
  <div class="circle"></div>
  <div class="circle"></div>
  <div class="circle"></div>
  <div class="circle"></div>
  <div class="circle"></div>
  <div class="circle"></div>
  <div class="circle"></div>
  <div class="circle"></div>
  <div class="circle"></div>
  <div class="circle"></div>
</div>

.parent {
  position: relative;
  width: 0; 
  height: 0;
}

/* the “dots” */
.circle {
  --size: 25px;
  --offset: 100px;
  width: var(--size);
  aspect-ratio: 1;
  border-radius: 50%;
  background-color: lightgreen;
  position: absolute;
  left: 0;
  top: 0;
  transform: translate(
    calc(cos(var(--degrees)) * var(--offset)),
    calc(sin(var(--degrees)) * var(--offset))
  );
}

/* Set angle for each dot */
.circle:nth-of-type(1)  { --degrees: 0deg; }
.circle:nth-of-type(2)  { --degrees: 30deg; }
.circle:nth-of-type(3)  { --degrees: 60deg; }
.circle:nth-of-type(4)  { --degrees: 90deg; }
.circle:nth-of-type(5)  { --degrees: 120deg; }
.circle:nth-of-type(6)  { --degrees: 150deg; }
.circle:nth-of-type(7)  { --degrees: 180deg; }
.circle:nth-of-type(8)  { --degrees: 210deg; }
.circle:nth-of-type(9)  { --degrees: 240deg; }
.circle:nth-of-type(10) { --degrees: 270deg; }
.circle:nth-of-type(11) { --degrees: 300deg; }
.circle:nth-of-type(12) { --degrees: 330deg; }

Sin() and Cos()are used to position each dot around a circle. Cos()controls the x position (horizontal), and Sin()controls the y position (vertical). Each dot gets a different — degrees value (0, 30, 60, …), and multiplying those by a radius ( — offset) places them evenly in a circular layout.

2. Wavy patterns

Waves are everywhere — in nature, sound, and even in design. Using the Sin()function in CSS, we can translate the same natural rhythm into our layouts, creating smooth, balanced curves that feel organic yet precise.

<div class="wave-line">
  <div style="--i:0"></div>
  <div style="--i:1"></div>
  <div style="--i:2"></div>
  <div style="--i:3"></div>
  <div style="--i:4"></div>
  <div style="--i:5"></div>
  <div style="--i:6"></div>
  <div style="--i:7"></div>
  <div style="--i:8"></div>
  <div style="--i:9"></div>
</div>

.wave-line {
display: flex;
justify-content: center;
align-items: center;
gap: 1.5rem;
height: 200px;
background: #f6f8ff;
}

.wave-line div {
--t: 0deg;
--angle: calc(var(--i) * 36deg + var(--t));
width: 16px;
height: 16px;
border-radius: 50%;
background: hotpink;
transform: translateY(calc(sin(var(--angle)) * 40px));
animation: wave 2s linear infinite;
}

Each dot gets its own i(index), which we multiply by 36 deg to spread them evenly across 360 deg. Sin()then maps those angles to values between -1 and 1which is perfect for positioning dots along a gentle curve. This creates a visually rhythmic, wave-like pattern.

What can you do with this?

• Create decorative dividers or flowing separators between sections.
• Build magazine-style layouts with wave-shaped image alignments.

3. Animations

Trigonometric functions in CSS aren’t just for static layouts — they could also be used for perfect for smooth, natural animations. By updating angles over time, elements can move along curves, orbit around points, or create rhythmic wave patterns.

<div class="orbit-container">
  <div class="planet"></div>
</div>

<button id="toggle-btn">Start Animation</button>

@property --angle {
  syntax: "<angle>";
  inherits: false;
  initial-value: 0deg;
}

body {
  display: flex;
  flex-direction: column;
  justify-content: center;
  align-items: center;
  height: 100vh;
  background: linear-gradient(135deg, #0d1b2a, #1b263b);
  gap: 2rem;
  margin: 0;
}

.orbit-container {
  position: relative;
  width: 300px;
  height: 300px;
  --angle: 0deg; /* CSS variable for animation */
}

.planet {
  position: absolute;
  top: 50%;
  left: 50%;
  width: 25px;
  height: 25px;
  border-radius: 50%;
  background: radial-gradient(circle at 30% 30%, #f97316, #ff4500);
  box-shadow: 0 0 20px rgba(255, 87, 34, 0.7);
  transform: translate(
    calc(cos(var(--angle)) * 120px),
    calc(sin(var(--angle)) * 120px)
  );
  transition: transform 0.016s linear;
}

/* Define CSS animation */
@keyframes orbit {
  to {
    --angle: 360deg;
  }
}

.orbit-container.animate .planet {
  animation: orbit 5s linear infinite;
}

const container = document.querySelector('.orbit-container');
const btn = document.getElementById('toggle-btn');

btn.addEventListener('click', () => {
  container.classList.toggle('animate');
  btn.textContent = container.classList.contains('animate')
    ? "Stop Animation"
    : "Start Animation";
});

We start by defining a custom property angle, which represents the current rotation in degrees. They keyframes orbit animation gradually increases this angle from 0 deg to 360 deg. As the angle updates, the element’s position is recalculated using Cos()and Sin()

What can you do with this?

Floating animations can use Sin()to create gentle up-and-down movements, while Cos()can drive side-to-side motions.

Both Sin()and Cos()could be combined to produce complex orbital movements which could be useful for loading indicators, decorative elements, or interactive components that need to follow curved trajectories.

Some general trips

• Leverage transform properties for hardware-accelerated animations
• Combine with calc() to scale results from the unit circle’s -1 to 1 range
• Use responsive units like vw or cqi for scalable layouts
• Use CSS custom properties for reusable values and easier maintenance

Performance

CSS trigonometric functions perform better than JavaScript equivalents because calculations happen during the browser’s style computation phase. This eliminates runtime overhead and provides smoother animations, especially when combined with CSS transforms.

Browser support

Both sin()and cos() are widely supported across all browsers.

Final thoughts

At the end of the day, using trigonometry in CSS might feel like owning a treadmill — it’s impressive that you have it, and you will tell everyone you use it, but most of the time you are just staring at them with a sense of existential dread. Well, don’t be that person. Maybe, we should start showing some love to those ‘most hated features’ (and also your treadmill).

Now go forth and rotate things — responsibly!

In the modern web ecosystem , pages are not just rendered — user interactions are tracked and analyzed to optimize user experience, and gather insights. When you click a link on a website, something else may happen besides navigation. When you close a tab, something might still be sent. Most users never see this traffic. Behind the scenes, the web is constantly talking.

This is the privacy story of sendBeacon(), ping, CSP reports.

sendBeacon()

navigator.sendBeacon() was created to solve a practical problem “What if the user leaves before your analytics request finishes”?

If not for sendBeacon(), developers had to use fetch()or XMLHttpRequestduring unload events where the browser must wait for the request to complete before allowing navigation to proceed. The problem with that approach was that it created a poor user experience and unreliable data transmission.

The Beacon API on the other hand, operates differently. It queues requests asynchronously and handles transmission in the background, even after the page has closed. The browser manages the entire process without blocking navigation or requiring your JavaScript to remain active.

Example

The navigator.sendBeacon() method accepts two parameters: a URL endpoint and optional data. It returns a boolean indicating whether the request was successfully queued (not whether it reached the server).

const success = navigator.sendBeacon(url, data)

Use cases

The fire and forget approach of navigator.sendBeacon()could be used for —

• Analytics
• User action tracking
• Error reporting

Privacy implications

The sendBeacon()API, while a valuable tool for developers to send data asynchronously to a server without disrupting page navigation, raises significant privacy concerns that needs careful consideration.

• This API allows websites to transmit user data, such as browsing behaviour or session information, even after a user has left the page, potentially enabling tracking across multiple sites or sessions.
• Without proper safeguards, this functionality could be exploited to collect sensitive information without explicit user consent.

Developers must ensure transparency and implement robust privacy measures, such as anonymizing data and obtaining informed consent, to mitigate these risks and maintain user trust. As privacy regulations like General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA) become increasingly prevalent, understanding and addressing the implications of sendBeacon()is essential for ethical web development.

Best practices

To responsibly use the sendBeacon()API while protecting user privacy, developers should adhere to several best practices —

• Ensure that any data transmitted is minimized and anonymized, avoiding the collection of Personally Identifiable Information (PII) unless absolutely necessary
• Implement clear and transparent user consent mechanisms, such as privacy notices or opt-in checkboxes, to inform users about data collection and obtain their explicit permission.
• Encrypt sensitive data before transmission to protect it from interception or unauthorized access
• Provide users with control over their data by offering options to opt out or delete their information.
• Finally, regularly audit and update your implementation to comply with evolving privacy regulations and standards, ensuring that your use of sendBeacon()aligns with ethical and legal requirements

By prioritizing these practices, developers can leverage the API’s benefits while respecting user privacy and building trust.

<a ping>: The click that tells two stories

The ping attribute is an optional attribute for the <a> tag that specifies one or more URLs to notify when a link is clicked. These notifications are sent as HTTP POST requests to the specified URLs.

Example

<a href="https://example.com" ping="https://tracker.com/logs">Visit me</a>

In this example — Clicking the link navigates to example.com and at the same time, an HTTP POST request is sent to https://tracker.com/logs

How does it work?

When a user clicks a link with a ping attribute:

• The browser sends an HTTP POST request to the specified ping URL(s).
• The link destination i.e href is loaded as usual.
• The ping POST request contains basic information, such as the URL of the link clicked.

Use cases

• Click tracking — Allows websites to send a small POST request when a link is clicked, enabling basic analytics.
• Outbound Link & Affiliate attribution — Helps measure which external link users click, commonly used for affiliate programs, ad attribution, and marketing analytics — without slowing navigation via redirects.
• Audit & Logging — In enterprise or internal systems, it can log user navigation events for monitoring and compliance purposes.

Privacy implications

The ping attribute in the <a> tag, designed to notify servers when a user navigates away from a page, introduces notable privacy implications that require careful handling —

• This attribute can be used to track user behaviour, such as click patterns or navigation paths, potentially enabling cross-site tracking without the user’s knowledge.
• Such tracking can lead to the profiling of users based on their browsing habits, raising concerns about data misuse and lack of transparency

To mitigate these risks, developers should ensure that any data sent via the ping attribute is anonymized and not tied to individual users. Additionally, websites should clearly disclose the use of this attribute in their privacy policies and provide users with the ability to opt out of tracking. By adopting these measures, developers can balance the utility of the ping attribute with the need to protect user privacy and maintain trust.

Best practices

To responsibly implement the ping attribute in the <a> tag while protecting user privacy, developers should follow these best practices.

• Limit the use of the ping attribute to essential purposes, such as analytics or user engagement tracking, and avoid using it for unnecessary or intrusive monitoring
• Ensure that any data transmitted via the ping attribute is anonymized and does not include personally identifiable information (PII).
• Provide clear and transparent disclosure about the use of the ping attribute in your privacy policy, explaining its purpose and how user data will be handled.
• Offer users the ability to opt out of tracking through mechanisms like browser settings or privacy controls on your website
• Regularly review and update your implementation to comply with privacy regulations such as GDPR or CCPA

By adhering to these practices, developers can leverage the ping attribute effectively while respecting user privacy.

Content Security Policy (CSP) headers

CSP is one of the many security headers that gives us a granular control over what resources (images, scripts, stylesheets etc.)a browser is allowed to load for your site.

CSP is the number one defense against Cross-site scripting (XSS). By specifying a whitelist of trusted sources, you can prevent the browser from executing malicious scripts injected by an attacker. Other use cases of CSP could be defending against clickjacking and helping to ensure that a site’s pages will be loaded over HTTPS.

Example

Content-Security-Policy: default-src 'self'; script-src 'self' https://apis.random.com

This policy tells the browser to only load resources from your own domain ('self') by default, and to only execute scripts from your domain or https://apis.random.com.

Use cases

Since complex web applications are more sensitive to XSS, CSP should be used for any application that manages sensitive data, such as administrative UIs, device management consoles, or any products hosting files, documents or messages created by users.

Privacy implications

Content Security Policy (CSP) headers play a critical role in enhancing web security by mitigating risks such as cross-site scripting (XSS) and data injection attacks, but they also have privacy implications that must be carefully managed —

• CSP headers can inadvertently expose information about a website’s security practices, potentially revealing details about the resources it loads or the domains it interacts with. For instance, overly restrictive CSP configurations might lead to blocked resources, resulting in broken functionality or degraded user experiences, which could indirectly impact user trust.
• Additionally, CSP headers can be used to track users by analysing which policies are enforced across different sites, raising concerns about potential privacy leaks.

To address these issues, developers should craft CSP headers that balance security and privacy, ensuring they are neither too permissive nor overly restrictive. Regular audits and updates to CSP configurations are essential to adapt to evolving threats and maintain user privacy while safeguarding against security vulnerabilities.

Best practices

To implement Content Security Policy (CSP) headers effectively while prioritizing both security and privacy, developers should follow these best practices —

• Adopt a principle of least privilege by specifying only the necessary sources for resources like scripts, styles, and images, avoiding overly permissive policies such as ‘unsafe-inline’ or ‘unsafe-eval’.
• Use nonces or hashes to allow specific inline scripts or styles, reducing reliance on broad directives that could compromise security.
• Include reporting mechanisms, such as the report-uri or report-to directives, to monitor and address violations without exposing sensitive information.
• Ensure that CSP headers do not inadvertently reveal sensitive details about your website’s architecture or third-party integrations by carefully configuring directives like default-srcand connect-src
• Regularly test and update your CSP configurations to align with evolving security standards and privacy regulations.

By adhering to these practices, developers can enhance web security while minimizing privacy risks and maintaining a seamless user experience.

Final thoughts

As the web grows more complex, so does the responsibility of those building it. Thoughtful implementation — grounded in clarity, restraint, and purpose is what turns these powerful features into trustworthy experiences. So next time you reach for one of these tools/APIs, consider not just the functionality it enables, but the responsibility that comes with it.

The web is always talking: Link pings, Beacon, CSP was originally published in Samsung Internet Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Have you ever found yourself juggling endless @mediaqueries, tweaking calc()expressions, and still struggling to make your design scale just right?

I have been there too — adjusting font sizes that look perfect on one screen and completely off on another.

Meet clamp(), a versatile CSS function that can become your go-to tool for creating flexible and responsive layouts. It lets you define flexible, fluid values that grow and shrink naturally — without breaking your layout (or your patience!!)

What is clamp( )

The clamp()CSS function lets you set a value that stays within a defined range — between a minimum and a maximum — while growing or shrinking based on a preferred middle value.

<property>: clamp(minimum, preferred, maximum)

Here’s how it works:

• Minimum: The smallest value it can be
• Preferred: The ideal, fluid value (often viewport-based)
• Maximum: The largest value it can grow to

Example

h1 {
 font-size: clamp(1.5rem, 4vw, 3rem)
};

This means:

• The heading’s font size will never go below 1.5rem.
• It will grow fluidly with 4vw (viewport width)
• It won’t exceed 3 rem.

So you get smooth scaling across screen sizes without needing multiple queries.

clamp( ) vs calc( )

At first glance, you might think — can’t I just use calc() for this?

font-size: calc(1rem + 2vw);

Yes, calc()gives fluidity, but without boundaries. On very small screens, text can become tiny and on ultra-wide monitors, it can balloon uncontrollably.

clamp( ) vs media queries

Before clamp(), we’d often write something like this:

h1 {
  font-size: 1.5rem;
}

@media (min-width: 768px) {
  h1{
    font-size: 2.5rem;
  }
}

@media (min-width: 1200px) {
  h1{
    font-size: 3rem;
  }
}

With clamp(), that’s just:

h1 {
  font-size: clamp(1.5rem, 4vw, 3rem);
}

It’s cleaner, easier to tweak, and automatically adapts across every viewport width in between those sizes. With just a single line of code, we achieve a fluid and responsive typography that adapts seamlessly to different screen sizes.

Use cases

You can use clamp() for much more than font sizes:

.container {
  width: clamp(300px, 80%, 1000px);
}

button {
  padding: clamp(0.5rem, 1vw, 1rem);
}

section {
  margin: clamp(1rem, 5vw, 4rem);
}

It’s perfect for anything that should scale fluidly but within sensible bounds — padding, margins, widths, or even grid gaps.

Best practices

• Use vwor %for the fluid middle value.
• Prefer remor emfor minand maxfor consistency

When NOT to use clamp( )

• You need pixel-perfect layouts (icons, logos etc.)
• For animations or transitions that require good consistency.

Accessibility and clamp( )

When used well, clamp()can actually improve accessibility. It helps maintain readable font sizes and smooth scaling without abrupt jumps between breakpoints. By setting sensible minimums, you ensure text never gets too small on compact screens.

A very important thing to note though — overly tight minor maxvalues can stop users who zoom or increase text size from seeing changes. Use relative units like remor em, allow enough range, and always test with zoom to ensure your design remains flexible for everyone.

Browser support

clamp()is widely supported across all major browsers. You can check the latest compatibility details here — caniuse.com

Final thoughts

I personally see clamp()as a smarter way to think about responsive design. Try using clamp()whenever you find yourself juggling calc()and @mediaqueries. It’s a cleaner and smoother way to make your layouts fluid.

Beyond media queries: How CSS clamp( ) redefines responsive design was originally published in Samsung Internet Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

A few months ago — though it still feels like yesterday — our Web Standards group at SRUK attended the W3C TPAC conference. Standing on the shoulders of giants — the previous incarnations of our team — this was the first time that many of us had attended the W3C’s annual conference. As such, this post captures our experiences and learnings from TPAC 2025 (Kobe, Japan), and also presents the perfect opportunity to officially introduce ourselves to all the great developer communities out there:

• Matthew Atkinson: Web Standards Group lead at SRUK.
• Muadh Al Kalbani: Web Standards Technologist (XR).
• Ehsan Toreini: Web Standards Technologist (Privacy).
• Ananya Kittane Yogananda: Web Standards Technologist (DX/UX).

We had heard people describe TPAC as ‘the most intense week of the year’ for anyone working on the Web platform. After attending our first TPAC this year in Kobe, Japan, we can confirm — it absolutely lived up to that description! We would see it as part conference, part meeting marathon, part reunion (for a few people) — and also a space where ideas crystallize at remarkable speed.

What is “TPAC” anyway?

The W3C (World Wide Web Consortium) is the convening body that brings together browser vendors, standards bodies, and the broader web community to collaborate and develop the specifications for the web features that web browsers implement today.

TPAC (Technical Plenary & Advisory Committee) is the W3C’s annual gathering where working groups (WG), community groups (CG), interest groups (IG) meet in person to coordinate, discuss specs, resolve issues, and plan for the future of the web. Throughout the year, these groups meet over regular teleconference calls to review specs, resolve issues, and coordinate work. But when TPAC happens, the groups come together in one physical location for face-to-face meetings. This really helps groups reach consensus, make key decisions faster, and collaborate more deeply with other groups.

To us, this first TPAC was largely about meeting people, going around and introducing ourselves to as many folks as we could, and making connections. It felt amazing to be under the same roof as hundred other smart people who make the web what it is today. It was a fantastic opportunity to meet people personally, ease into conversations, and many of those connections have already blossomed into friendships.

Location

TPAC 2025 was hosted at the Kobe International Conference Center in Japan. It’s a modern, beautifully designed venue with views of the Port Island waterfront — large enough to hold dozens of simultaneous meetings, but compact enough that you constantly bump into people in hallways, cafeterias. Those hallway conversations are often as valuable and meaningful as formal conversations.

For some of us, being vegetarian — food turned out to be more of an adventure than we’d expected and planning this repeatedly, across language barriers required patience. Finding “Veggie Street” and enjoying a warm bowl of vegan ramen was a highlight, and a reminder that persistence often pays off deliciously.

How do W3C meetings typically work?

We were so impressed with how equipped all the meetings were. The tools, processes in place and everything felt like a smooth stream of water.

• Groups meet in structured sessions with chair/s driving the agenda.
• An IRC channel runs in parallel for queue management with a set of commands for participants to signal their presence (present+), get added/removed (q+/q-) into the question queue and so on — for quick logging, comments, taking down minutes.
• A scribe takes notes in real time, capturing what each person said, decisions, resolutions etc.
• There is a bot ‘Zakim’ (and NO, Zakim is not a person) that helps manage the speaker queue, generation of minutes.
• Some groups also use shared Google Docs for collaborative minute-taking.

Overall, it felt like a super structured way to run meetings.

Highlights

The meetings

One of the best parts of TPAC is the sheer amount of great and valuable conversations one can have in every corner of the conference. Whether you’re in a meeting, a breakout session, a coffee break or having lunch, you were almost guaranteed a great conversation with other attendees. This is a great testament to the great work that happens across different groups within W3C — from browser engineers, spec editors, designers and fellow first time TPAC attendees, practically everyone is working on something interesting and great for the Web.

The meetings provided great opportunities to learn more about the latest updates across different facets of the Web Platform, some of the highlights include (but definitely not limited to): WCAG updates on Web Accessibility, new features in the WebRTC spec, more optimised formats for delivering media over the web, potential new pointer events to cater for more devices, new features in the Web Audio and Web speech specs and many, many, others. The meetings that particularly piqued our interest however, were those that introduced emerging and bold ideas that aim to lay solid foundations to ensure a bright and responsible future for the Web Platform. Global and societal topics such as sustainability, AI, monetization, privacy, smart cities, digital identities and many more were actively being discussed and tackled in TPAC, to ensure that W3C is not only working to make the Web a great place today, but also advancing the Web Platform to be great for many future generations to come. To be part of these conversations and contribute to them felt surreal, as we collectively — across different organisations, bodies and interests — work in tandem as one to push the Web Platform forward.

The breakouts

Breakouts are where most of the incubations and futuristic proposals get a chance to showcase their ideas for the future of the platform. Breakout sessions during TPAC are specialized meetings that focus on specific (usually novel and out-of-box) topics within the W3C ecosystem. These sessions provide a platform for experts, developers, and stakeholders to collaborate, share insights, and address challenges related to web technologies. They often cover a wide range of subjects, including web accessibility, privacy, security, and emerging technologies like Agentic AI and Web Monetization.

During these breakout sessions, participants engage in detailed discussions, brainstorming, and decision-making processes to shape the future of web standards. These sessions are crucial for fostering innovation and ensuring that the web remains open, interoperable, and inclusive.

During the week, breakouts are scheduled before the official start of the group meetings (8:00–9:00) or end of the day (17:00–18:00). However, one day is solely dedicated to the breakouts. It was an intense, and creative day with many interesting topics discussed. This ranged from research-focused study on threat modelling digital credentials API to how Agentic Web will impact the future of the web. The sessions dedicated to Agentic AI were particularly very popular. This indicates there is a clear hype for the topic and the web ecosystem is adapting to the coming wave.

Socialising and most used phrases — The TPAC way

Being part of TPAC was not limited to simply attending different meetings and breakout sessions, the conference also presented great opportunities to meet new people, make new friends and share ideas — adding a much needed fun aspect to an intense and productive week.

Given how much we enjoyed our first in-person TPAC experience, it feels right to end this post on a fun note. Picture this — our whole team is having a final dinner in Kobe with a few newly made friends before heading back to London. It was a normal fun dinner to unwind and reflect on an intense, productive week with all the expected conversation taking place: jetlag (past, present and future), food options, cold vs hot food, deciphering receipts, tiredness (past, preset and future), but then someone said the word “queue” — turning our meal into one of the funniest dinners we’ve had at TPAC, because that one word prompted every one around the table to say — out loud — a TPAC specific term that they’ve repeatedly heard in almost every meeting attended, so here goes some of the most used terms, for your amusement:

• “Can you share the link to the slides?”
• “Anyone on the queue?”
• “I will ACK myself” [term used to acknowledge a person that asked to speak (using “q+”) and removes the person from the queue accordingly].
• “Any volunteers to scribe?”
• “Can the people on the call hear us?”
• “RESOLUTION” [term used if participants of a group reach consensus on resolving a particular issue].
• “This is out of scope for this group”
• “Add an issue on GitHub”
• “Let’s continue this conversation over the break”

Looking back

A successful event is definitely one in which a lot of key, and high-quality, decisions were made, and blockers to progress resolved. Another way of measuring success is in the connections that we make, and the ongoing work that results. By all of these measures, we are happy to report TPAC 2025 was a great event. Here are some highlights…

• Having some engaging dialogue around the horizontal review process, particularly around accessibility, and how it can be improved for spec authors, and documented better for the members of our review group.
• Getting involved with revisions to the exciting work of the Second Screen Working Group — a group that allows web content to take advantage of additional displays attached to devices.
• Learning about the latest XR developments, particularly the impact of the work being done by different groups across the Web Platform, like pointer-events, media and sustainability, on the future of the immersive web.
• We were inspired by the dynamic discussions within the Web Machine Learning Working Group and the thought-provoking brainstorming sessions on agentic web and emerging trends. Therefore, the team has taken on a new role as the editor of the Translation API. This task-specific API represents a critical stepping stone toward the seamless integration of trustworthy machine learning (ML) and large language models (LLMs) into the web ecosystem.
• The Technical Architecture Group (TAG) getting an insight on upcoming work across the platform.

We also returned home with: a boatload of GitHub issues to work on, across a wide range of W3C repositories; a new appreciation for the power of ‘in real life’ (IRL) meetings; huge respect for the event organisers, and for the way that the W3C community conducts itself, to create positive fora for debate and solving the challenges we face.

Closing thoughts

We hope you’ve enjoyed this broad and personal view of what participating in this great and important annual event. Hopefully it has illuminated parts of the standards process for you. If it has inspired you to get involved in any W3C work, please do so! If you are working for a member organisation, we encourage you to talk with your Advisory Committee (AC) rep. If not, you can still join any Community Group (CG), where ideas are often incubated, and you have the option of applying to join a Working Group (WG), which can publish specifications, as an Invited Expert.

We hope to see you at a TPAC in future!

Reflections from W3C’s annual conference — Kobe, Japan (2025) was originally published in Samsung Internet Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

If JavaScript were a city, asynchronous tasks would be the traffic (requests zipping in and out), promises waiting at red lights, and callbacks merging onto the highway. What about stoplight? Once a request starts, how to politely tell it to stop?

Meet AbortController — a small API that gives developers the ability to say no to runaway async work.

Why do we care?

Imagine you are building a search box that fetches results as the user types.

fetch(`/api/search?q=${query}`).then(renderResults);

If the user types fast, multiple fetches pile up, older ones might complete after newer ones, causing stale data to appear. You could just ignore old responses, but browser is still doing work for nothing (Network wasted! CPU wasted!) What if you could cancel those outdated fetches cleanly? That’s exactly what AbortController does.

The Basics

The AbortControllerAPI works by creating a signal that you can pass to certain JavaScript functions. The signal is basically an indicator that tells the function if it should continue or abort. To abort a function, you need to call controller.abortand any function that listens to that signal will stop what it is doing (just like how vehicles stop when there’s a red light).

const controller = new AbortController()
const signal = controller.signal

fetch("/api/data", { signal })
  .then(res => res.json())
  .then(data => console.log(data))
  .catch(err => {
    if (err.name === "AbortError") {
      console.log("Request was aborted")
    } else {
      throw err
    }
  })

// Cancel the request
controller.abort()

When controller.abort is called, the fetch immediately stops, freeing up network and memory resources.

fetch() is the most common use case but we could use AbortController with any API that accepts signal.

Other useful use cases

Use it with addEventListener()

You can pass an AbortSignal directly into event listeners — this automatically removes the listener when the signal is aborted, as if you called the removeEventListener(). This works particularly well when you have many event listeners to remove at the same time.

const controller = new AbortController();
const {signal} = controller;

window.addEventListener('mousemove' , e => {
console.log('Mouse moving..');
} , {signal});

setTimeout(() => controller.abort(), 3000);
//After 3 seconds, listener is gone automatically.Use it with your own async functions

You can make your own async code to respond to abort signals.

async function simulateWork(signal) {
  for(let i=0 ; i < 10 ; i++) {
    if(signal.aborted) throw new DOMException('Aborted' , 'AbortError');
      console.log('Working step' , i);
      await new Promise(r => setTimeout(r, 500));
}
}

const controller = new AbortController();
simulateWork(controller.signal)
  .catch(e => console.log('Stopped:', e.name));

setTimeout(() => controller.abort(), 1800);

This pattern is perfect for UI tasks, background jobs, or data processing where you want graceful exits.

Combine multiple Signals with AbortSignal.any()

Sometimes you have multiple cancellation sources — for example, a user action or a timeout. Let’s say you want to combine a timeout and a manual abort signal. The request will be aborted if either the manual abort is called or the timeout is reached. So whichever happens first, cancels the whole thing.

const controller = new AbortController()
const signal = AbortSignal.any(
  controller.signal,
  AbortSignal.timeout(2000), // 2 seconds
)

Link Controllers with AbortSignal.timeout(ms)

You can create a signal that automatically aborts after a given time.

const signal = AbortSignal.timeout(5000) // 5 seconds

fetch("/api/slow", { signal }).catch(err => {
  if (err.name === "TimeoutError") {
    console.log("Request timed out")
  }
})

It’s simple and built in and a big improvement over manually scheduling setTimeout(() => controller.abort())

Reuse and Chain Signals

You can pass the same signal to multiple fetches, and aborting once cancels them all.

const signal = AbortSignal.timeout(2000);
fetch('/user', {signal: controller.signal));
fetch('/posts', {signal: controller.signal));

//After 2 seconds, both requests will abort automatically

Browser support

The AbortController and it’s instance methods are widely supported on all major browsers. For a more detailed information on the browser compatibility, you could check out the mdn docs.

Final thoughts

In JavaScript as in life — it’s easy to start things. A network request, a background task or even a fight with your partner or your mum. But stopping them gracefully? That’s the real skill.

AbortController and AbortSignal bring that missing balance to our async world — giving the power not just to begin, but to end thoughtfully. So next time you kick off a flurry of async operations, remember :

Knowing when to abort() might just save your app — and maybe your evening too!

The art of saying STOP — The JavaScript way was originally published in Samsung Internet Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

JavaScript is everywhere. It powers dynamic websites, interactive apps, and modern user experiences. But just because you can use JavaScript doesn’t always mean you should.

This post isn’t about dismissing JavaScript — it’s an incredible language that makes the web what it is today! Instead, it’s about recognizing the moments where restraint can lead to faster, cleaner experience.

Why the fuss?

Because this isn’t just theory — we’re literally shipping megabytes of JavaScript every day.

The 2024 HTTP Archive study found:

1. The median mobile site ships over 500KB of JavaScript.
2. Many popular sites cross the 2MB+ mark.
3. And remember: every single byte must be downloaded (network cost), parsed (CPU cost), and executed before it can do anything useful.

Shipping excess JavaScript is like making every visitor pay an invisible “tax” — in terms of time, battery, and data.

When simple HTML and CSS would do the job

A surprising number of sites lean on JavaScript for things that HTML and CSS can already handle.

For example , Accordions and dropdowns — these can often be implemented with <details>and <summary>.

Over-engineering these with JavaScript increases maintenance burden and makes your site brittle. Sometimes, the web platform already has your back.

When it slows down performance

JavaScript is one of the heaviest assets on a page. Every byte needs to make the full journey — download, parse, run. If your site ships large bundles for simple tasks, users with slower devices or networks would feel the pain.

1. Large SPA frameworks for content-heavy sites.
2. Client-side rendering everything, even when static HTML could be served.
3. Overuse of polyfills or unused libraries.

A lean site with fewer dependencies often performs better and reaches more users.

When it adds more complexity than value

JavaScript libraries are often introduced to “save time”, but each dependency comes with:

1. Extra code weight
2. Security updates to monitor

For example, adding a 50kB date library just to format timestamps could be replaced with Intl.DateTimeFormat. Choosing native solutions over dependencies can reduce technical debt.

When it reinvents the wheel

It’s tempting to roll your own modal, carousel, or tooltip. But custom-built components often miss crucial edge cases (focus trapping, ARIA attributes, keyboard shortcuts). In these cases, it would be better to rely on HTML/CSS first.

When it hurts accessibility

JavaScript-driven components often re-create UI patterns that already exist natively. Unfortunately, these custom versions can confuse screen readers if not implemented with care.

Some examples:

1. Custom dropdown menus that don’t expose proper ARIA roles.
2. Popups that don’t return focus to the triggering element.

The safest approach is to start with semantic HTML and enhance it progressively with JavaScript, rather than replacing the baseline functionality.

Finding the balance

The goal isn’t to ban JavaScript. It’s to use it thoughtfully. Ask yourself:

1. Can I enhance rather than replace? Am I using JavaScript to progressively improve what HTML and CSS already provide, instead of rebuilding the basics?
2. Have I measured the impact? Will this library or feature actually improve user experience, or just add weight and complexity?
3. Could I ship less to do more? Are there dependencies I can remove, or code I can lazy-load to reduce download, parse, and execution time?
4. Am I respecting the user’s device? Could this feature slow down users on slower phones or poor networks?
5. How does this affect performance, accessibility, and even battery?

The best experiences often come from a progressive enhancement mindset: start with a solid HTML foundation, layer in CSS, and only then sprinkle JavaScript where it truly adds value.

Final thoughts

JavaScript is a powerful tool but as Uncle Ben famously said — With great power comes great responsibility. Every byte shipped, every line executed, and every unnecessary library added has a cost — in performance, accessibility, and battery life.

Sometimes, the most elegant, faster, and most inclusive solution isn’t adding more JavaScript — it’s adding less and when you get that balance right, your site becomes faster, more reliable, and a joy for every user, on every device.

When JavaScript hurts more than it helps was originally published in Samsung Internet Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of the most common questions developers ask when they discover new ways to do things on the web: “Can I use this feature in production?”

Sometimes, a feature works perfectly in your browser but breaks for a chunk of other users on a different browser. Other times, you delay adopting a feature for longer than necessary, just to play it safe.

This is where Baseline steps in. It’s a signal that makes this decision a lot more clearer.

What is Baseline?

Baseline is an initiative that gives an idea of which web platform feature works across the core browser set and are safe to use. This tells us if a web feature is ready for broad, reliable use.

Think of Baseline as a common calendar that we could use to understand what’s safe to adopt right now.

Why Baseline Matters?

Baseline isn’t just a nice-to-have. It shifts how developers make decisions. Instead of “I think it works everywhere”, you can say “This is Baseline — widely available, it’s safe!” But that certainty breaks if a feature does not work with ATs (Assistive Technologies). If it isn’t usable with ATs, it isn't truly safe for everyone.

Baseline — An evolving definition

• Newly available — The feature works across the latest devices and browser versions. The feature might not work in older devices or browsers.

• Widely available — The point at which the feature is generally safe to use (usually within 30 months after the newly available point when most features become available to about 95% of users globally).

• Limited availability — Prior to being newly available, a feature has Limited availability when it’s not yet available across all browsers.

Note: For a feature to be a part of the baseline, it has to be available across the core browser set -

• Apple Safari (macOS and iOS)
• Google Chrome (desktop and Android)
• Firefox (Desktop and Android)
• Edge (Desktop)

How to find the Baseline status of a feature?

The Baseline status entries could be found on caniuse, and the MDN Web Docs pages or the mdn/browser-compat-data repo— where the MDN publishes a npm package for the compatibility data.

The missing piece: Accessibility in Baseline

Baseline gives us confidence about broad browser support, but it doesn’t guarantee accessibility. A feature can be “widely available” in Baseline terms and still fall short for people who rely on assistive technologies.

As W3C puts it, the web is for everyone. If something doesn’t work for any user, that code is definitely considered buggy.

So how do we know if our website works with ATs?

1. allysupport.io — We could use this if we wanted to see support for ARIA roles. It covers support for browsers and screen readers. While in theory, this has to cover all of the HTML input elements that use ARIA mappings but the data is actually incomplete since it relies on volunteers to update and contribute.
2. PowerMapper.com — This is another good tool that takes a step further than allysupport.io. It gives support data for HTML elements across screen readers and browsers. However, there isn’t a guarantee of how often the data is updated and mainly, this isn’t integrated with any popular developer tooling which means we, developers have to know this exists in order to go and give it a try.

How about the web-platform-tests (WPTs)? It then occurred to me that the WPT gives a more in-depth information which is way more than what we actually need. Also, The WPTs were mainly built for browser vendors and it wasn’t really meant for developers.

We have seen how each of these tools have their own drawbacks. Imagine having all of the support data under one umbrella (The Baseline!).

What could a more complete baseline look like?

Baseline should take into consideration the accessibility support. A web feature should technically show ‘full support’ if it does expose the correct information in the accessibility tree, regardless of what the Assistive Technology does.
There’s already promising work in this direction, like Lola Odelola’s accessibility-compat-data project, which explores how assistive technologies actually handle web features. It is also about making that data machine readable so that, in theory, it could be integrated into Baseline later. It’s the kind of data that could one day complement Baseline, helping us build a web that’s both interoperable and accessible.

Final thoughts

Baseline is already helping teams to adopt features more confidently. But if we stop there, we risk shipping code that excludes some users. The real goal isn’t just a web that’s interoperable — it’s a web that’s also inclusive.

While I support the Baseline initiative wholeheartedly, I also believe that the web’s true “baseline” should be the one where accessibility is guaranteed, not optional or out of scope.

Baseline: A feature adoption strategy for the web was originally published in Samsung Internet Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Infinite scroll has become almost synonymous with modern web design. It might feel sleek, immersive, and frictionless — no ‘next page’ button to click, just a smooth river of content that never seems to end.

But here’s the reality — Infinite scroll is often a trap. While it looks modern, it can seriously hurt accessibility, performance, and user experience. In this post, we’ll unpack the infinite scroll trap, show you why it’s problematic!

How infinite scroll works

At its core, infinite scroll is a design approach which loads content continuously as the user scrolls down. Also called endless scroll, the point is that the user never reaches the end of the page. Instead, they’re presented with a perpetual content stream without having to click.

Why infinite scroll seems modern

• Frictionless browsing: Arguably, the biggest advantage of infinite scrolling is that it reduces interruptions and that the users don’t have to click ‘next’ button.
• Keeps users engaged: Endless feeds often feel immersive.

Why is it problematic?

Accessibility nightmares

• Screen readers: Continuous content updates can disorient users. Some screen reader users might think the page is very long and might miss the footer region completely, especially if it is pushed out of reach.
• Focus issues: Newly injected content can grab focus unexpectedly or leave the user lost.
• Cognitive overload: Users with ADHD, dyslexia may struggle with never -ending streams of content.
• Keyboard traps: Infinite scroll can make it impossible for keyboard users to reach controls at the bottom of the page.

Here’s a great list of checkpoints from the article So You think You’ve built a Good Infinite Scroll by Adrian Roselli that’s worth checking before you consider implementing infinite scroll.

Performance costs

• Memory bloat: The DOM grows endlessly. Every new batch of items adds more DOM nodes, images, event listeners, and CSS reflows. This just keeps appending content indefinitely and this could lead to sluggish performance.
• SEO challenges: Infinite scroll often hides content outside of a crawler’s field of vision. Search engine crawlers typically only see the initially loaded content, not what appears later as you scroll. If the crawler can’t access that extra content, it can’t index it — which means large parts of your page may remain invisible in search results.

Better alternatives

You don’t have to ditch dynamic loading — just give users the control.

1. Pagination: With pagination — simply splitting content into different pages and linking to these pages at the foot of a page — users have a sense of where they are in the information hierarchy. They know how many pages they have to navigate and they get to choose whether they go to those pages or not. Seen in that light, pagination gives users back the control that infinite scroll takes from them.
2. “Load More” button: This involves showing a certain number of results per page; below these results there is a button that asks if a user wants to see more. Again, this lets users decide when to fetch more content. One thing to note — place new content after the “Load more” button, not before, so the focus order remains logical, and keyboard-only and screen reader users can continue navigating forward, without being disoriented. (If the additional content was placed before the button, and the focus remained on the button, how would a keyboard-only or screen reader user get back to the start of the content that had been added?)

Some users rely on landmark regions (<main>, <nav> , <footer>, etc.) to quickly jump around content — so far, screen readers are the only assistive technology to fully support this. Providing landmarks for content that comes after the infinitely scrolling area of the page may seem like a solution — but it won’t help keyboard-only users. So, it’s not a complete fix today, though it might become more effective in the future.

If you’re a keyboard-only user, or a web content author, and would like to navigate landmark regions via the keyboard, or visualise the landmark structure of your page in the developer tools panel, you could use an extension such as the Landmarks browser extension.

Final thoughts

Infinite scroll isn’t a one-size-fits-all solution. When used without due care, it creates more problems than it solves. However, with thoughtful design we could enhance the experience allowing all users to access the web content and functionality. Ultimately, giving users control is the key to a better experience.

The infinite scroll trap: Why “modern” isn’t always better was originally published in Samsung Internet Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Samsung Internet has steadily expanded beyond Samsung devices, and today it’s available across the Android ecosystem, giving more people the opportunity to explore its capabilities.

Whether you’re using a Samsung phone or just want a better browsing experience on Android, here are some cool features of Samsung Internet that you probably might not know about — but definitely should.

Customize the menu

Samsung Internet lets you customize the browser menu giving more control over how the menu is laid out, to match your preferences and keep your most-used features within easy reach. Navigate to Settings → Layout and menus → Customize menus

Customizing the menu ensures frequently used tools are always at your fingertips, making browsing more convenient.

Play YouTube videos in the background

Another neat feature, Samsung Internet supports background playback for videos, you can listen to podcasts or play music with the screen off. Navigate to Samsung Internet’s Settings → Useful features → Enable Background play

Just open a video, switch apps or lock the phone — and the audio keeps playing (unless blocked by the site itself).

In-Built video assistant

Watching videos in the browser? Samsung Internet includes a Video Assistant with some of the controls like Picture-in-picture mode, full-screen toggle etc.

Secret Mode with Biometric Lock

A private browsing mode is a staple in most browsers, allowing you to browse without saving history or form data. Samsung Internet’s Secret mode builds on this idea, offering a few extra layers of control.

Biometric protection — Unlock Secret mode using your fingerprint or face

Whether you’re shopping for a gift, or just want extra privacy, Secret mode gives you peace of mind with a private space right in your pocket.

Reader mode

Tired of cluttered websites with popups and ads breaking your flow? Samsung Internet’s Reader mode clears away the noise so you can focus on what matters — the content. Additionally, you could also increase the font-size for a better reading experience, just like a kindle!

This mode is perfect for reading articles, blogs, or long-form content on the go — without distractions.

AI-powered smart browsing tools

Samsung Internet offers some great tools to make your browsing smarter and more helpful.

• Summarise: Get quick summaries of long articles to save time
• Read highlights aloud: Lets the browser read content for you
• Translate: Instantly translate webpages into your preferred language

These tools are designed to make information more accessible — whether you are trying to read on the go or just scanning through an article.

Final thoughts

Samsung Internet is one of the most capable and user-friendly browsers on mobile today. It packs thoughtful features that genuinely improve how you use the web — often in ways you never knew you needed.

So if you haven’t explored these features, now is a great time to give them a closer look. You might have just found your new favourite mobile browser!

Cool Samsung Internet Features You Didn’t Know About was originally published in Samsung Internet Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Most web layouts live inside neat rectangles — but what if you could think outside the box?

With CSS properties like clip-path and shape-outside, you can transform your images and content into dazzling shapes that break free from the box ( literally!)

In this post, we will explore how we could:

1. Clip images into circles, stars, and polygons
2. Add interactive animations to these shapes
3. Wrap text organically around custom shapes to create stunning, editorial style UIs

For all of these examples, you could use any editor to follow along — I’ve used CodePen for my demos.

clip-path & shape-outside in a nutshell

At its core, clip-path lets you define a visible region of an element. It doesn’t affect how text flows or how readers interpret content — it’s purely visual masking. We could think of clip-path as akin to cutting a shape (circle, triangle etc.,) from a rectangular piece of paper.

shape-outside on the other hand, lets us define a shape — which may be non-rectangular and let’s text flow around the floated element’s shape. It helps us create magazine-style layouts.

Usage

Use clip-path when you want to create custom shapes or masks for an element.

Use shape-outside when you want to wrap text or other content around a custom shape.

Use both clip-path and shape-outside together when you want to clip an element to one shape while wrapping content around another shape. This is useful for advanced designs where the element and its surrounding content interact in unique ways.

Syntax Overview

/* clip-path */
.element {
   clip-path: <shape-function> | <path()> | <url> | <geometry-box>;
}

/* shape-outside */
.element {
   shape-outside: <shape-function> | <image> | <path()> | <url> | <gradient> | <geometry-box>;
   float: left; /* Required for text wrapping */
}

/* Using shape-outside & clip-path together */
.element {
   clip-path: <shape-function>;
   shape-outside: <shape-function>;
   float: left;
}

Example values:

Shape-function: circle(), ellipse(), polygon(), inset()

Geometry Box: content-box, padding-box, border-box

For more detailed overview of the syntax, take a look at shape-outside and clip-path’s MDN articles.

The Simplest Shape: Circles

Let’s begin with the most common and easiest shape — a circle. This is perfect for avatars and logos.

Clipping an Image into a Circle

.circle {
  width: 200px;
  height: 200px;
  object-fit: cover;
  clip-path: circle(50%);
}

Spice things up: Creating different polygons

Once we’ve mastered circles, we can create more interesting polygons like triangles, diamonds, trapeziums using clip-path() and polygon().

<div class="gallery">

  <div class="item">
    <img src="https://images.unsplash.com/photo-1472214103451-9374bd1c798e?q=80&w=1170&auto=format&fit=crop&ixlib=rb-4.1.0&ixid=M3wxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8fA%3D%3D" class="triangle">
    <p>Triangle</p>
  </div>

  <div class="item">
    <img src="https://images.unsplash.com/photo-1472214103451-9374bd1c798e?q=80&w=1170&auto=format&fit=crop&ixlib=rb-4.1.0&ixid=M3wxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8fA%3D%3D" alt="Diamond Shape" class="diamond">
    <p>Diamond</p>
  </div>

  <div class="item">
    <img src="https://images.unsplash.com/photo-1472214103451-9374bd1c798e?q=80&w=1170&auto=format&fit=crop&ixlib=rb-4.1.0&ixid=M3wxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8fA%3D%3D" alt="Trapezium Shape" class="trapezium">
    <p>Trapezium</p>
  </div>

</div>

body {
  font-family: sans-serif;
  background: #fafafa;
  padding: 2rem;
  text-align: center;
}

.gallery {
  display: flex;
  gap: 2rem;
  justify-content: center;
  flex-wrap: wrap;
}

.item {
  display: flex;
  flex-direction: column;
  align-items: center;
  width: 200px;
}

img {
  width: 200px;
  height: 200px;
  object-fit: cover;
  border: 3px solid #ccc;
  transition: clip-path 0.3s ease;
}

/* Shapes using clip-path */

.triangle {
  clip-path: polygon(50% 0%, 100% 100%, 0% 100%);
}

.diamond {
  clip-path: polygon(50% 0%, 100% 50%, 50% 100%, 0% 50%);
}

.trapezium {
  clip-path: polygon(20% 0%, 80% 0%, 100% 100%, 0% 100%);
}

Note: When applying clip-path to images, using object-fit: cover ensures they fill the shape properly without distortion.

Want to create your own shapes?

Try clippy- CSS clip-path maker. It helps create visually crafty shapes, from simple triangles to more intricate polygons.

Level up: Adding interactivity

So far we’ve used clip-path to statically crop images into different shapes. But CSS lets us go one step further — we can animate shapes using transitions!

Example: Hovering over a circular image that morphs into a diamond This can be a subtle but engaging visual cue, great for things like testimonials, profile images etc.

<div class="clip-animate-container">
  <h1>Hover over the image to see magic! </h1>
  <div class="image-wrapper">
  <img
    src="https://images.unsplash.com/photo-1541515929569-1771522cbaa9?w=500&auto=format&fit=crop&q=60&ixlib=rb-4.1.0&ixid=M3wxMjA3fDB8MHxzZWFyY2h8N3x8Z2lybCUyMHdpdGglMjBjYW1lcmF8ZW58MHx8MHx8fDA%3D"
    alt="Morphing Image"
    class="clip-circle-to-diamond"  />
  </div>
</div>

.clip-animate-container {
  text-align: center;
  margin: 2rem 0;
}

.image-wrapper{
  position: relative;
  width:219px;
  height:219px;
}

.clip-circle-to-diamond {
  width: 200px;
  height: 200px;
  object-fit: cover;
  transition: clip-path 0.5s ease-in-out;
  clip-path: circle(50%);
  border: 4px solid #ccc;
  border-radius: 12px;
  pointer-events: none;
}

/* Morph into a diamond on hover */
.image-wrapper:hover .clip-circle-to-diamond {
  clip-path: polygon(50% 0%, 100% 50%, 50% 100%, 0% 50%);
}

The .image-wrapper CSS class is added to prevent flickering caused by shape changes — an important consideration for accessibility and for users sensitive to rapid visual shifts.

You can have a look at the output and the code here — Hover demo.

I’ve also created a more advanced animation example. You could use this -animation demo — clip-path() to view and play around.

Magazine-style layouts with shape-outside

For the longest time, web content has lived inside rigid rectangles. Thanks to modern CSS, we now have a tool that brings editorial elegance and fluidity to web layouts. Meet shape-outside!

Let’s see how we could float a circular image and have the paragraph naturally flow around it — creating a layout you’d usually expect from a magazine or a newsletter.

<img src="https://images.unsplash.com/photo-1563207937-508961e52353?q=80&w=627&auto=format&fit=crop&ixlib=rb-4.1.0&ixid=M3wxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8fA%3D%3D" class="circle-small">
<img src="https://images.unsplash.com/photo-1622017634176-8da750043c54?q=80&w=1170&auto=format&fit=crop&ixlib=rb-4.1.0&ixid=M3wxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8fA%3D%3D" class="circle-small">
<p>
  These images float side by side, and the text wraps around both to simulate a multi-column layout of headshots in an editorial feature. These images float side by side, and the text wraps around both to simulate a multi-column layout of headshots in an editorial feature. How amazing is the capability to just use CSS to create such fluid layouts. The web isn't just a rectangle anymore. And nope, we dont need just figma or other design tools to do any of these fancy stuff! These images float side by side, and the text wraps around both to simulate a multi-column layout of headshots in an editorial feature. These images float side by side, and the text wraps around both to simulate a multi-column layout of headshots in an editorial feature. How amazing is the capability to just use CSS to create such fluid layouts. The web isn't just a rectangle anymore. And nope, we dont need just figma or other design tools to do any of these fancy stuff. The web isn't just a rectangle anymore. And nope, we dont need just figma or other design tools to do any of these fancy stuff.
 The web isn't just a rectangle anymore. And nope, we dont need just figma or other design tools to do any of these fancy stuff.
</p>

.circle-small {
  float: left;
  width: 120px;
  height: 120px;
  shape-outside: circle(50%);
  clip-path: circle(50%);
  object-fit: cover;
  margin: 0 1rem 1rem 0;
}

/* Media query for smaller screens (e.g., mobile) */
@media (max-width: 768px) {
  .circle-small {
    width: 30%; 
    margin: 0 0.5rem 0.5rem 0; 
  }
  p {
    font-size: 14px; 
  }
}

Browser Support

Both shape-outside (except <path>) and clip-path are widely supported across all the browsers.

Conclusion

We learnt how we could break the grid and make the web look interesting with just simple CSS. I hope this article inspires you to try out new stuff and make fancy-looking UIs outside of the regular box!

Think Outside the Box: Creating Shapes with CSS clip-path & shape-outside was originally published in Samsung Internet Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.