fidzu : firefox

<figcaption class="wp-element-caption">Credit: Nick Velazquez / Mozilla</figcaption>

Carlos Moreno is an activist, a graphic designer at CAP Tulsa and leads Tulsa's Code for America volunteer brigade. He has a master's degree in public policy and is the author of "The Victory of Greenwood" and "A Kids Book about the Tulsa Race Massacre." You can follow him on Twitter. Photo: Jamie Glisson

As the father of a teenager, I find myself worrying - and not just about their grades and how quickly they're growing up. Dating? Driver's permit? I'm not ready for this! I also worry about how my child, through the internet, is experiencing the world at a much quicker pace than I did.

When I was younger, I remember when the video of police brutally beating Rodney King surfaced. I watched the uprising that unfolded on the streets of Los Angeles on the news in real time. I was 15. That's six years after I, along with my classmates and teachers, watched the space shuttle Challenger unexpectedly explode on television. Both times, I didn't fully grasp what I'd just watched - my understanding came with help from my family and teachers and with time.

Now, with the web at their fingertips, children today are being exposed to a Challenger-level disaster in some part of the world in real time, every week it seems. I fear that without context and guidance to keep up with the internet news cycle, teens are becoming cynical, distrustful and isolated. So how can we, as parents, support and empower them to navigate it all?

'What good is marching in the streets or signing a petition going to do?'

Recently, I visited my teenage child's youth group at school and asked them how they're learning about the issues that affect them. I learned that most of the dozen high schoolers I spoke with were getting their information from social media accounts, like @mr_fish_news on TikTok's news fish. That, or they were too overwhelmed to care.

Through the internet, young people have access to information unlike any of the generations before them. But politically, my child feels completely helpless. "I don't have any power or money," they said. "The rich and powerful make all the decisions, so what good is marching in the streets or signing a petition going to do?"

I didn't have a good answer. Keep fighting? Try to avoid doomscrolling? Focus on taking care of those around you? It didn't seem like enough.

Learn from news literacy and advocacy organizations

Through my own work as an activist, I'm reminded that there are always organizations who can help. To learn how I can better talk to my kid about the news, I found the list of resources provided by Media Literacy Now to be a great starting point.

I also recommend contacting your local library to find out what digital media literacy workshops they might have. There's also Generation Citizen, which offers resources across the U.S. for what it calls "action civics," teaching a combination of media literacy and the inner-workings of local government.

In my community, the nonprofit Oklahoma Center for Community and Justice worked to create a safe space where young people in Tulsa can speak to each other after the 2020 protests prompted by George Floyd's murder.

Not only can families bring kids to these spaces to process difficult issues among their peers, but parents can also use all of these resources to educate themselves for having tough conversations about how what's happening in the world is affecting them.

How to talk to kids about the news (and getting involved)

In today's political and media climate, as amplified by the internet for better or worse, it's easy to feel distraught. It's a place I find myself more often than I care to admit both as a community advocate and a parent.

Still, there are great resources that are made more accessible by the internet - and parents don't need to figure things out alone. There are organizations that we can learn from and that are constantly working to help meet our children's needs. This is what gives me a bit of hope.

Here's what I've learned that can help you talk to kids about news events:

1. Ask them what they care about. Your kids will surprise you with what they're already discussing with their teachers and friends. Make time to talk about complicated issues they care about or that are relevant in their lives. Read a book, search for trustworthy articles online or watch an informative video, then try to understand it together.

2. Value their voice. The word "advocacy" means "giving voice." Listen to what your kids want to express. Ask what voices or perspectives are missing from the conversation. Together, explore the voices of those who are most affected by the issue you're discussing. The internet makes it easier to find connections. This is one way to use it for good.

3. Explore local resources together. Activism is about building power. Go online to find local avenues - a school board, town hall or city council meeting, where teenagers can learn about issues going on in their own community and where they can express their views. Help write emails to the editor of a local paper. Ask for meetings with local elected officials. Trust me, you'll be surprised that your family has more power than you think!

What we see and hear amid the constant online news cycle can be discouraging. But the internet also makes plenty of resources and guidance accessible, so that parents are equipped to have tough but empowering conversations with their kids.

The internet is a great place for families. It gives us new opportunities to discover the world, connect with others and just generally make our lives easier and more colorful. But it also comes with new challenges and complications for the people raising the next generations. Mozilla wants to help families make the best online decisions, whatever that looks like, with our latest series, The Tech Talk.

The post How to talk to kids about the news appeared first on The Mozilla Blog.

01 Feb 2023 7:20pm GMT

A key difference between the web and other platforms is that the web puts users in control: people are free to choose whichever browser best meets their needs, and use it with any website. This is interoperability: the ability to pick and choose components of a system as long as they adhere to common standards.

