9 Matching Annotations
  1. Jan 2023
  2. Jan 2022
    1. Moving forward I'd rather see {#await} being removed than adding more {#await}. But that's just from my experience and I'm sure there are use-cases for it.
  3. Feb 2021
  4. Nov 2020
    1. However, this coalescing was very complicated, both in the specification and implementations, due to the dynamism of computed property names for accessors. Coalescing was a big source of overhead (e.g., in terms of code size) in polyfill implementations of "Stage 2" decorators.
  5. Oct 2020
  6. May 2020
    1. AppCache was standardized in the Offline Web applications section of the HTML specification. The standard is formally referred to as application caches. New Web applications should be built around Service Workers. Existing applications that use AppCache should migrate to Service Workers. AppCache access was removed from insecure origins in M70. This intent addresses AppCache usage in secure origins.

      First and foremost, AppCache is a deprecated standard with serious architectural concerns. Second, Chrome's AppCache implementation is a security and stability liability. AppCache is documented as deprecated and under removal in MDN and in the WHATWG standard, and marked as obsolete in W3C’s HTML 5.1. It is incompatible with CORS, making it unfriendly for usage with CDNs. Overall, AppCache was changed in over 400 Chromium CLs in 2018-2019. It has imposed a tax on all of Chrome’s significant architectural efforts: Mojofication, Onion Souping, and the Network Service. The security benefits of the removal are covered under Security Risks.

  7. Mar 2020
    1. Yes, it’s been deprecated. Why? Because too few people were using it to make it worth the time, money, and energy to maintain. In truth, although I sometimes disagree with the operator changes, I happen to agree with this one. Maintaining ALL of the synonyms takes real time and costs us real money. Supporting this operator also increases the complexity of the code base. By dropping support for it we can free up a bunch of resources that can be used for other, more globally powerful changes.
  8. Nov 2019
    1. I'm considering this, although I'm still leaning towards not including it and I'd love to just get rid of first if it wouldn't break so many peoples tests. Newcomers to Capybara don't understand (or aren't willing to learn) the issues that all/first (and last if added) have and massively overuse them. Yes the fact that all and first now wait by default will prevent some of the new user issues/confusion, but it won't fix the non-reloadability issue.