161–170 of 194 posts
Earlier quoted context omitted.
Firefox and Safari already made similar changes. Safari made the exact same change, and Firefox hides http:// already, but not https:// , chrome is just using a lock icon to represent the https:// instead of the actual string.
As mentioned, at least this setting can be disabled in Firefox. (I don't know if this is possible in Chrome.)
This is a giant AMP scam. The next change will be that it will trick users into thinking they are on are on a real site like example.com but will instead be on Google.com/example.com. But chrome will remove google.com just like http/s.
Signed HTTP exchanges. It was actually the main complaint about AMP because it caused confusion among users. Technically it makes no difference wether the content is hosted by the author or any AMP CDN. The question is more a philosophical one. If it’s wrong that the URL doesn’t point to where files are “actually” stored. Or rather that the package delivery and package creator aren’t the same party. In my mind this h…
The issue is deceit and fraud. A browser should _never_ ever under any circumstances be able to display one companies domain differently than all others. Especially when it's their domain.
Google.com, or any of Alphabet's domains, should not get special preference or treatment. And they certainly should not be trimmed out of an address for the benefit of Alphabet/Google to the detriment of all others.
I don't understand why you have to click twice to show this info. That's just bizarre.
Only issue I have with this is it removes a bit of useful information when I'm asking users for screenshots when reporting errors on websites!
It's a pretty trivial issue that has sat around for a while. While I run Firefox, I would normally distinguish what version of the site a user is on by the green lock.
While http does show a "Not secure" segment next to the URL, everything just shows as black and white in dark mode, making it harder to distinguish at a glance.
Earlier quoted context omitted.
And requires you to jump through non-obvious hoops to make "hidden" files and folders visible.
And now ~/Library is invisible by default, so that's yet another thing I have to fix on any new installation.
"As a ____, I want to get users to our []-controlled version of our site, without alerting the user aware they are on our []-controlled version of our site."
So in this sense there are points for filling it. It's still the correct domain, so this is quite a niche user story.
Earlier quoted context omitted.
Given the implementations I've seen of file metadata outside of the extension I'm okay with this - every time OSes (especially windows) tries to strip away the extension it ends up switching the file type from being a description of "what am I" to "what can open me", I really dislike "what can open me" especially when we get into a lot of common office work file formats. Knowing the difference between .rtf, .txt, .do…
Agreed. Apple's pre-OSX metadata system was two pieces: "What am I" and "Who created me." This was an amazingly flexible system that just worked and was the best of both worlds.
Earlier quoted context omitted.
It's not the picture that broke, it's not the user that is dumb, but the system that is broken. Dot extensions is a concept that should never have seen the light of the 21st century. Or at least it should be a last resort for the system to guess the file format for those formats that don't have magic numbers in their headers or for lesser known formats.
Or more generally the header should contain the metadata of the file: date modified, filetype, comments, icon, etc, rather than spreading that between the filesystem (with different filesystems having inconsistent dates), the OS, etc.
shadow files (._*) and directory clutter (.DS_Store/desktop.ini) are one solution, but they're ugly and frustrating, having separate areas in the filestore (like a resource fork, but designed to be ephemeral) are a much more sane solution.
Earlier quoted context omitted.
Given the implementations I've seen of file metadata outside of the extension I'm okay with this - every time OSes (especially windows) tries to strip away the extension it ends up switching the file type from being a description of "what am I" to "what can open me", I really dislike "what can open me" especially when we get into a lot of common office work file formats. Knowing the difference between .rtf, .txt, .do…
Agreed. Apple's pre-OSX metadata system was two pieces: "What am I" and "Who created me." This was an amazingly flexible system that just worked and was the best of both worlds.
That's fine, not every task that is possible must be directly supported by the OS - third party apps to fiddle with data that is considered non-primary workflow like that is OK.