CSS on Jingyuan

An Apple-Style Web Clock Widget: Design Notes and Technical Details

Fri, 24 Jul 2026 20:00:00 +0200

This post explains how I designed and built the new Apple-style dual-time web clock on my homepage, from its visual decisions to the time-zone and rendering logic behind it.

The clock now sits directly below the search box on the desktop version of the homepage. It compares the visitor’s current time with “My time” using two analog dials, while deliberately avoiding a widget title, a personal name, or a country label.

It is a small addition, but it brought together more interesting problems than its size suggests: browser time zones, daylight-saving changes, analog geometry, light and dark presentation, responsive layout, bilingual text, and accessible live information.

The reusable source code is now available on GitHub: Jingyuan-Zheng/apple-style-web-clock-widget. The MIT-licensed repository includes a standalone demo, framework-free CSS and JavaScript, bilingual documentation, configuration examples, and tests for time-zone and hand-angle calculations.

A Familiar Interface Without Copying an App

The visual direction is clearly inspired by Apple’s clock interfaces: circular faces, thin hands, restrained typography, a bright orange second hand, and a rounded card with soft depth.

The goal was not to reproduce a specific Apple screen pixel for pixel. It was to borrow the qualities that make those interfaces immediately understandable:

the clock should be recognizable before any text is read;
the two time zones should feel related but remain visually distinct;
labels should explain only what the user needs;
decoration should never compete with the hands or numerals.

That is why the visible copy is reduced to “Your time” and “My time.” A heading such as “World Clock” would repeat what the two dials already communicate, while a personal name or country would add visual noise and expose more context than the widget needs.

One Instant, Two Wall Clocks

The most important technical decision is to treat both dials as two views of the same instant.

Every update starts from one Date:

`1`	`const now = new Date();`

The visitor’s zone comes from the browser:

1
2

const localZone =
    Intl.DateTimeFormat().resolvedOptions().timeZone || "UTC";

The second dial uses the time zone configured by the site. Both are passed through Intl.DateTimeFormat with formatToParts(), which gives numeric year, month, day, hour, minute, and second values for the selected IANA time zone.

This is safer than manually adding a fixed number of hours. A fixed +1 or +2 eventually becomes wrong when daylight-saving rules change. The Intl API lets the browser’s time-zone database resolve the applicable offset for the current instant.

Calculating the Time Difference

Displaying a wall-clock time is only half the job. The widget also shows the difference between the two zones.

For a target zone, the formatted wall-clock parts are reconstructed as if they were UTC:

const wallTimeAsUtc = Date.UTC(
    year,
    month - 1,
    day,
    hour,
    minute,
    second,
);

const offsetMinutes =
    Math.round((wallTimeAsUtc - currentSecond) / 60000);

The difference displayed under the second clock is then:

`1`	`targetOffsetMinutes - localOffsetMinutes`

This also handles half-hour and quarter-hour zones. The output formatter keeps one decimal place when necessary instead of assuming that every time-zone difference is a whole number.

Turning Time into Hand Angles

An analog clock is mostly geometry. A complete circle is 360 degrees, so each minute or second represents 6 degrees, and each hour represents 30 degrees.

1
2
3

const minuteAngle = minute * 6;
const hourAngle = (hour % 12) * 30 + minuteAngle / 12;
const secondAngle = second * 6;

The small minuteAngle / 12 term matters. Without it, the hour hand would jump abruptly from one number to the next. Including it makes the hour hand travel gradually as the minutes pass.

Each hand is a narrow positioned element whose transform origin sits at its bottom center:

1
2

transform: rotate(var(--clock-rotation));
transform-origin: bottom center;

JavaScript only updates the custom property. CSS remains responsible for the hand’s shape, length, color, and positioning.

The numerals use the same separation of concerns. Hugo generates twelve repeated elements, CSS rotates each one around the dial, and an inverse rotation keeps the numeral upright.

The Site Theme and the Dial Theme Are Different

The component has two independent kinds of appearance.

The outer card follows the blog’s light or dark theme so that it belongs naturally in the sidebar. The clock face, however, follows the time shown by that particular clock:

07:00–18:59 uses a light dial;
19:00–06:59 uses a dark dial.

This distinction was important. If the entire widget followed only the website theme, switching the blog to dark mode would turn a daytime clock dark as well. That would remove useful information from the visual design.

Because each dial evaluates its own zoned hour, it is possible—and intentional—for one face to be light while the other is dark.

Recalculate Instead of Counting

