Re: [csswg-drafts] [css-fonts] The Cursive = Chinese Kaiti equivalent (#4606)

The CSS Working Group just discussed `The Cursive = Chinese Kaiti equivalent`.

<details><summary>The full IRC log of that discussion</summary>
&lt;stantonm> topic: The Cursive = Chinese Kaiti equivalent<br>
&lt;astearns> github: https://github.com/w3c/csswg-drafts/issues/4606<br>
&lt;stantonm> chris: first had these thoughts in CSS2, said cursive matched cyrillic (?)<br>
&lt;stantonm> ... how similar is kaiti to cursive<br>
&lt;stantonm> ... would like to see more comments from people who read chinese<br>
&lt;stantonm> myles: can we ask i18n<br>
&lt;stantonm> chris: we should reference clreq<br>
&lt;stantonm> fantasai: usage of kaiti is similar to how english uses italics, not really cursive<br>
&lt;stantonm> ... switching to cursive english font in middle of kaiti feels inappropriate<br>
&lt;stantonm> heycam: see kaiti in childrens books<br>
&lt;stantonm> fantasai: something like comic sans<br>
&lt;stantonm> ... not fully connected writing<br>
&lt;stantonm> florian: mapping english words like cursive doesn't always make sense in other language<br>
&lt;stantonm> ... inconsistent mapping<br>
&lt;stantonm> chris: we don't provide typography for free, better to use font-family name<br>
&lt;stantonm> ... if you want something specific say something specific<br>
&lt;stantonm> fantasai: high-level switching can be nice, distinguish paragraphs<br>
&lt;stantonm> fantasai: think we do need some kind of syntax<br>
&lt;stantonm> florian: should not map all keywords we have to other language<br>
&lt;stantonm> ... how far do we need to go? not sure<br>
&lt;stantonm> astearns: we should ask clreq for this issue<br>
&lt;stantonm> florian: what do we want to ask<br>
&lt;stantonm> astearns: do we need a keyword for kaiti, or can it map to existing keywords<br>
&lt;stantonm> chris: followed spec in good faith, people may need to back things out if we change<br>
&lt;stantonm> s/authors followed/followed/<br>
&lt;dbaron> q+ to comment on whether data indicating which category a font falls in exists in the font or the OS<br>
&lt;chris> s/people/browser implementers/<br>
&lt;stantonm> myles: valuable for us to have criteria on when to add new generic font keywords<br>
&lt;stantonm> astearns: open page on wiki for requirements of new keywords<br>
&lt;stantonm> dbaron: it's useful to have that in the spec, fine to have non-normative explaining why the spec is this way<br>
&lt;Zakim> dbaron, you wanted to comment on whether data indicating which category a font falls in exists in the font or the OS<br>
&lt;stantonm> hober: lets people know how to change it if they see it in spec<br>
&lt;stantonm> astearns: put in wiki as scratch space<br>
&lt;stantonm> dbaron: can we extract metadata from fonts to help derive these keywords<br>
&lt;stantonm> myles: most existing generic font families fail that test<br>
&lt;stantonm> jfkthame: in theory panose should word, but in pratice usually not there<br>
&lt;stantonm> s/word/work/<br>
&lt;fantasai> s/word/work/<br>
&lt;stantonm> myles: some criteria for naming, needs to map to more than just one font file<br>
&lt;stantonm> ... useful for installed fonts, OS's need to have installed fonts that match<br>
&lt;stantonm> ... other criteria is that at least two OS support a font for that generic<br>
&lt;stantonm> chris: not always helpful in underrepresented languages<br>
&lt;stantonm> astearns: but we already resolved to do work on that front<br>
&lt;stantonm> fantasai: so then it's with appropriate language pack installed<br>
&lt;fantasai> for some appropriate definition of language pack<br>
&lt;stantonm> myles: computers don't know, browser dev needs to manually type in list<br>
&lt;Zakim> fantasai, you wanted to say that the threshold is, are typographers regularly using a distinction in font stylistic groupings to make a semantic distinction in their publications<br>
&lt;stantonm> fantasai: threshold should be whether typographers in typical publications are using distinctions between different groups of fonts<br>
&lt;stantonm> ... example is italic vs normal vs bold in latin<br>
&lt;stantonm> ... sans-serif, serif, monospace makes a semantic distinction<br>
&lt;stantonm> dbaron: does serif/sans-serif meet that criteria<br>
&lt;stantonm> hober: good to come up with criteria, stuck with the ones we already have<br>
&lt;stantonm> ... new criteria should just work going forward, may not fit existing perfectly<br>
&lt;stantonm> fantasai: there are stylistic distinctions sometimes, but can also be semantic in many others<br>
&lt;stantonm> florian: criteria is useful for prioritizing, but hard to say yes/no<br>
&lt;stantonm> florian: if we don't meet criteria we shouldn't add, if we meet it we *may* add<br>
&lt;fantasai> it's a sufficient but not necessary criteria<br>
&lt;stantonm> s/florian/fantasai<br>
&lt;fantasai> s/if we don't meet criteria we shouldn't add, if we meet it we *may* add/if we meet the criteria, should add; if we don't, we may add/<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4606#issuecomment-577736282 using your GitHub account

Received on Thursday, 23 January 2020 15:38:58 UTC