For Mozilla, interoperability based on standards is an essential element of what makes the web special and sets it apart from other, proprietary, platforms. Therefore it's no surprise that maintaining this is a key part of our vision for the web.

However, interoperability doesn't just happen. Even with precise and well-written standards it's possible for implementations to have bugs or other deviations from the agreed-upon behavior. There is also a tension between the desire to add new features to the platform, and the effort required to go back and fix deficiencies in already shipping features.

Interoperability gaps can result in sites behaving differently across browsers, which generally creates problems for everyone. When site authors notice the difference, they have to spend time and energy working around it. When they don't, users suffer the consequences. Therefore it's no surprise that authors consider cross-browser differences to be one of the most significant frustrations when developing sites.

Clearly this is a problem that needs to be addressed at the source. One of the ways we've tried to tackle this problem is via web-platform-tests. This is a shared testsuite for the web platform that everyone can contribute to. This is run in the Firefox CI system, as well as those of other vendors. Whenever Gecko engineers implement a new feature, the new tests they write are contributed back upstream so that they're available to everyone.

Having shared tests allows us to find out where platform implementations are different, and gives implementers a clear target to aim for. However, users' needs are large, and as a result, the web platform is large. That means that simply trying to fix every known test failure doesn't work: we need a way to prioritize and ensure that we strike a balance between fixing the most important bugs and shipping the most useful new features.

The Interop project is designed to help with this process, and enable vendors to focus their energies in the way that's most helpful to the long term health of the web. Starting in 2022, the Interop project is a collaboration between Apple, Bocoup, Google, Igalia, Microsoft and Mozilla (and open to any organization implementing the web platform) to set a public metric to measure improvements to interoperability on the web.

Interop 2022 showed significant improvements in the interoperability of multiple platform features, along with several cross-browser investigations that looked into complex, under-specified, areas of the platform where interoperability has been difficult to achieve. Building on this, we're pleased to announce Interop 2023, the next iteration of the Interop project.

Interop 2023

Like Interop 2022, Interop 2023 considers two kinds of platform improvement:

Focus areas cover parts of the platform where we already have a high quality specification and good test coverage in web-platform-tests. Therefore progress is measured by looking at the pass rate of those tests across implementations. "Active focus areas" are ones that contribute to this year's scores, whereas "inactive" focus areas are ones from previous years where we don't anticipate further improvement.

As well as calculating the test pass rate for each browser engine, we're also computing the "Interop" score: how many tests are passed by all of Gecko, WebKit and Blink. This reflects our goal not just to improve one browser, but to make sure features work reliably across all browsers.

Investigations are for areas where we know interoperability is lacking, but can't make progress just by passing existing tests. These could include legacy parts of the platform which shipped without a good specification or tests, or areas which are hard to test due to missing test infrastructure. Progress on these investigations is measured according to a set of mutually agreed goals.

Focus Areas

The complete list of focus areas can be seen in the Interop 2023 readme. This was the result of a consensus based process, with input from web authors, for example using the results of the State of CSS 2022 survey, and MDN "short surveys". That process means you can have confidence that all the participants are committed to meaningful improvements this year.

Rather than looking at all the focus areas in detail, I'll just call out some of the highlights.

CSS

Over the past several years CSS has added powerful new layout primitives - flexbox and grid, followed by subgrid - to allow sophisticated, easy to maintain, designs. These are features we've been driving & championing for many years, and which we were very pleased to see included in Interop 2022. They have been carried forward into Interop 2023, adding additional tests, reflecting the importance of ensuring that they're totally dependable across implementations.

As well as older features, Interop 2023 also contains some new additions to CSS. Based on feedback from web developers we know that two of these in particular are widely anticipated: Container Queries and parent selectors via :has(). Both of these features are currently being implemented in Gecko; Container Queries are already available to try in prerelease versions of Firefox, and is expected to be released in Firefox 110 later this month, whilst :has() is under active development. We believe that including these new features in Interop 2023 will help ensure that they're usable cross-browser as soon as they're shipped.

Web Apps

Several of the features included in Interop 2023 are those that extend and enhance the capability of the platform; either allowing authors to achieve things that were previously impossible, or improving the ergonomics of building web applications.

The Web Components focus area is about ergonomics; components allow people to create and share interactive elements that encapsulate their behavior and integrate into native platform APIs. This is especially important for larger web applications, and success depends on the implementations being rock solid across all browsers.

Offscreen Canvas and Web Codecs are focus areas which are really about extending the capabilities of the platform; allowing rich video and graphics experiences which have previously been difficult to implement efficiently using web technology.

