Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-values] should ic unit use 永 instead of 水? #2798

Closed
heycam opened this issue Jun 20, 2018 · 3 comments
Closed

[css-values] should ic unit use 永 instead of 水? #2798

heycam opened this issue Jun 20, 2018 · 3 comments
Labels
Closed Rejected as Wontfix by CSSWG Resolution Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. css-values-4 Current Work

Comments

@heycam
Copy link
Contributor

heycam commented Jun 20, 2018

https://drafts.csswg.org/css-values-4/#ic

A minor issue, but I wonder if the ic unit should use the advance of the 永 glyph instead of 水? To me 永 feels like it's closer to the idea of a representative Chinese character.

https://en.wikipedia.org/wiki/Eight_Principles_of_Yong

But I'd be interested to know if there was a particular reason for choosing 水.

@heycam heycam added the css-values-4 Current Work label Jun 20, 2018
@frivoal
Copy link
Collaborator

frivoal commented Jun 20, 2018

Good point. I think switching is reasonable. In the vast majority of fonts, it should not make any difference, and 永 is indeed more iconic.

I think 水 was picked as a character that's common (so that it would be in every font) and that did not differ based on the language. 永 should fit that bill too.

@myakura
Copy link
Contributor

myakura commented Jun 20, 2018

Writing Modes uses 水 as well (used when scaling down the tate-chu-yoko to 1em). If switching to 永, I kinda want to see two specs refer to the same character.

@css-meeting-bot
Copy link
Member

The Working Group just discussed ic unit character basis, and agreed to the following:

  • RESOLVED: closing this issue as no-change
The full IRC log of that discussion <fantasai> Topic: ic unit character basis
<fantasai> github: https://github.com//issues/2798
<frremy> astearns: who want to take the IC unit issue?
<frremy> heycam: I don't think it's super important because IC isn't implemented yet
<frremy> florian: not in any browser, but maybe some epub/print impl
<frremy> heycam: the glyph should be chinese as I understand
<frremy> heycam: I propose the Yuan "eternity" character is more common than the one currently used
<frremy> heycam: so I proposed to switch to this instead of the "water" char
<frremy> fantasai: why not, but we also need to change writing mode
<frremy> fantasai: we just need to make sure it is always full-width, and common to all cjk fonts
<frremy> myles: how many fonts that support both of these chars support different advances for them?
<frremy> florian: that should be excessively rare
<frremy> myles: then I am fine with this
<frremy> ??: I don't think this will be a compat issue
<frremy> fantasai: I agree there should be no compat
<astearns> s/??/xidorn
<myles> s/then I am fine with this/I understand./
<frremy> fantasai: could be make one version of writing mode do one char, then the next one switch to the other?
<dbaron> the unicode codepoints for these characters differ by 4, fwiw :-)
<frremy> no
<frremy> heycam: I am fine leaving the char as is
<frremy> myles: is it gonna be likely to have a font that supports one vs the other?
<frremy> heycam: not if you dont artificially limit
<frremy> florian: for newspaper, you could have a few glyphs just for the name of the newspaper
<frremy> florian: but any font for a normal text would include both
<frremy> RESOLVED: closing this issue as no-change
<frremy> fantasai: (largely for process reason, changing writing-modes is too much pain)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Closed Rejected as Wontfix by CSSWG Resolution Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. css-values-4 Current Work
Projects
None yet
Development

No branches or pull requests

6 participants