Re:UI design for software developers. Part 1, Colors
by jessaustin on Wednesday November 18, 2020 @01:42PM
(#25140612)
That explanation seems to be having it both ways. If it's really a spoofing security risk, do they still intend to provide functionality that is sufficient for the original purpose?
Re:UI design for software developers. Part 1, Colors
by dragonwriter on Wednesday November 18, 2020 @03:13PM
(#25141826)
> If it's really a spoofing security risk, do they still intend to provide functionality that is sufficient for the original purpose?
The explanation explictly says that the original functionality was a spoofing security risk, but even so was “insufficient for their original purpose (making website elements look like their native OS counterparts)”. So, no, they've fairly explicitly abandoned the original purpose.
They retained functionality has a more limited purpose, which I would describe as providing a vehicle for the user/browser/OS to provide defaults which pages/apps can reference, which when provided by the OS, minimize aesthetic clash and preserve contrast/accessibility between the page/app features and native UI without disguising the nature of the web page/web app, rather than actually mimicing native system UI.
Re:UI design for software developers. Part 1, Colors
by userbinator on Wednesday November 18, 2020 @07:48PM
(#25144867)
For Internet webpages it makes sense, but for things like Electron apps, the security argument makes no sense since the whole point is that they should look like the native OS.
Earlier versions of CSS defined several additional system colors. These color keywords have been deprecated, however, as they are insufficient for their original purpose (making website elements look like their native OS counterparts), represent a security risk by making it easier for a webpage to “spoof” a native OS dialog, and increase fingerprinting surface, compromising user privacy.
https://www.w3.org/TR/css-color-4/#deprecated-system-colors