[css-values][css-conditional][css-animations] Proposal for time-based CSS

[johannesodland]

I'm adding this proposal to start the discussion and to see if it is possible to support conditions, animations and/or values based on the local time of the user.

Motivation

Over the years I've stumbled upon many uses for the users local time in layout and styles. This is currently possible my running small blocking scripts that set custom properties or start animations then can be used to style the page or component. If these values could be set directly in CSS, the code would be more cohesive and less brittle.

Use cases

1. Time based theming

A mini-game is set up to have a generative color theme based on the day of the year. Each day the game has a new combination of colors.

--background-color-1: ...;
--background-color-2: ...;
--background-color-3: ...;
--background-index: mod(day-of-year(), 3);


background-color: var(ident("--background-color-" var(--background-index)));

2. Time tables/schedules

A time table is showing the current programming for a big event. The current row should be highlighted.

--start-time: attr(data-start-time, <timestamp>);

background-color: if(
  time(now >= var(--start-time)): var(--highlight-background); 
  else: transparent;
);
scroll-snap-align: if(
  time(now >= var(--start-time)): start; 
  else: none;
);

3. Showing and hiding

A banner for a big event should show at a specific time.

display: none;

@media time(now >= 2026-03-14T10:30:00Z) {
  display: block;
}

3. Animations

A clock-animation is supposed to follow the time of the day.

animation-timeline: time-of-day();

Your page should start an animation at midnight new years eve:

timeline-trigger-name: --midnight;
timeline-trigger-source: time(2026-01-01T00:00:00Z);

[Crissov]

See #9710 for my proposal to do this with Mediaqueries.

[SebastianZ]

@johannesodland CamelCase is considered a mistake. So the keyword in your time() function should rather be current-time, or to be more precise, current-timestamp, or just now. And the timeOfDay() function should be called time-of-day() following that rule. Though since it refers to the current day as the animation timeline, it might just be called day(). And that might even be generalized to a timespan() function that takes two timestamps or some predefined keywords for the current day and other common time spans.
Also, your use of <time> seems to be different from the existing <time> data type, as it reflects a point in time rather than a duration. Therefore it should rather be called something like <timestamp>, <point-in-time>, or <date-time>. (And maybe <time> should be renamed to <duration>.)

So to iterate on the initial proposal, the concrete additions would be:

• a day-of-year() function that returns a <number> value referencing the number of the current day within a year.
• a <timestamp> data type that refers to a specific point in time and includes the current-time keyword.
• a now keyword that represents the current timestamp.
• a time() function that can be used in conditions to compare two <timestamp> values.
• a timespan() function for animation-timeline that defines a timespan to be used as the animation timeline, referred to as a new <timespan> data type, which either takes two <timestamp> values or a keyword like current-day. (It might even allow to do calculations, meaning a <timestamp> value plus or minus a <time> value, but that probably also requires to extend <time> to take other values than seconds and milliseconds.)

With the above, I think this proposal should probably be split into multiple issues so they can be discussed separately with the media query part maybe being merged with #9710.

Sebastian

[johannesodland]

Thanks @SebastianZ. I went back and edited the proposal.
I'll come back and split it into separate issues when I've had time to structure it a bit.

[johannesodland]

I've created #13659 to discuss numerical functions for calculations, and #13664 for discussing syncing animations with wall time. I amended that proposal a bit, seeing that a new timeline should not be necessary.

Conditional rules are probably best discussed in the existing #9710 proposal?

I think what remains is a proposal for a type that we can use both to specify wall time and relative time, for use in these proposals.