The widget refreshes once per second with setInterval, but it never treats the previous tick as the source of truth.

Each tick creates a fresh Date and recalculates every hand from the current system time. If the browser delays a timer because a tab is in the background, the clock corrects itself on the next update instead of accumulating drift.

This also means daylight-saving changes and system time adjustments are picked up naturally. The interval is only a request to repaint; it is not the clock’s internal timekeeper.

Hugo Integration and the Desktop-Only Decision

The widget is implemented as a local Hugo partial and registered immediately after the search widget in the homepage configuration. This keeps the structure modular: the search component remains unchanged, and the clock can be moved or removed through the widget list.

The HTML contains the semantic structure and bilingual labels. SCSS owns the card, dial, hands, numerals, and theme states. TypeScript owns time-zone conversion and live updates.

The open-source version removes the Hugo dependency and exposes the same ideas through standard data-* attributes, so it can be embedded in an ordinary webpage without a framework or build step.

The blog’s right sidebar appears only at desktop widths of 1024 pixels and above, so the clock does not consume space on phones. This is an intentional product decision rather than an unfinished responsive state. On a small screen, the article list and navigation are more important than a decorative time comparison.

Small Accessibility and Localization Details

Animated clock hands are not enough for assistive technology. Each dial therefore receives an updated accessible label containing its name, digital time, and time difference. The visible difference line is hidden from screen readers to avoid announcing the same information twice.

The labels and hour units come from the current Hugo language:

English: “Your time,” “My time,” “hour,” and “hours”;
Simplified Chinese: “你的时间,” “我的时间,” and “小时.”

Time calculations deliberately use Latin digits and a Gregorian calendar internally. Presentation text remains localized without making the numeric parsing dependent on a browser’s display language.

The main lesson was that a good widget needs boundaries more than it needs features.

I removed the title, personal name, country label, and mobile version. I separated website theming from day-and-night dial logic. I let the browser handle time-zone rules, while keeping the analog drawing in simple CSS and geometry.

The result is intentionally narrow: two clocks, one comparison, and no controls. That restraint is what lets it feel like part of the homepage instead of a miniature app competing with the rest of the site.

Small interface components are often where design and engineering meet most directly. Every extra label, timer, color rule, and breakpoint has an immediate visual consequence. Building this clock was a useful reminder that polish usually comes not from adding more, but from deciding what the component can leave out.

Why Chinese Text Falls Back to a Serif Font in Safari

Wed, 22 Jul 2026 11:00:00 +0200

This post explains a common Safari typography problem for developers and designers: a page is intended to use a clean sans-serif style, but some Chinese text unexpectedly appears in a serif font.

To readers who use Chinese every day, the change is immediately visible. It is roughly comparable to a navigation label suddenly switching from a modern sans-serif face to Times New Roman. The text remains readable, but it no longer belongs to the surrounding interface.

Figure 1: The intended result—the Chinese interface text uses the sans-serif PingFang family.

Figure 2: The fallback problem—parts of the same interface unexpectedly use the serif Songti family.

If You Read Chinese and Just Want to Fix Safari

You do not need to understand the CSS or change any website code. The project provides one ready-to-use stylesheet:

Download the complete safari-fix.css.
Open Safari Settings and select Advanced.
Choose the downloaded file from the Style sheet menu.
Quit Safari completely with Command+Q, then reopen it.

If you later want to disable the fix, return to the same menu and select None Selected. It does not install a font, modify macOS, or require a Safari extension.

Figure 3: Select safari-fix.css from Safari Settings → Advanced → Style sheet.

The rest of this article explains the underlying problem and how developers can prevent it on their own websites.

The Short Explanation

Many sites begin their font stack with Arial, Helvetica, Inter, Roboto, or another Latin typeface. These fonts can render English letters and numbers, but they may not contain Chinese characters.

When the browser reaches a character that the selected font cannot draw, it must find another font. This is font fallback. If the remaining stack does not name a suitable Chinese sans-serif font, Safari may choose a Chinese serif font instead.

That is why a line can contain perfectly normal English alongside Chinese text that looks as though it came from a different design system. Chrome and Safari may also choose different fallback fonts for the same CSS, so testing only one browser can hide the problem.

Start with a Better Font Stack

If the design is meant to be sans-serif, say so for both Latin and Chinese text. A practical stack for a multilingual interface might look like this:

body {
    font-family:
        Inter,
        -apple-system,
        BlinkMacSystemFont,
        "PingFang SC",
        "Hiragino Sans GB",
        "Microsoft YaHei",
        sans-serif;
}

