# Han.css: tags stopped at v3.2.7 and the documentation stopped in 2016

> A Sass, Stylus and JavaScript typography framework for Chinese and Japanese web typography, published as four differently named packages. The interesting parts are all bookkeeping: a tag history that stops below the version the code and the docs claim, a test command that needs a browser nobody ships any more, and documentation split across two hosts over plain HTTP.

**ethantw/Han** — 「漢字標準格式」印刷品般的漢字排版框架 Han.css: the CSS typography framework optimised for Hanzi.

- Repository: https://github.com/ethantw/Han
- Website: https://hanzi.pro/
- Stars: 2,527 · Forks: 132
- Language: JavaScript
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/ethantw-han

## The newest tag is v3.2.7 while the package and the README both say 3.3.0

Three version statements sit in this repository and they do not agree.

The package manifest declares version `3.3.0`. The footer of the documentation states the release as v3.3.0, and every CDN path in the install instructions is pinned to `3.3.0`. The tags say otherwise: v3.2.5 on 2015-06-29, v3.2.6 on 2015-08-21, v3.2.7 on 2015-10-26, and nothing after that.

So the released history tops out below the version everything else refers to. Anyone resolving a dependency by tag gets 3.2.7 at best; anyone resolving `han-css` from npm gets whatever the manifest says, which is 3.3.0. Those are different code bases by the repository's own numbering.

The second date is stranger. The documentation footer records the page as last modified on 2016-03-19 in UTC+8, while the most recent push to the repository is 2026-09-06. A decade of commits have landed without moving the line that says when the instructions were last touched. The documentation is a snapshot, and the release tags below it stopped ten years before the last push.

## Three install commands, four names, and the Rails route is a third party's gem

The installation section gives three commands:

```bash
npm install --save han-css
bower install --save Han
gem install 'hanzi-rails'
```

Those three lines use three different package names, and none of them matches the repository name exactly in case. The npm package is `han-css`, lowercase with a suffix. The Bower package is `Han`, capitalised, and the root of the tree carries a `bower.json` to match it. The gem is `hanzi-rails`.

The Rails entry is the one to look at twice. Its link goes to `github.com/billy3321/hanzi-rails`, a different account from the repository's own owner. So the third installation route is not maintained here; it is a third-party wrapper that this project points at. The manifest records the author as Chen Yijun with the handle `@ethantw`, so the naming drift spans the Ruby route as well.

Bower is the tell that this documentation predates the current package managers. A `bower.json` at the root and a `carthage`-style registry entry are both ecosystem markers that have since faded, which tells you how the install matrix should be read.

## The CDN route is frozen at 3.3.0 and the customization route is the real one

There are two ways in, and the documentation makes the choice explicit. If you do not need special customization, you can link the CDN version of the stylesheet, the script and the web fonts, compiled with default values, for fast download and caching. That service is provided by cdnjs.com. The links are protocol relative and version pinned:

```html
<link rel="stylesheet" media="all" href="//cdnjs.cloudflare.com/ajax/libs/Han/3.3.0/han.min.css">
```

```html
<script src="//cdnjs.cloudflare.com/ajax/libs/Han/3.3.0/han.min.js"></script>
```

The web fonts follow the same pattern, with a WOFF file at `font/han.woff` and an OTF file at `font/han.otf`, both under the same `3.3.0` path.

The other route is the one the project actually wants you on. The customization section says the framework offers multiple customization features, available through variable settings and module imports, with the details in a manual. Every tree root file supports that route separately: `index.scss` for Sass, `index.styl` for Stylus, `index.js` for JavaScript. So a Sass or Stylus consumer never touches the compiled file, and a CDN consumer is explicitly the case where you accept the defaults.

## han-init on the html element is the switch that turns the JavaScript on

The usage section is three steps and the order matters. First, reference the compiled `han.min.css` before all other stylesheets on the page, or import it through Sass or Stylus. Before, not after: this is a normalization baseline, and a cascade that loads it late cannot do its job.

Second, include `han.min.js` as needed and add the class `han-init` to the `<html>` element tag to enable DOM-ready rendering. That class is the entire opt-in. The script does not run on page load by itself.

Third, or customize the rendering as needed, with details in the manual.

The framework presents the script as optional by design rather than as an afterthought. It claims low coupling and a high degree of semantic naming, with the stylesheet and the script each doing their own job and very little dependence on each other, plus multi-level style fallback. That combination is what makes the CSS-only path viable, and it is why `han-init` is a class rather than a configuration flag: you decide per page whether the script earns its place.

## The browser matrix pins two versions and says latest for everything else

Seven entries make up the browser support list: Chrome at the latest version, Edge at the latest version, Firefox at the latest version, Firefox ESR+, Internet Explorer 11, Opera at the latest version, and Safari 9.

Five of those say nothing about a version. They are written as the latest version, which is a statement about your own browser rather than about the framework, and it means the list carries no information for a reader trying to work out whether their users are covered. Two entries do carry a floor: Internet Explorer 11 and Safari 9.

Those two are the informative rows, and both point the same way. Internet Explorer 11 places the lower bound at the last Microsoft browser engine, and Safari 9 places it at the release where Apple changed some of the web platform defaults the framework depends on. Reading a list that mixes named minimums with unversioned rolling entries as a support policy is a mistake; the two pinned rows are the only part with a date attached.

