It should be right-aligned so that the timestamp and status is visible against a light background. But it’s left-aligned due to a bug.

So, the article was right?

Not all of them are enjoyable when played on a small touchscreen, so the question is still relevant: which ones actually work well for the form factor?

They can also request location info and other things on a website, and people also just need to click Allow.

They can also use push notification on websites, and for both websites and apps you have to agree to a system prompt first to allow it to happen.

So that’s not the reason.

deleted by creator

Probably nothing because he owns Geico, it’s just self-promotion

I think “20 minutes ago” is a lot more useful than seeing the full date on every comment and having to do mental math. It does make it harder to see the precise date, but that’s a far less common use case, so the tradeoff goes towards making it more usable for the more common scenario. So I see that as the reason: it’s usually better. The full date is still available on hover, which seems reasonable to me.

I disagree with your premise that web developers “want to make it hard”, as that isn’t the motivation. The motivation is to make it easy to see when a comment was posted, which is far more useful as relative time. That it makes it harder to copy the full date is not the goal, but an unfortunate side-effect of the tooltip disappearing when you stop hovering over the relative time. Which I’m sure you could submit as an issue to the lemmy devs, because likely it just never came up, and isn’t some evil plot to “make it hard on purpose”.

Looking into git commits, the unselectable property was added by @dessalines@lemmy.ml, so maybe we can get an answer right from the source instead of guessing?

It’s interesting you say they “obscure it”, where in your example they went out of their way to make it possible to see the precise date and time when you hover over the relative time. They could easily not add the tooltip and yet they did.

Why is it not selectable? My guess is that most people would want to select the content of the comment but accidentally also select the time since it’s very close to it, so to make it easier to select just the content, they made the time unselectable. It’s a tradeoff but helps in more cases than it harms. Just a guess though.

Forget a crash, it saves you from hitting your head on the ceiling when the plane encounters turbulence and suddenly drops 10 meters and everything not held down goes flying inside.

I think you are talking about website hosting, which has nothing to do with my offline images. I have nothing to do with websites.

But if you are talking about using it for publishing, some time ago I published a mobile app that shows an offline map for some mountain trails. All the map tiles were originally PNG and took 900MB, but I got them to 50MB as WebP tiles. That’s quite a reduction, nobody would download a 900MB app!

I use webp a lot, it’s smaller than PNG for lossless images like screenshots and smaller than JPG for lossy while working for both. All the image editors and image viewers I use support it, so it’s not inconvenient for me in any way.

Also Portable Network Graphics, as the name suggests, is a network image format, not a digital image format. Just having a laugh : )

what if somewhere else in the code

Then you’d need to do something else.

the semantical and resourcewise equivalent would be a third variable

So you are advocating for:

data class Filters(
    val isAdmin: Boolean = false,
    val filterByAdmin: Boolean = false,
    val isConfirmed: Boolean = false,
    val filterByConfirmed: Boolean = false,
)

fun filterUsers(users: List<User>, filters: Filters): List<User> {
    return users
        .filter { !filters.filterByAdmin || it.isAdmin == filters.isAdmin }
        .filter { !filters.filterByConfirmed || it.isConfirmed == filters.isConfirmed }
}

fun getAdmins() {
    val users = getUsers()
    val filters = Filters(isAdmin = true, filterByAdmin = true)
    val admins = filterUsers(users, filters)
    println("Admins: $admins")
}

Over:

data class Filters(
    val isAdmin: Boolean? = null,
    val isConfirmed: Boolean? = null,
)

fun filterUsers(users: List<User>, filters: Filters): List<User> {
    return users
        .filter { filters.isAdmin == null || it.isAdmin == filters.isAdmin }
        .filter { filters.isConfirmed == null || it.isConfirmed == filters.isConfirmed }
}

fun getAdmins() {
    val users = getUsers()
    val filters = Filters(isAdmin = true)
    val admins = filterUsers(users, filters)
    println("Admins: $admins")
}

To me, Filters(isAdmin = true) is a very easy to use API, where Filters(isAdmin = true, filterByAdmin = true), with the additional variable to avoid nullable booleans, is more verbose, for not much benefit and brings ambiguity. What if someone writes Filters(isAdmin = true), but forgets they need to set filterByAdmin = true for it to actually work? Easy mistake to make. We can prevent these mistakes by removing default values so they have to be specified on the call site, but then you need Filters(isAdmin = true, filterByAdmin = true, isConfirmed = false, filterByConfirmed = false), which is very verbose. Having two variables also allows your systems to get into invalid states:

isAdmin = true, adminRightsHaveBeenValidated = false isAdmin = true, filterByAdmin = false

What do these mean? It’s better for invalid states to be unrepresentable. Since these states are mutually exclusive, we should have only 3 states, not 4 which you get with 2 booleans. Which you could achieve with an enum True, False, None, but then you are just reinventing the wheel of nulls. You also get the issue that now you have to remember to always update both variables together.

It all comes back to your point:

it’d be idiomatic and reasonable to assume it to be false if we have no data

You want to have ambiguous states, where a single value represents both “we have no data” and “we have the data, the answer is no”.

It is not more accurate nor less wasteful. If you default it to false and you have 100 admin requests in the session where that variable is stored, you would have to check with the database 100 times. Because you are conflating false to mean two things: “the user is not an admin” and “we don’t know if the user is an admin”. Where if you set it to true or false the first time we need the information, then subsequent requests don’t need to check anymore.

does not have to worry about nulls

I am used to null safe languages where there is no such thing as worrying about nulls, because not checking for null on a nullable type is a compile error, and so it’s impossible to forget about the null case. Maybe it’s why I don’t see any issue with using them.

Let’s say you have a website receiving 1 million requests per day. 0.01% of those are admin requests that need to know if your are an admin to execute them. It would be wasteful to check with the database if you are an admin for every request, when only a tiny minority of then needs to know that. So for 999.900 of the requests isAdmin will be null. We don’t know if the user is an admin and we don’t need to know.

Depends on your requirements.

If the admin status needs to be checked in a database, but most actions don’t require authentication at all, it’s pointless to waste resources checking and it would be left null until the first action that needs the information checks it and fills it in as true or false.

So in a language with nullable types, are you against a boolean ever being nullable? Null means “empty, missing info”. Let’s say we have role variable with a enum type of possible roles. It could still reasonably be nullable, because in some scenarios you don’t know the role yet, like before log in.

In any use case where we need to store some boolean, it’s a common occurrence that we don’t have the data and it’s null. It would be overkill to use an enum with True, False, NoData for these cases, where there is already a language feature made just for that, nullable values.

I’ve never used TypeScript, just writing from experience in other languages.

This is quite reasonable, aside from the variable name which should be isAdmin. A user either is an admin, or isn’t. Unless we don’t know, then it’s null. You are correct this is bad if the point was to represent roles, but it’s not supposed to.

I use an extension that replaces YouTube comments with Reddit comments, if the video was posted anywhere on Reddit.

Would be nice to have a Lemmy version.