Content deleted Content added
Cobaltcigs (talk | contribs) tweak |
Cobaltcigs (talk | contribs) clarify opinion on wikt links |
||
Line 42:
===Comments===
* I'm not convinced the "Notes" section at the bottom is worth the space it takes up, and I only added it as a proof-of-concept gesture to mimic existing layout convention. A collapsible (show/hide, just like the section above) section at the bottom with an additional list/table of character info (one per line) would certainly be feasible and only require a few more lines of code. Its hugeness of screen space would be the primary concern, because its expansion would displace other page content possibly including wrapped text or floating images (unlike navboxes, which occupy 100% width at the very bottom).
* One intuitive solution would be to mimic typical charmap program behavior by using a Javascript click handler on each character cell that populates the footer area (of about the same size as the "Notes" section, maybe slightly smaller) with the cursor-selectable name of the last clicked-upon codepoint, plus its <code>&escapecode;</code> and any additional info we care to pull from [[Module:Unicode data]] (replacing any previous content). I could whip up a demo for that in the next few days. I just worry that it might be [[WP:CLICKHERE|too interactive]] to be widely accepted.
* A third approach might be to render the entire list (of names and whatnot) in a vertically scrollable footer panel containing "section" links, such that clicking on the character cell would cause the footer to scroll to and highlight (similar behavior to reflist anchors) the appropriate line. This might be [[WP:SCROLL|even less popular]].
* On the other hand, some philosophies may have changed over the years. I mean, we do have [[:mw:Help:Extension:Kartographer|interactive scrolling maps that pop up in a fullscreen div]] now (see [[RM 2222|example]]).
* I haven't formed any opinion yet on how to handle combining character positioning, other than "oh god, I hope it's something other than <code>&nbsp;</code>" lol.
*:Personally I prefer NBSP as the base for combining characters as dotted circle (which we currently use) often interferes with the character. [[User:BabelStone|BabelStone]] ([[User talk:BabelStone|talk]]) 11:33, 10 September 2019 (UTC)
―[[special:contributions/cobaltcigs|cobaltcigs]] 17:55, 9 September 2019 (UTC)
Line 62:
== Existing charts ==
Interesting approach to create the Unicode code charts dynamically but I have many questions. Most only apply if this module is intended to replace the existing chart templates...
# What problem is this new approach solving? Is it just duplicating/replacing the existing templates? If not, what will this module be used for?
Line 92 ⟶ 91:
*9 and 10. Each of the display-aliased characters in the templates you mentioned returns false for the [[Module:Unicode data]] function <code>.is_printable(n)</code>, except for U+0020 SPACE and U+00A0 NO-BREAK SPACE, which return true for <code>.is_whitespace(n)</code>. So both of these traits can easily be tested. Choosing the replacement alias we want would require maintaining a list of same. I'm not sure a printable space character should be aliased in this manner. Maybe it the cell background should be a different color with a footnote explaining yes, a whitespace character is there, and yes, you can copy it and paste it elsewhere. Also not sure "XXX" is appropriate for U+0080–0081. Maybe we want to display "PAD" and "HOP" instead?
*11. The existing chart for Javanese shows up with a cell height of 80px which seems excessive for the apparent line height of 33px [https://i.imgur.com/z0fgysQ.png on my screen]. Preview of module output for Javanese [https://i.imgur.com/EVWG2xM.png looks fine]. Better in my opinion. Maybe I just don't have the right fonts installed. But yes, cell height/width params can be added if there's a demonstrated need for this. Otherwise the browser should be trusted to stretch cells for large characters as needed. See "Also 6" above.
*12. I think if they are going to be linked, they shouldn't be piped to something else unless the character itself an [[mw:Manual:$wgLegalTitleChars|illegal title char]] and even then it shouldn't be linked to anything other than a title that paraphrases said character (e.g. <code><nowiki>[[Number sign|#]]</nowiki></code>). Making [[≅]] a disambiguation page (then piping the link to a more specific topic because linking to disambiguation pages is bad) was a mistake in my opinion. And nothing on
*12, continued. If the character title is a redirect to some other page (such as a list of emojis, or an article about the subject represented by some symbol), that's fine. Someday the character itself might become a separate article, which is also fine. The template need not know or care about that. I'm thinking a list of link aliases for bad-title chars (mapping <code>'#'</code> to <code>Number sign</code> and so on) would be a good solution. But only if we're going to be linking the characters at all, which is unclear. *13. I did keep the optional start/end parameters, because I figured subdivision would be wanted in some blocks for reasons including hugeness. Note that these need not be multiples of 16. The module will pad leftover cells accordingly with <code><nowiki><td class="excluded"></nowiki></code> which is currently styled the same as <code>class="reserved"</code> but this can be changed.
*14 and 15. If the unicode block display names can't be made to exactly match the [[Module:Unicode data/blocks|"official" names]] in all cases, we'll need a (hopefully short) list of aliases. Adding a blocknamelink parameter which continues to default to <code>Blockname (Unicode chart)</code> if empty would be easy and sufficient. Let's try to avoid having three sets of names wherever possible.
| |||