I think that PWA should have the ability to override the default
beforeunloadEvent message.
Since returning string is already deprecated and removed from all browsers,
it would be safe to change how the returned value is handeled.
All proposed changes should only apply to installed PWAs!
This should able to be done via two nested WakMap,
First level would be the function and the second the context or vice versa.
This should be able to give you the same bound function while both are
avaible, but should clear itself once the reference to function/context is
lost.
--
Back when async/await was introduced I struggeled quite a bit with promises
arrays that have conditional promises. RxJS is moving from array only
support in theirs operators to objects too, there seems to be an actual
trend going on. Is there any reason
The point is not how to write assertions, but how to replace implementation
of `compoteGraph` with some other that would return something else for sake
of testing only one module instead of all deeply dependant modules.
I suppose that the user gesture might be solvable by starting browser with
> If gather the requirement correctly you can substitute utilizing
> `console.assert()` shipped with the browser for a third-party library.
Yet MDN says:
> Writes an error message to the console if the assertion is false. If the
> assertion is true, nothing happens.
I am not sure, but
About video try reloading the page and doing `video.play()`, it will reject,
as the event is not trusted. ___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Assuming code like this:
```
import { compoteGraph } from './compute-graph';
export function doTheMath() {
// Elaborate work to gather parameters for `computeGraph`.
const param1 = 1;
const param2 = 'a';
const param3 = 'A';
return computeGraph(param1, param2, param3);
}
```
As we are looking into the bright future when we will have native module
support, but how will we test it then? As of now the only way to mock any
module function, classes or other exports are by way of exploiting the fact
that webpack (or similar) is in the middle.
Things to think about:
-
If you want to have native scrolling experience for `` you need to
either implement your own scrolling behaviour, or you will create `` of
size much bigger than screen, that way it overflows screen and shows scollbars,
but then you must only render on part of canvas as most is hidden.
I would
I mean, that there should be an API that would say, how an element would
scroll, if it was in place of for example a ``.
```
const scrollArea = new ScrollArea(canvasElement, {
borderBox: 'unlimited', // Default would be the element
//viewPort: '100#200'
});
Hello everyone. I think browsers should expose the native scroll as API.
Possible uses:
* Native-like scroll in canvas apps (games) - Google's Proxx
(https://proxx.app/) had to do quite a bit of magic to have native scroll for a
game.
* Camera controls for touch device (3D model preview)
This new notation will enable you a new way to create functions
`.map(...)` produces `(parameter) => parameter.map(...)`, it is not
evaluated, it is a function definition
I cannot say I like it. To me it is less readable, confusing to be exact.
Anything leading with `.` (dot), seems
12 matches
Mail list logo