Compatibility

Unlike the other focus areas, Web Compatibility isn't about a specific feature or specification. Instead the tests in this focus area have been written and selected on the basis of observed site breakage, for example from browser bug reports or via webcompat.com. The fact that these bugs are causing sites to break immediately makes them a very high priority for improving interoperability on the web.

Investigations

Unfortunately not all interoperability challenges can be simply defined in terms of a set of tests that need to be fixed. In some cases we need to do preliminary work to understand the problem, or to develop new infrastructure that will allow testing.

For 2023 we're going to concentrate on two areas in which we know that our current test infrastructure is insufficient: mobile platforms and accessibility APIs.

Mobile browsing interaction modes often create web development and interoperability challenges that don't occur on desktop. For example, the browser viewport is significantly more dynamic and complex on mobile, reflecting the limited screen size. Whilst browser vendors have ways to test their own mobile browsers, we lack shared infrastructure required to run mobile-specific tests in web-platform-tests and include the results in Interop metrics. The Mobile Testing investigation will look at plugging that gap.

Users who make use of assistive technology (e.g., screen readers) depend on parts of the platform that are currently difficult to test in a cross-browser fashion. The Accessibility Testing investigation aims to ensure that accessibility technologies are just as testable as other parts of the web technology stack and can be included in future rounds of Interop as focus areas.

Together these investigations reflect the importance of ensuring that the web works for everyone, irrespective of how they access it.

Dashboard

To follow progress on Inteop 2023, see the dashboard on wpt.fyi. This gives detailed scores for each focus area, as well as overall progress on Interop and the investigations.

Mozilla & Firefox

The Interop project is an important part of Mozilla's vision for a safe & open web where users are in control, and can use any browser on any device. Working with other vendors to focus efforts towards improving cross-browser interoperability is a big part of making that vision a reality. We also know how important it is to lead through our products, and look forward to bringing these improvements to Firefox and into the hands of users.

Partner Announcements

• Apple - Pushing Interop Forward in 2023
• Bocoup - Interop 2023 Update
• Google - Interop 2023
• Igalia - Interop 2023
• Microsoft - Microsoft Edge and Interop 2023

The post Announcing Interop 2023 appeared first on Mozilla Hacks - the Web developer blog.

01 Feb 2023 5:02pm GMT

Nightly Rust now has support for async functions in traits, so long as you limit yourself to static dispatch. That's super exciting! And yet, for many users, this support won't yet meet their needs. One of the problems we need to resolve is how users can conveniently specify when they need an async function to return a Send future. This post covers some of the background on send futures, why we don't want to adopt the solution from the async_trait crate for the language, and the general direction we would like to go. Follow-up posts will dive into specific solutions.

Why do we care about Send bounds?

Let's look at an example. Suppose I have an async trait for performs some kind of periodic health check on a given server:

trait HealthCheck {
    async fn check(&mut self, server: &Server) -> bool;
}

Now suppose we want to write a function that, given a HealthCheck, starts a parallel task that runs that check every second, logging failures. This might look like so:

fn start_health_check<H>(health_check: H, server: Server)
where
    H: HealthCheck + Send + 'static,
{
    tokio::spawn(async move {
        while health_check.check(&server).await {
            tokio::time::sleep(Duration::from_secs(1)).await;
        }
        emit_failure_log(&server).await;
    });
}

So far so good! So what happens if we try to compile this? You can try it yourself if you use the async_fn_in_trait feature gate, you should see a compilation error like so:

error: future cannot be sent between threads safely
   --> src/lib.rs:15:18
    |
15  |       tokio::spawn(async move {
    |  __________________^
16  | |         while health_check.check(&server).await {
17  | |             tokio::time::sleep(Duration::from_secs(1)).await;
18  | |         }
19  | |         emit_failure_log(&server).await;
20  | |     });
    | |_____^ future created by async block is not `Send`
    |
    = help: within `[async block@src/lib.rs:15:18: 20:6]`, the trait `Send` is not implemented for `impl Future<Output = bool>`

The error is saying that the future for our task cannot be sent between threads. But why not? After all, the health_check value is both Send and 'static, so we know that health_check is safe to send it over to the new thread. But the problem lies elsewhere. The error has an attached note that points it out to us:

note: future is not `Send` as it awaits another future which is not `Send`
   --> src/lib.rs:16:15
    |
