User talk:ChristTrekker/UnicodeSymbol: Difference between revisions

Revision as of 17:48, 12 December 2012

Revision as of 23:29, 12 December 2012

Line 1:

==My comments==

Allow me to write in telegraph style.

* '''Concept''': good plan to use specialised font selections per Unicode character group (whichever group that is). Good to aim for a single complete template that covers all.

::Commons.css encoders (those who have to enter and maintain the font set per class) might not be happy with:

::-Non-stable groups, class-names and asp font-sets. IOW: they [class-names and font-sets] should work well in most/all of the browsers, they should not change too often (any more), and they shouolldshould not be too many especially if they can be correctly grouped (e.g., when some different groups can share a font set). Also the number of classes can become an issue (it could grow to 100 or 200).

* User input (editors input): use {{cose|1=#switch}} to its best: it allows many inputs. Still ambiguous input should give a warning.

* Class naming: I suggest to use all lc and use underscore "_" to suggest a space character. So that would be "unicode_emoticon" not "UnicodeEmoticon". I think the prefix "unicode_" is fine, maybe a shorter one can be found.

::-When it applies, use the proper formal ''[[Unicode block]] name'' or the ''[[Template:ISO_15924_script_codes_and_Unicode|Unicode script name]]'' [http://www.unicode.org/charts/ or via]. These are well defined. If there is such a name, there is no need to introduce a new name.

::-If block or script name does not covertcover the characger set ("card suits", "ipa"), first look if Unicode does use a subsection title in a block. ""card suits" is not a block name, but is ''is'' a section title in b;lockblock "Miscellaneous symbols" [http://www.unicode.org/charts/PDF/U2600.pdf]. So then nammename the class "unicode_card_suits".

::-If that not covers it, find a good short descriptive name. (I wouldn't use abbreviations like "PoliReli" or "poli_reli"). Remember you have to convince high level editors who do not like/need more jargon.

*'''The process''' of introducing the classes. Now this is a more difficult part. It is nigh impossible to get the font set right first time, let alone for 100 or 200 classes. Unless you found a commons.css editor who will enter you first proposal of ~100 classes with preferred font sets ;-). I suggest you contact the class editors by now, ask what and what not they can implement.

::-''My'' appproachapproach was (at least, in theory) is to first use subtemplates per fontset (your class name) that has the fonts written down. Using {{code|1=<span style="font-family:...>"}} (minor start in {{tl|script}}, with Cyrl example). These can be edited, tested, and when stable turned into a class. One by one.

*Another thought: naming the classes is overseeable. Another issue can arise when character sets are to be combined (into one class). We definitely do not want knots in the future. I have no solution for this.

*Of course the class should have the fallback font(s) too, and maybe somnesome generic ones like for diacritics ("common script").

*Question for commons.css editors (maybe you are): how does the "lang" affect this? I have the impression that browsers (HTML, CSS) try to wringe a font (-family) out of a language. That would turn the table upside down.