4 ms·

Apple would certainly benefit from more transparency in these matters, no question. Decoupling Safari updates from OS updates and better communication/tracking

by ribit 4y ago

Apple would certainly benefit from more transparency in these matters, no question. Decoupling Safari updates from OS updates and better communication/tracking of issues and release dates would be a big help At the same time, I don't really see why they should aim to replicate other browser bugs or be responsible for author's idiosyncratic assumptions regarding feature availability. It's a shame that browsers don't have to undergo strict compliance tests and that JavaScript is generally pretty much awful. Under these circumstances the most popular browser (Chrome) is taken as a gold standard and that can't be good for the open web.

AshleysBrain 4y ago
Is it idiosyncratic to assume that two variants of the canvas API support the same things?
- bzzzt 4y ago
  Considering it's a big API with dozens of methods I'd be surprised if two implementations would agree exactly.
  - AshleysBrain 4y ago
    I would have assumed browsers had one internal implementation and exposed it through both APIs. They wouldn't want to have two separate implementations of a large amount of complex code.
- cxr 4y ago
  Yes, and it's a little reckless to even get to a state where, even in the presence of bonafide bugs re non-standard behavior, just showing "a blank screen" when your app dies is a possibility. Add some basic error detection/reporting.
  - AshleysBrain 4y ago
    We did have basic error detection and reporting. For example if it failed to get WebGL in a normal HTML canvas, it would show a "WebGL not supported" error message with some diagnostic details and some advice about what the user could do about it. The problem in this case is a gotcha where there are two ways to access the canvas API, one supporting WebGL, and the other not - a case we never anticipated, nor had happened with any previous browser.
illiarian 4y ago
> It's a shame that browsers don't have to undergo strict compliance tests There are compliance tests, and it's a thankless job to create and maintain them that some people do. But browsers are bigger than some OSes now. It's almost impossible to create comprehensive compliance tests that cover everything.

by ribit 4y ago

AshleysBrain 4y ago

Is it idiosyncratic to assume that two variants of the canvas API support the same things?

bzzzt 4y ago
Considering it's a big API with dozens of methods I'd be surprised if two implementations would agree exactly.
- AshleysBrain 4y ago
  I would have assumed browsers had one internal implementation and exposed it through both APIs. They wouldn't want to have two separate implementations of a large amount of complex code.
cxr 4y ago
Yes, and it's a little reckless to even get to a state where, even in the presence of bonafide bugs re non-standard behavior, just showing "a blank screen" when your app dies is a possibility. Add some basic error detection/reporting.
- AshleysBrain 4y ago
  We did have basic error detection and reporting. For example if it failed to get WebGL in a normal HTML canvas, it would show a "WebGL not supported" error message with some diagnostic details and some advice about what the user could do about it. The problem in this case is a gotcha where there are two ways to access the canvas API, one supporting WebGL, and the other not - a case we never anticipated, nor had happened with any previous browser.

illiarian 4y ago

> It's a shame that browsers don't have to undergo strict compliance tests There are compliance tests, and it's a thankless job to create and maintain them that some people do. But browsers are bigger than some OSes now. It's almost impossible to create comprehensive compliance tests that cover everything.