16  |         while health_check.check(&server).await {
    |               ^^^^^^^^^^^^^^^^^^^^^^^^^^^ await occurs here

The problem is that the call to check is going to return a future, and that future is not known to be Send. To see this more clearly, let's desugar the HealthCheck trait slightly:

trait HealthCheck {
    // async fn check(&mut self, server: &Server) -> bool;
    fn check(&mut self, server: &Server) -> impl Future<Output = bool>;
                                           // ^ Problem is here! This returns a future, but not necessarily a `Send` future.
}

The problem is that check returns an impl Future, but the trait doesn't say whether this future is Send or not. The compiler therefore sees that our task is going to be awaiting a future, but that future might not be sendable between threads.

What does the async-trait crate do?

Interestingly, if you rewrite the above example to use the async_trait crate, it compiles. What's going on here? The answer is that the async_trait proc macro uses a different desugaring. Instead of creating a trait that yields -> impl Future, it creates a trait that returns a Pin<Box<dyn Future + Send>>. This means that the future can be sent between threads; it also means that the trait is dyn-safe.

This is a good answer for the async-trait crate, but it's not a good answer for a core language construct as it loses key flexibility. We want to support async in single-threaded executors, where the Send bound is irrelevant, and we also to support async in no-std applications, where Box isn't available. Moreover, we want to have key interop traits (e.g., Read) that can be used for all three of those applications at the same time. An approach like the used in async-trait cannot support a trait that works for all three of those applications at once.

How would we like to solve this?

Instead of having the trait specify whether the returned future is Send (or boxed, for that matter), our preferred solution is to have the start_health_check function declare that it requires check to return a sendable future. Remember that health_check already included a where clause specifying that the type H was sendable across threads:

fn start_health_check<H>(health_check: H, server: Server)
where
    H: HealthCheck + Send + 'static,
    // -----  ^^^^^^^^^^^^^^ "sendable to another disconnected thread"
    //     |
    // Implements the `HealthCheck` trait

Right now, this where clause says two independent things:

• H implements HealthCheck;
• values of type H can be sent to an independent task, which is really a combination of two things
  • type H can be sent between threads (H: Send)
  • type H contains no references to the current stack (H: 'static)

What we want is to add syntax to specify an additional condition:

• H implements HealthCheck and its check method returns a Send future

In other words, we don't want just any type that implements HealthCheck. We specifically want a type that implements HealthCheck and returns a Send future.

Note the contrast to the desugaring approach used in the async_trait crate: in that approach, we changed what it means to implement HealthCheck to always require a sendable future. In this approach, we allow the trait to be used in both ways, but allow the function to say when it needs sendability or not.

The approach of "let the function specify what it needs" is very in-line with Rust. In fact, the existing where-clause demonstrates the same pattern. We don't say that implementing HealthCheck implies that H is Send, rather we say that the trait can be implemented by any type, but allow the function to specify that H must be both HealthCheck and Send.

Next post: Let's talk syntax

I'm going to leave you on a cliffhanger. This blog post setup the problem we are trying to solve: for traits with async functions, we need some kind of syntax for declaring that you want an implementation that returns Send futures, and not just any implementation. In the next set of posts, I'll walk through our proposed solution to this, and some of the other approaches we've considered and rejected.

Appendix: Why does the returned future have to be send anyway?

Some of you may wonder why it matters that the future returned is not Send. After all, the only thing we are actually sending between threads is health_check - the future is being created on the new thread itself, when we call check. It is a bit surprising, but this is actually highlighting an area where async tasks are different from threads (and where we might consider future language extensions).

Async is intended to support a number of different task models:

• Single-threaded: all tasks run in the same OS thread. This is a great choice for embedded systems, or systems where you have lightweight processes (e.g., Fuchsia¹).
• Work-dealing, sometimes called thread-per-core: tasks run in multiple threads, but once a task starts in a thread, it never moves again.
• Work-stealing: tasks start in one thread, but can migrate between OS threads while they execute.

Tokio's spawn function supports the final mode (work-stealing). The key point here is that the future can move between threads at any await point. This means that it's possible for the future to be moved between threads while awaiting the future returned by check. Therefore, any data in this future must be Send.

This might be surprising. After all, the most common example of non-send data is something like a (non-atomic) Rc. It would be fine to create an Rc within one async task and then move that task to another thread, so long as the task is paused at the point of move. But there are other non-Send types that wouldn't work so well. For example, you might make a type that relies on thread-local storage; such a type would not be Send because it's only safe to use it on the thread in which it was created. If that type were moved between threads, the system could break.

In the future, it might be useful to separate out types like Rc from other Send types. The distinguishing characteristic is that Rc can be moved between threads so long as all possible aliases are also moved at the same time. Other types are really tied to a specific thread. There's no example in the stdlib that comes to mind, but it seems like a valid pattern for Rust today that I would like to continue supporting. I'm not sure yet the right way to think about that!

01 Feb 2023 1:06pm GMT