The exact order depends on the product and supported platforms, but the intention should be clear:

keep the preferred Latin or brand typeface first;
include an appropriate Chinese sans-serif family;
include a suitable Windows alternative when Windows is supported;
end with the generic sans-serif family.

Avoid placing SimSun, Songti SC, or another Chinese serif face inside a stack that is otherwise intended to be sans-serif. Those fonts can be excellent choices for editorial reading, literature, or a deliberately serif design. They are simply the wrong fallback for a sans-serif interface.

If the design intentionally uses a Chinese serif font, declare that choice explicitly rather than relying on whichever fallback the browser happens to find.

Do Not Solve It by Overriding Every Font

A frequently shared workaround applies PingFang to every element:

1
2
3

* {
    font-family: "PingFang SC" !important;
}

This removes the visible serif fallback, but it also removes much of the site’s typography.

It can replace icon fonts, change monospace code, alter Latin headings, override component-specific styles, and erase intentional serif typography. In other words, it fixes one fallback decision by taking all font decisions away from the page.

A safer solution should change only the missing Chinese glyphs while leaving Latin text, numbers, icons, code, and deliberate serif choices alone.

A Targeted Fallback Rule

The core technique used by this project is an @font-face rule with unicode-range. The following shortened example tells Safari to use PingFang only for the listed Chinese character ranges when a page requests Arial:

@font-face {
    font-family: "Arial";
    src: local("PingFangSC-Regular");
    unicode-range: U+3000-303F, U+3400-4DBF,
        U+4E00-9FFF, U+F900-FAFF, U+FF00-FFEF;
}

Latin characters still come from Arial. Chinese characters that Arial cannot provide come from PingFang. The page therefore keeps its existing Latin metrics and visual identity while gaining a predictable Chinese sans-serif fallback.

The complete project also covers bold text, Traditional Chinese, extended character ranges, common Latin font names, and Windows Chinese font names. The snippet above is only an explanation, not the full stylesheet.

You can review or download the maintained file here:

If the project fixes the problem for you, consider giving it a Star on GitHub. It helps other Safari users and web developers find the solution.

A User Fix and a Website Fix Are Different

When you do not control the affected websites, the downloadable Safari stylesheet is a practical compatibility layer. For a site you maintain, correcting the site’s own font stack is preferable because every visitor benefits without installing anything.

What Designers Should Check

CJK typography should be part of design review, not left entirely to the browser.

A useful review does not require every team member to read Chinese. Check the visible form of the text:

Does Chinese body text use a serif or sans-serif style that matches the design?
Do navigation labels and buttons look consistent with nearby Latin text?
Do regular and bold Chinese text have a clear but stable weight difference?
Are punctuation, brackets, and full-width symbols visually consistent?
Does the design still work when a single line mixes Chinese, English, and numbers?

Chinese characters are visually dense, so differences in weight and spacing can be more obvious than expected. A Latin-only mock-up is not enough to validate a multilingual interface.

What Developers Should Test

Use actual Chinese content in browser testing. A few translated menu labels are more useful than placeholder boxes or repeated sample characters.

At minimum, test:

Safari and Chrome on macOS;
normal and bold text;
headings, navigation, buttons, form controls, and code blocks;
Simplified and Traditional Chinese when both are supported;
mixed Chinese, English, numbers, and punctuation;
the production build after web fonts finish loading.

In browser developer tools, inspect the font that actually renders the Chinese glyphs, not only the computed font-family declaration. The computed stack may say Arial or Inter even though a different local font supplied the Chinese characters.

Also test web-font failure. A blocked, slow, or partially loaded font should fall back to a typeface from the same broad category rather than unexpectedly switching from sans-serif to serif.

Privacy and Limitations

The project is CSS only. It contains no JavaScript, analytics, telemetry, or access to browsing history.

As a Safari user stylesheet, it cannot reliably change text drawn into images or canvas elements, and some embedded or isolated components may not inherit its rules. No generic stylesheet can perfectly infer whether every serif choice was intentional, which is another reason the website’s own font stack remains the best place to solve the problem.

The Broader Lesson

sans-serif is a design category, not a guarantee that every writing system will receive the expected local font. A multilingual font stack should describe the intended result for the scripts the product actually supports.

For Chinese interfaces, the essential principle is simple: pair a Latin sans-serif design with an explicit Chinese sans-serif fallback, preserve deliberate serif typography, and test the rendered fonts in the browsers your users rely on.