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.)
"From the very inception, we had a vision to fix a lot of the issues with hardware, starting by getting Mono (the open-source runtime that powers Xamarin) running on a microcontroller in order to bring a modern runtime to the class of computing that powers real IoT."
I'm going to argue that, while the .NET environment may be unfamiliar, it's as good (if not better!) than the NodeJS environment for "getting stuff done." You may have fewer libraries (depending on what you're looking for), but with .NET Standard 2, you need fewer of them. The standard library has support for everything from Memory Mapped Files [0], to Parallel loops [1], every collection type under the sun [2], globalisation [3], and HTTP applications [4].
Memory management is just as automatic as well (they seem to just be using the mono runtime).
And bringing it back to small embedded systems, there are some really nice plugins for VS that let you stay in that familiar environment. I am so much more productive with Visual Studio and the VisualMicro and Visual GDB plugins than I would be in the respective "native" IDEs.
> But if Latin-style scripts are so much easier to input into computers, and if computers are not just the wave of the future but the present as well
But the hard part isn't supporting _a_ script, it's supporting _all_ scripts (or at least, all relevant scripts, in our modern interconnected age). It's only moderately more complicated, even with existing latin-centric tools, to only support a single script. Heck, If you only support Chinese + Japanese for example: you can always assume monospacing, which makes layout a breeze; line-wrapping rules are extremely simple [0]; and word-breaking (and associated headaches, like hyphenation and inter-word spacing) is practically a non-factor.
I can speak a little on Chinese and Japanese. In neither of these countries, English (or sometimes even Latin) literacy is high enough to replace the domestic language. (And anyway, maybe it's just me, but reading romanized Chinese or Japanese is exhausting.)
With China, the market's so big that there's an entire ecosystem of homegrown (or Chinese-modified) software and websites, everything from office suites to web browsers, and I have to imagine those support Chinese input just fine.
With Japanese, generally the same software and sites are used, but Japanese support is also pretty good across common software.
Some niche or open source software struggle with IMEs in general, but in those cases, the solution is just to not use that software.
UWP is hardly consistent. Just as a quick example, the context menu in the start menu is slightly different from the context menu for the task bar, which are both very different from the context menu(s!) which appear in the Windows Mail app. Or how the context menu in the start menu can exit the bounds of the start menu, but most popups/menus in UWP apps are fully bound to their parents.
What's being withdrawn is their original CUI, linked in the article [0]. From what I can tell, this is very distinct from their new digital service manual, which seems to be replacing the old CUI.
> ...but this would need to be either extended or abstracted to be applicable to, say, administrative systems.
Based on nothing more than a rough skim of the CUI, admittedly, it seems like the original was a very web/interface-oriented design system in the first place. A focus on web components makes sense, since administrative systems can be implemented with a web-based frontend, and web design systems can be adapted to other user interfaces, because they provide a set of baseline, expected behaviours to replicate.
And for anyone who isn't familiar with (what I would consider) the most important difference in this use-case: borders affect the positioning of other elements, whereas outlines do not. You don't want to be using a temporary border, since it can significantly affect the layout of your site when you remove it.
Borders still affect the positioning of things even with box-sizing set to border-box. For example, here "Block 1" is still two pixels taller than "Block 2":
Does that really matter though? A difference of 2px for something temporary doesn't seem like much concern. While I understand the implication is that these can accumulate and cause larger layout issues, the purpose of this practice is to highlight those areas to remove that accumulation anyway
When I'm coding DIV layouts by hand, I temporarily assign each DIV with a random background-color. Once I have the layout and responsiveness required, I strip the background-color setting on each DIV as I fill them up with content. Works for me.
