ytugiuyghvk

No, but there are several reasons it is suboptimal here.

The lookupbar is associated with the window chrome (ie. there is one per window). Inserting it into the DOM requires emulating this behavior by synthesizing one "bar" in each tab, adding and deleting them at the right time, etc.

Inserted content always has the possibility of interacting poorly with the scripts and styles of the underlying page (or other extensions). Rikai-chan already has problems where its overlays will end of underneath page content.

Inserted content goes below the line of death (https://textslashplain.com/2017/01/14/the-line-of-death/). There are other minor deficiencies: you can't get the browser's theme on the bar, etc.

For Rikai-chan, it seems like it'd be nice to allow the background script to write to a page that sits on top of the space that shows the actual page and have the content scripts communicate what should be rendered. AFAIK, the only ways to show something on the screen is to either send it to the content scripts and have them modify the DOMs, or show it in a popup for a button.

Same here. Is the Lookupbar (Alt+Del) possible to do with WebExtensions? I think it would have to be recreated in the DOM and inserted into the web page.

Nit: self-closing refers to tags that are closed like <this/>.

Related reading re. Vulkan

"What a WebGL2 successor could look like and why it can’t be WebVulkan" - https://floooh.github.io/2016/08/13/webgl-next.html

See also the the author's sketch of a next-gen web graphics API on top of WebGL (https://floooh.github.io/2016/10/24/altai.html) which is (perhaps unsurprisingl) broadly similar to the sketch given the article (minus command queues, shader libraries, ...).

What a waste of time.

class = X is just an anonymous template type parameter with default value X, just like

    auto foo(int = 0);

declares a function with a int parameter with default value 0. In this case, it's just a conventional place to stick an expression in the declaration to trigger SFINAE. If you don't need SFINAE, you can also just place the condition in a static_assert in the definition

    template <class T>
    auto foo(T&&) {
        static_assert(!is_reference<T>::value, "call me with an r-value");
        ...
    }

If you want to template on an r-value reference, the easiest way is probably to use a forwarding reference and disable the template if the template parameter deduces to a reference

    template <class T, class = enable_if_t<!is_reference<T>::value>>
    auto f(T&& x);

What's wrong with C++'s closures?

b.clone(), of course, derefs b as well.

Why ask that B: Copy instead of B: Clone?

Every type system eliminates all its own type errors by definition. Even the trivial system with one type eliminates all its own type errors (vacuously, since there are zero of them).

There is no universal set of errors called type errors. What are type errors depend on your type system. A good type system allows more errors to be encoded as type errors so you can catch them at compile time, but it doesn't mean anything to say that a language like Rust or Haskell eliminates all type errors. There are certainly type systems which could catch more errors.