barryvan

Footnotes _are_ great when done right, but I have to say that inline citations are incredibly frustrating as a reader, because they're harder to skip over. A footnote marker is small enough that your eye can continue over it, whereas a citation like (Just-OK 2020) is much harder to read.

My personal preference is to use footnotes as you suggest -- as a "here's more information for the curious" option -- whereas citations should be linked to a "references" section -- either at the end of the chapter or the book or the overall article.

This seems to be a mixture of the "collections" feature from Firefox Mobile (Beta/Preview) and Firefox's container tabs, but without the security / isolation benefits.

From what I can tell, the main benefit seems to be in relation to identifying similar-looking tabs. It's unfortunate that they didn't bake in the same security and isolation benefits of Firefox's container tabs, or the "put aside and come back to it later" functionality that (old) Edge and Firefox Mobile's "collections" bring.

I'm also not sure how adding _more_ to the tabstrip will improve utility in Chrome, where tabs so quickly become impossible to manage because the strip doesn't scroll.

It does! https://blog.mozilla.org/firefox/no-notifications/

School timetabling is one of those areas which can become a rabbit-hole very quickly. Here in Australia, at least, you have to contend with student subject preferences -- so you end up having constraints around, for example, the number of teachers qualified to teach French at different levels, and the number of students who would like to do French (at different levels of preference and proficiency) and then generate classes.

Then you can also start adding in geographic information -- things like optimising classroom allocations not only for equipment but also for student and teacher transit times between sessions, and for accessibility for specific students and teachers.

And then you have to consider the quality-of-life characteristics of the timetables you generate -- for example, ensuring that a 0.8FTE teacher doesn't have a day where they come in for two sessions only, one first thing in the morning and one last thing in the afternoon.

Oh, and you need to ensure that students get the right number of minutes of instructions for each subject, accounting for exceptional days (like sports carnivals and assemblies) and public holidays. And it'd be good to keep students together a bit, but also mix them up between classes so that they socialise across the whole year level.

There are so many more constraints that can be added over time, with differing levels of importance and significance, that the problem space rapidly becomes huge. That's probably why there are only a handful of players in the market (at least here in Australia).

I suspect that it's because Firefox makes extensive use of "private" Apple APIs to be able to efficiently render on the platform, and Apple doesn't allow such uses for apps distributed through the app store. Similar issues apply to electron apps: https://news.ycombinator.com/item?id=21437255

The correct way to prevent this would be to constrain the input and validate it on output -- so that users cannot enter anything that's not a hex value, and Slack won't send back anything that's not a hex value in the theme. Even limiting the length of the input (and output) would mitigate the issue to some extent...

Developer edition definitely gets regular updates, fwiw.

They are! Around five years ago I wrote a CSS minifier (creatively called CSSMin, available on GitHub, and still in use at the company I work for) which rewrote the CSS to optimise gzip compression. Although it never really took off, I think that some of the lessons from it have been rolled into some of the more modern CSS optimisation tools.

> Downgrading the prompt to a non-popup icon in the address bar unless it follows a user action sounds like the perfect balance.

Agreed. If it's in direct response to a user action (a sync response to a click or a tap on an element smaller than 300x300px, for example), I think it's perhaps more legitimate to have a more visible indication, like a strip across the top. (I'd want the element size constrained to avoid issues with sites adding `onClick` handlers to the `<body>` element or similar.)

> Actually I think it makes sense to persistently show the notification icon in the navbar once the permission has been granted (same with mic, audio, and anything else) providing a quick glance at any privs that have been granted and an obvious way to revoke them.

I believe Firefox already does this. It also shows you privileges which you've explicitly denied -- for example, if you disallow location access, you'll see a slashed compass next to the (i) button in the Awesomebar.

When does an e-reader stop being an e-reader and become an e-ink display tablet? This sounds interesting, but more for the activities it enables in addition to and apart from reading.

This is where something like CSS Modules comes into its own. You can have (nearly) absolute confidence that what's in the CSS file colocated with the component is only used by that component. Sure, there are escape hatches like `:global(...)`, but those should be considered a code smell.

The beauty of CSS modules over a convention-based approach like BEM is that you end up with cleaner, simpler CSS files -- with selectors like `.Widget .search.error` rather than `.Widget__search--error`. The downside is that there's a compilation step, but chances are that you already have _some_ sort of compilation going on -- even if just to bundle things up.

The way to handle "special" cases for buttons -- like when they appear in certain contexts -- is to allow the calling code to add a class to the button; a class which comes from the caller's own CSS module. Alternatively, use CSS variables:

Button.css

  .Button {
    background: var(--btn-background, turquoise);
    color: var(--btn-foreground, octarine);
  }

Nav.css

  .Nav {
    --btn-background: fuchsia;
    --btn-foreground: lime;
  }

> Between men having spent some amount of effort and energy actively pushing women out, and marketing decisions having had some influence on creating gendered stereotypes, and those stereotypes having had some impact on diminishing appeal of the field to women, and workplace sexism, hostility and unfair treatment having had some deterring effects against women, and society-wide labor practice changes having some influence on women’s presence in the workforce overall, we have a very cumulative picture in the aggregate that explains the status quo for women in computer science.

This seems to me to be the key point in the post: there's no one reason that we can point to that would explain how we got to where we are. (I would suggest that trying to find that one reason is, in fact, counter-productive.) This being the case, I don't believe there can be any one way of "fixing" this -- the large change has to happen as a result of many smaller changes, including in hiring practices, standards of behaviour in the workplace, and in schools, colleges, and universities.

In other words, that small change that you can make that you don't think will make a big difference? It can.

The Tasmanian parliament is considering exactly this -- banning smoking for anyone born after 2000.

Ran into the same issue today. I'm really surprised that Apple went down this path, as I can only imagine the havoc that it will have wreaked across the web. I know that it's caused some serious issues in our app.

I'm also wondering why this change wasn't announced to developers by Apple more clearly -- I can't find any mention of it in the release notes. [1]

[1] https://developer.apple.com/library/ios/#releasenotes/Genera...