The list also predates the versions of the package it describes, since it sits in documentation whose last-modified stamp is 2016-03-19.

## The manual, the API reference and the FAQ live on two hosts over plain HTTP

The documentation is spread across more origins than a single project needs, and the split is not obvious from the page itself.

The homepage is `https://hanzi.pro/`. The Sass customization API reference is `http://hanzi.pro/manual/sass-api`. The JavaScript rendering reference is on a different host entirely, `http://css.hanzi.co/manual/js-api`, with a rendering anchor on it. The frequently asked questions are also on that second host, at `http://css.hanzi.co/manual/faq`, with separate anchors for stylesheet overriding and for the runtime environment of `han.js`.

So `hanzi.pro` and `css.hanzi.co` both serve the manual, split between the stylesheet side and the script side, and both are referenced over plain HTTP rather than HTTPS. The homepage is the only one written with a scheme. A demo page is published separately on `ethantw.github.io` at the `latest` path rather than at a version number, which means that example tracks the default branch instead of any release.

The practical consequence is that this page is a hub with four outbound destinations, two of them insecure by URL and one of them unpinned by version.

One more detail about the page itself. The default document in this repository is written in Chinese, and the header of it offers two alternatives by link: `README-en.md` and `README-ja.md`, both of which sit at the top level of the tree alongside `README.md`. So the three documentation languages exist as three files rather than as one document with a language switcher, and the version stamp and installation matrix described above belong to the Chinese one.

## The gulpfile is LiveScript and the test target runs PhantomJS

The development requirements are Node.js and LiveScript 1.4.0, installed globally with `sudo npm install -g livescript`. The build file at the root is `gulpfile.ls`, which is LiveScript rather than JavaScript, matching the `.jshintrc` sitting beside it for the JavaScript sources.

Five commands cover the work. `sudo npm install` installs the development modules, `npm start` or `gulp dev` starts the development environment including local running and automatic compilation, `gulp build` compiles the distributable files, `gulp test` tests the `han.js` API, and `sudo npm update && gulp dep` updates the dependency modules. The manifest wraps three of them as npm scripts, so `npm test` runs `gulp test` and `npm start` runs `gulp dev`.

Two details decide whether you can run any of it. The test target is annotated as PhantomJS, and the dev dependencies pull in qunitjs for the assertions, so the suite needs a headless browser that current Node toolchains no longer bundle. And the gulp version pinned is `^3.9.0`, the last major release of that task runner before the Node version it targeted. The manifest declares a floor rather than a ceiling, at node `>= 0.12`.

The runtime dependencies, by contrast, are small: `fibre.js` and `normalize.css`.

## Conclusion

Han.css is worth a look if you are typesetting mixed Chinese and Latin web text and want a baseline you can override, and there is still value in the compiled han.min.css on its own. Before you depend on it, check the version you actually get. The npm package reports 3.3.0 while the newest tag is v3.2.7 from 2015, and the README itself carries a last-modified stamp of 2016-03-19, so treat the documented browser matrix as a historical record rather than a support statement. If you need to build it, budget for the toolchain: the gulpfile is LiveScript and the test target runs PhantomJS.

## FAQ

### How do I install Han.css?

Three documented commands: npm install --save han-css for the npm package, bower install --save Han for the Bower package, and gem install 'hanzi-rails' for Rails. The npm and Bower names differ in case and suffix from the repository name, and the Rails gem link points at a separate account rather than this repository.

### Which version of Han.css am I actually installing?

It depends on how you resolve it. The package manifest declares version 3.3.0 and the documentation and CDN paths all reference 3.3.0, but the newest repository tag is v3.2.7 from 2015-10-26. A dependency resolved by tag stops below the version the rest of the project refers to.

### What does han-init do in Han.css?

It is the opt-in for the JavaScript. You include han.min.js as needed and add the class han-init to the html element tag to enable DOM-ready rendering. The stylesheet and the script are deliberately low coupling with multi-level style fallback, so the script is optional and the stylesheet alone is a supported path.

### Does Han.css support Traditional Chinese, Simplified Chinese and Japanese?

Yes, all three of the writing systems that use Hanzi are stated as fully supported. The framework ships WOFF and OTF web fonts, with han.woff and han.otf served from the same version-pinned CDN path as the stylesheet and script. It is built as a Sass, Stylus and JavaScript framework.

### What does it take to build Han.css from source?

Node.js plus LiveScript 1.4.0 installed globally, since the build file is gulpfile.ls. Commands are sudo npm install, npm start or gulp dev for the development environment, gulp build for the distributable files, gulp test for the han.js API, and sudo npm update && gulp dep to update modules. The test target runs on PhantomJS.

## Sources

- [ethantw/Han on GitHub](https://github.com/ethantw/Han)
- [License: MIT](https://github.com/ethantw/Han/blob/master/LICENSE)
- [Project website](https://hanzi.pro/)
- [README](https://github.com/ethantw/Han/blob/master/README.md)
- [Releases](https://github.com/ethantw/Han/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ethantw-han