Saying that Chinese people are okay, and are not necessarily represented by the actions of the Chinese state, isn't about anything more than trying to prevent violence and hate from being targeted towards ethically East Asian-looking people. There is precedence for this kind of violence, and if we're angry at China for human rights abuses, we should not breed an environment in which the human rights of Chinese people are put at risk in other countries.
Built-in Windows controls, like buttons, scroll bars, etc. are updated with each system release. However, they are relatively inflexible, and no one uses WinApi anyway, so most frameworks and apps build their own components, with varying dedication to emulating the "native" style. Built-in controls also don't perform much in the way of layout (I believe the only way to position child HWNDs remains manual absolute positions?) so while your button might look native, your collection of two buttons won't.
My guess is MacOS's consistency comes from some combination of developer incentives, and UI toolkit design.
> I believe the only way to position child HWNDs remains manual absolute positions? so while your button might look native, your collection of two buttons won't.
I thought the native APIs provided some kinds of constraints, like ‘these go into corners, and this is next to that’? Such approach is sorta necessary when windows can be resized. And I thought that UI builders like Visual Basic depended on these constraints. However I didn't do much manual UI, so perhaps the programmer indeed has to recalculate everything in pixels when something moves or is resized—like we did back in the day before we knew better.
Which is the "native" API - win32, MFC/ATL, Form builder, WPF, or MAUI? If you're dealing with HWNDs directly, it's either win32 or MFC/ATL, but those haven't been touched in tens of years in favor of the current .NET APIs.
It displays for me, in place of the favicon (but I'm on nightly, so this might be a more recent change). Here's what it looks like for me: https://imgur.com/a/EwaKsNt
Sure, but not all people who use computers are programmers, and programmers make up a small minority of computer users. Much of the value in computers come from augmenting other workloads. There are no shortage of people composing e-mails and documents, or consuming content, in non-English languages. Probably more than there are fluent English users.
I have an app installed that essentially draws over the entire view to darken the screen, while all interactions pass through transparently. It can't draw over certain areas, like some popups and the notification bar, but most of that wouldn't matter for malicious interactions.
Well, good news! I don't know when this might've changed (I have animations enabled), but I just tested it on Windows 10 2004, and the start menu doesn't animate with animations off.
Firefox, in contrast, breaks at script boundaries, so it'll select runs of Hiragana, Katakana, and Kanji. Not nearly as useful, and definitely makes copying Japanese text especially annoying.
Personally I find double click highlighting to be a useless feature in any language, but the Firefox approach is superior imo. Breaking at script boundaries is predictable behavior the user can anticipate whereas doing some janky ad hoc natural language processing invariably results in behavior that is essentially random from a user perspective. I tried out double click highlighting on some basic Japanese sentences on Chromium and it failed to highlight any of what would be considered words.
It's not like English highlighting does complex grammatical analysis to make sure "Project Manager" gets highlighted as one chunk and "eventUpdate" gets highlighted as two chunks, most implementations just breaks at spaces like the user expects.
I use double-click highlighting, and the reason is mostly selecting passages of text when editing. Double-click highlighting makes it so I don't have to find the precise character boundaries for the first and last words in the passage. Instead, I can just double click the first word, roughly move my mouse to hover over the last, and copy or delete that entire passage.
Firefox's approach is fairly useless in this regard. Even if it's predictable from a technical perspective, it's not predictable for a reader who naturally processes semantic breaks rather than technical ones. Unlike in English, where a space is both semantic and visual, hiragana-kanji boundaries often don't mean anything. As a result, for me at least, Firefox's breaks feel a lot more random than Chrome's, which, while dodgy, are often fine.
Having used Firefox as my main browser since 2006, I remember when I discovered this feature in Chrome, and being shocked at how much of an effect that minor improvement had for me. It's not a deal-breaker, certainly, but it's become my one big annoyance with Firefox.
I'm Japanese and I agree that Firefox behavior makes sense.
For example, a text with kanji like "その機能拡張は、", A word "機能拡張" consists of "機能" + "拡張" words.
In Chrome, double-click makes individual part (like 機能) selected which is rarely wanted behavior for me.
In Firefox, the whole word (機能拡張) is selected, which is wanted mostly.
It's pretty painless to select the next word though. It's best for the computer to err on the side of caution in this case.
[Edit: Ah, it might not be common knowledge but you can drag on the double click to select more words. You can also hold alt while editing text to jump words, and even combine alt+shift and alt+delete. Windows and Apple differ on the boundaries wrt whitespace, but I'm fairly sure they're both alt. Wordjumps while editing is an unappreciated superpower imo.]
I know drag after double click action but I don't use double click to select action for Japanese text and always select text by dragging because I prefer predictable operation.
I don't know Alt + Shift/Delete action, how is it useful?
I think all of this just highlights (hah) that the way we think of human-language strings needs to change. They're not a stream of characters, they're their own thing with complex semantic rules. They should be represented as an opaque blob only manipulated via an API or passed to an OS for rendering etc.
Machine-readable strings can still just be an ASCII byte array, but we need to keep the two separate.
I feel like this is a conclusion you could only reach by having an irrational compulsion to defend the deficiencies of Firefox, and not being a regular user of the Japanese language.
I don't use/speak Japanese, but the GP's conclusion makes complete sense to me.
Consistent behavior > inconsistent behavior, almost always. If I can anticipate what my computer is going to do, I can plan around it, even if it means a bit of extra manual work.
That doesn't work if the consistent behaviour is completely useless. If double click selected English tokens grouped by which half of the alphabet they came from, nobody would ever double click anything, they'd just click-drag highlight.
Spaces have zero importance to the Japanese language itself, but they are occasionally used like punctuation. e.g. some YouTube video titles will use spaces around names of things that could be hard to parse as not part of a sentence, another example is when you're typesetting phrases in lyrics.
In general, whitespace characters have no place or significance inside a Japanese sentence, and most of the whitespace in Japanese typesetting is built into punctuation marks.
Furthermore, even most punctuation is optional in Japanese. The full stop 。 and comma 、 are mostly a matter of preference, sometimes spaces are used in place of full stops or commas.
I actually like this behavior more, since it is predictable. Sometimes it just works for occasional looking up proper nouns, and you can already tell if it won't.
I think it depends on how engrained the double-click highlight is for you. For me, I double-click by default, since I almost always want to select at a word boundary in English. As a result, when I need to select Chinese or Japanese text, I'm always annoyed when my double click (which, in my mind, should always select a word) selects a nonsensical sub-sentence instead, and I have to then re-select it manually.
When you double-click, say, the word "double-click", do you expect to highlight either "double" or "click", depending on which part of the word I happened to click on? Or do you expect to highlight the entire compound? Does your expectation change when the phrase is written with spacing: "double click"? When written without spacing: "doubleclick"? Does your perception of the word boundaries change between these cases?
Now consider another anglophone arbitrarily; how likely does it seem to you that they would share the exact same set of expectations of the above with you? Because if they don't, then one of you is going to have their expectations violated.
Now give it a try: do the highlights match your expectations? (Moreover: are those expectations consistent with where you placed the word boundaries?)
If your expectations of what double-click highlight does for English is consistent with what actually happens when you double-click, it is deeply unlikely that the causality goes word boundary -> highlight expectation; if they do, it's more likely that double-click highlight has influenced your sense of word boundaries.
But it's even more likely that you your expectations of double-click highlight don't actually match up with your intuition for word boundaries, and you just have a pretty good model of how double-click highlight behaves independently of where you think the word boundaries are.
(The notion of word boundaries in this context is fraught anyway. Even setting aside the problem of compound words, the phonological word boundaries of Japanese don't match up with the lexicographical ones, in both directions.)
I agree, there's definitely flexibility in what I expect, and what other people will likely expect. Here's the thing though: when I double-click "double-click", I could reasonably expect "double" "click" or "double-click" would be selected. I wouldn't expect it to select everything between the last and next punctuation characters (as an imperfect analogy).
For me at least, double-clicking is like fuzzy string matching. It's an imprecise behaviour by nature, but should be designed to be useful. Firefox's behaviour in the case of Japanese, but especially Chinese, often isn't useful, not because it doesn't perfectly reflect linguistic expectations, but because it usually selects too much--meaning you can't correct your selection by moving the cursor back and forth, and instead, have to stop and select using a different method.
Take the following passage:
もうこんなことは終わってほしいと願うばかりだ
Different people may break apart もうこんなことは differently, but it's hard to argue that it's one word. Chrome (and Word) separate it like this: もう こんな こと は, and whether or not you agree that each one of those parts are words, simply splitting もうこんなことは into parts semi-logically makes it smoother to edit (for me, at least! I understand most people might not be as dependent on double-click selection).
The same behaviour for Chinese is so useless that it's not even worth mentioning, since you'll always select either a large part of a sentence, or an entire sentence at once. I mean, I love the word 匹配的近似度用如下方法来度量.
Side note, this already doesn't work if you don't have a Touchpad / Magic mouse. The normal workflow is Right Click ==> Look Up, but Firefox overrides macOS's normal right click menu. :(
Firfox is just not a very good macOS citizen, sadly.
Oh, there is that, but it's too far away to be useful.
If I could set up a custom keyboard shortcut for the service, it would work great—but support for custom keyboard shortcuts also doesn't work in macOS Firefox[1]! (Unless you set a combination which Firefox doesn't already use for something, and it already uses everything sensible, so you have to set something long and annoying.)
