profile
viewpoint
T.J. Crowder tjcrowder Crowder Software United Kingdom crowdersoftware.com

tjcrowder/ecma262 1

Status, process, and documents for ECMA262

tjcrowder/browser-compat-data 0

This repository contains compatibility data for Web technologies as displayed on MDN

tjcrowder/ecmarkup 0

An HTML superset/Markdown subset source format for ECMAScript and related specifications

tjcrowder/grunt-distiller 0

Grunt plugin to automatically prepare scripts and stylesheets for release based on the input HTML.

tjcrowder/jquery 0

jQuery JavaScript Library

tjcrowder/kumascript 0

Bringing scripting to the wiki bears.

tjcrowder/proposal-class-fields 0

Orthogonally-informed combination of public and private fields proposals

tjcrowder/proposal-decorators 0

Decorators for ES6 classes

tjcrowder/proposal-item-method 0

A TC39 proposal to add a .item() method to all the basic indexable classes (Array, String, TypedArray)

tjcrowder/proposal-numeric-separator 0

A proposal to add numeric literal separators in Javascript. https://tc39.github.io/proposal-numeric-separator/

issue commentnodejs/help

Using `__proto__` in object literals

@devsnek - That's great news (in relation to this item), thanks!! I get leaving the accessor in Annex B, but I've really wanted __proto__ in literals (or some replacement for it) to be part of the main definition of object literals.

vsemozhetbyt

comment created time in 6 days

issue commentnodejs/help

Using `__proto__` in object literals

FWIW:

  • Because it's part of Annex B, __proto__ in object literals (and its cousin Object.prototype.__proto__) are officially only defined for JavaScript engines in web browsers or if the engine "...is required to run the same legacy ECMAScript code that web browsers encounter." I think it would be hard to argue that the Node.js ecosystem doesn't fit the second criterion there, and I can't imagine __proto__ in object literals will disappear from V8 in Node.js. (But I have no special knowledge in this regard.)
  • The way __proto__ in object literals is specified does supposedly change the prototype of the object after it was created. That doesn't mean JavaScript engines can't optimize it, though. It's hard to see what would be in their way — the object being created can't be a proxy, and nothing else will ever have seen it, so nothing else can observe its prototype before it's changed. And the engine knows in advance, from parsing, whether __proto__ is there.
    • For the avoidance of doubt, the above does not apply to the cousin, the Object.prototype.__proto__ accessor property. You can't rely on the accessor being on any given object (the object may have no prototype, or may inherit from a prototype that doesn't inherit from Object.prototype), so using the accessor property is much chancier than using the __proto__ property name in an object literal.

Re your alternative, it's much less cumbersome to use Object.assign than the second argument to Object.create:

const proto = /*...*/;
const obj = Object.assign(Object.create(proto), {
    // Your properties here in the normal way, not as property descriptors
    example: 42
});
console.log(obj.example); // 42

On Twitter you asked if __proto__ was deprecated. Fundamentally, yes, it is; but that doesn't mean it's going away. Annex B has a big explanatory note at the beginning. It says

  • All of the language features and behaviours specified in this annex have one or more undesirable characteristics and in the absence of legacy usage would be removed from this specification.

and

  • These features are not considered part of the core ECMAScript language. Programmers should not use or assume the existence of these features and behaviours when writing new ECMAScript code.

and

  • ECMAScript implementations are discouraged from implementing these features unless the implementation is part of a web browser...

but that same sentence continues with

  • ...or is required to run the same legacy ECMAScript code that web browsers encounter.

and elsewhere in the note

  • However, the usage of these features by large numbers of existing web pages means that web browsers must continue to support them. The specifications in this annex define the requirements for interoperable implementations of these legacy features.

So...hopefully that gives you some input into your decision whether to use __proto__ in object literals, and a slightly less cumbersome alternative (Object.assign(Object.create(...), { ... })) if you decide not to.

Hope that helps!

vsemozhetbyt

comment created time in 6 days

PR opened tc39-transfer/proposal-item-method

Add package.json, build step; update rendered spec.

Created package.json by:

  • Copying from class fields and updating to use existing docs directory instead of out
  • Removing mkdirp since docs always exists so it has the ecmarkup support scripts. Could probably be improved by linking to them rathen than duplicating them, but it's a start.
+3721 -4

0 comment

3 changed files

pr created time in 17 days

push eventtjcrowder/proposal-item-method

T.J. Crowder

commit sha 94f87f6796d2935faaecc6be27a0f7c3557f825b

Reflect proposal is at Stage 2, update spec text links to use new repo owner (#13) Re Stage 2: https://github.com/tc39/proposals/commit/1badce0191cc12203a22e5b60599a1eca911d00b

view details

push time in 17 days

issue commentgatsbyjs/gatsby

GraphQL Query Options Reference: 404 on Links to CodeSandBox -> Keep Example running

As I write this, they're working, presumably because someone manually restarted the app again.

There are other problems with the CodeSandbox integration:

  1. It doesn't work by default when using the Brave browser, Brave classifies them as trackers. You have do go "shields down" for them to work or they just stick at Loading... forever.
  2. There's a significant lag (2-10 seconds on my fast connection) between the rest of the documentation appearing and the examples appearing.
  3. Coming back to a documentation page you've had open in a tab for a while, the code blocks are just missing (literally just white space where they should be) until/unless you refresh the page.
  4. The sample code isn't in the page, which is a problem for searches.

Although it's really cool and handy when it works, it seems like relying on a third-party service integration for essential documentation is problematic. :-) I suggest including the examples as marked up code in the page itself, and either providing a link to the CodeSandbox live version (expanding it inline in the page or opening a new tab, etc.), or replacing the static code with the live example when it's done loading, if it can be done without reflow and too much of a flash effect.

I like Gatsby a lot so far, but I've found this aspect of the documentation problematic and frustrating -- even before I ran into the 404s. (Sadly, unlike @muescha, I wasn't smart enough to think to look at the page source and go to CodeSandbox directly.)

muescha

comment created time in 18 days

issue commenttc39-transfer/proposal-item-method

Add to `arguments` as well?

@ljharb - We already add an own Symbol.iterator method to them. :-) So there's some precedent.

tjcrowder

comment created time in 20 days

issue commenttc39-transfer/proposal-item-method

Add to `arguments` as well?

FWIW, I come down on the side of adding it, unless implementers see a performance concern or there's evidence adding it isn't web safe (Con # 3). For me, the consistency with other indexables is the better path and I'd rather not have to explain Yet Another Way arguments is "special."

tjcrowder

comment created time in 20 days

issue openedtc39-transfer/proposal-item-method

Add to `arguments` as well?

This proposal currently adds item to the big three indexables: Strings, arrays, and typed arrays. Should it add item to the indexable that dare not speak its name, arguments?

Pros - some arguments (no pun) in favor:

  1. arguments is an indexable, so the rationales for item apply to it just as much as to other indexables.
  2. Leaving it off would make it the only indexable that doesn't have item, potentially leading to surprises.
  3. Adding it is consistent with having made arguments iterable in ES2015 when the other indexables were made iterable.

Cons - some arguments against:

  1. arguments is all but deprecated by rest parameters. Providing item is about improving the semantics/ergonomics of new code, which probably shouldn't use arguments.
  2. arguments objects are already unlike arrays (don't inherit from Array.prototype, are mapped to formal parameters in loose mode). Even if item were added, the "surprises" mentioned in Pro # 2 are still there for other methods, even methods like slice which all the other indexables have.
  3. arguments objects inherit directly from Object.prototype, so adding item would require either giving them a prototype to inherit item from (which seems like overkill) or adding item as an own property in CreateUnmappedArgumentsObject and CreateMappedArgumentsObject. Is there a danger there? Some legacy code somewhere that's optionally adding item to arguments objects and then checking later whether it's there? (blech)

In terms of doing it, it seems like Array.prototype.item could be reused as is for arguments objects, probably by definining %ArrayLikeItemMethod% and then using that as the initial value of Array.prototype.item and in a new step in the CreateXYZArgumentsObject operations that adds item to the new object. (So that code replacing Array.prototype.item doesn't affect arguments objects.)

I'm happy to do the spec changes if that ends up being the consensus.

created time in 20 days

pull request commenttc39-transfer/proposal-item-method

Reflect proposal is at Stage 2, update spec text links to use new repo owner

I just saw issue #8, which this will close.

tjcrowder

comment created time in 20 days

PR opened tc39-transfer/proposal-item-method

Reflect proposal is at Stage 2, update spec text links to use new repo owner

Re Stage 2: https://github.com/tc39/proposals/commit/1badce0191cc12203a22e5b60599a1eca911d00b

+3 -3

0 comment

1 changed file

pr created time in 20 days

create barnchtjcrowder/proposal-item-method

branch : feature/update-spec-url

created branch time in 20 days

fork tjcrowder/proposal-item-method

A TC39 proposal to add a .item() method to all the basic indexable classes (Array, String, TypedArray)

fork in 20 days

issue openedgatsbyjs/gatsby

404s for GraphQL Query Options Reference examples

Description

I'm getting 404s for the examples in the GraphQL Query Options Reference page. I'm fairly sure this is a new issue, I think I've been on that page in the last few days before and had the examples be there. It's not browser-specific (I tried Brave, Chrome, and Firefox).

(I initially clicked "Documentation" to report this, but that was oriented on creating/improving documentation rather than reporting a bug delivering the documentation.)

Steps to reproduce

  1. Go to https://www.gatsbyjs.org/docs/graphql-reference/
  2. Wait a moment
  3. Note that 404s appear for the examples as in the following screenshot. It's every example except the one-liner JavaScript example about filtering on multiple fields.

gatsby-404

created time in 20 days

delete branch tjcrowder/browser-compat-data

delete branch : feature/remove-cleanupSome

delete time in 23 days

delete branch tjcrowder/browser-compat-data

delete branch : feature/ie-animationend-support-6135

delete time in 23 days

issue commentcodehag/proposal-cleanup-some

Remove cleanupSome docs from MDN

@littledan - All done! Page is deleted, link to it removed from the FinalizationRegistry page, and I've done a PR to remove the compat data.

littledan

comment created time in 23 days

PR opened mdn/browser-compat-data

Remove `FinalizationRegistry.prototype.cleanupSome`

This is in light of https://github.com/codehag/proposal-cleanup-some/issues/6. The page has been removed from MDN. More: https://discourse.mozilla.org/t/should-the-finalizationregistry-prototype-cleanupsome-page-be-removed/64309

+0 -58

0 comment

1 changed file

pr created time in 23 days

create barnchtjcrowder/browser-compat-data

branch : feature/remove-cleanupSome

created branch time in 23 days

delete branch tjcrowder/browser-compat-data

delete branch : feature/update-cleanupSome

delete time in 23 days

create barnchtjcrowder/browser-compat-data

branch : feature/update-cleanupSome

created branch time in 23 days

push eventtjcrowder/browser-compat-data

Florian Scholz

commit sha 3f4f23aff58fea7f0eaac96730b4a094f5f2b1ef

Split JS bitwise operators (#6272)

view details

Daniel D. Beck

commit sha 4434630f7f041b051298c7b1e2f7b0570eaea68f

Clean up activeVRDisplays data (#6264) * Add initial secure_context_required feature for WebVR * Add note for Edge activeVRDisplays support https://developer.microsoft.com/en-us/microsoft-edge/status/webvr/?q=webvr * Add secure_context_required version for Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=1381645 * Update Chromium versions based on Joe's previous review * Add missing description

view details

TheDude53

commit sha 88facfbf8953d0c7e98e1115d005db27b21a7114

Add support for MediaSession in Opera (#6255) * Add partial MediaSession support in Opera * Add support for setPositionState in MediaSession I had an outdated version of Opera when testing. After updating, I could use navigator.mediaSession.setPositionState

view details

Joe Medley

commit sha 6b101b3be4a0cb794a9defa78ed6e20eec465714

Add data for HTMLInputElement.webkitEntries. (#6279)

view details

Joe Medley

commit sha 7859dd7bcabb531fd65bc7141eaa3548f616edeb

Add Screen Wake Lock API. (#6280)

view details

Jamie Webb

commit sha 22091bcab76d74048ff58f0af7737b6132c091a3

HTMLImageElement.currentSrc Safari (#6282) * currentSrc supported in safari and safari ios * currentSrc supported in safari and safari ios * use supported safari versions

view details

Joe Medley

commit sha 2ac9872e3a752c09d786f347ccb5fcba904fd9e7

Add BarcodeDector data. (#6250)

view details

ExE Boss

commit sha 919af23efc3a65e45702433bb120b1563539701f

feat(css): Update `appearance` data for `menulist‑button` changes (#6257)

view details

T.J. Crowder

commit sha e8a988a20fce991c89cad24b2ec87cd1b1583707

Add data for WeakRef and FinalizationRegistry (#6287) Chrome version is based on https://www.chromestatus.com/features/5892186633666560 Firefox by default version based on https://hg.mozilla.org/mozilla-central/rev/8cf72e804176 Node.js information is based on https://nodejs.org/en/blog/release/v12.16.0/ and https://nodejs.org/en/blog/release/v13.0.0/.

view details

Gilmore Davidson

commit sha 8e4a28203c487ac8731a9dbe72870661c908671d

Move Intl.Collator caseFirst option under the constructor (#6253)

view details

Daniel D. Beck

commit sha cc9bc0a97b0cb75d694a2418b633ae390d6bae2c

IntersectionObserver() support for document as root (#6289) * Set non-null Opera value for IntersectionObserver() * Add document_as_root feature to IntersectionObserver constructor Chromiums: https://bugs.chromium.org/p/chromium/issues/detail?id=1015183 via #6066 Firefoxes: https://bugzilla.mozilla.org/show_bug.cgi?id=1623623 via #6083 Safaris: Implemented but not yet shipped https://trac.webkit.org/changeset/258648/webkit

view details

Joe Medley

commit sha db51af670bfc93e9d5bad52b7f650cbf4bb99324

Add ContactsManager.json. (#6277) * Add ContactsManager.json. * Update api/ContactsManager.json Co-authored-by: Florian Scholz <fscholz@mozilla.com> Co-authored-by: Florian Scholz <fscholz@mozilla.com>

view details

Joe Medley

commit sha bc87a9b82f428b81f77bf760cef044d89e8c6f79

Add CSSPropertyRule.json. (#6278) * Add CSSPropertyRule.json. * Correct version number.

view details

Joe Medley

commit sha e73eb5639ee60866149c6380041cfabccad48b81

Update EffectTiming Chrome data (#6273)

view details

Florian Scholz

commit sha 072155434a728ba0eac56d920529a283b8dadd02

Patch release containing data or non-breaking updates only

view details

Gilmore Davidson

commit sha b899855ec496232045642555d804fc51b2e38c28

Complete nodejs data for SharedArrayBuffer (#6294)

view details

Joe Medley

commit sha d89347b2a95f161ce8de3ede188cc21e5dd89763

Chrome removes @viewport (#6165)

view details

Florian Scholz

commit sha 4bef6027923c9d7ea11b1169cfa801d154c3a96d

Atomics ships in Fx78, Wasm.Memory accepts 'shared' (#6297)

view details

Martin Kolárik

commit sha 041eb4273b4d4b8b898327ce6c1e35d05407902d

Opera supports Location.hostname (#6286) This reverts commit 69d797dd2d8035f33495261ab78efb2139dafcce (#3482).

view details

Michael[tm] Smith

commit sha 56aba711611b608c4a1021d81638d0ba88141e82

Update AudioTrack and VideoTrack support data (#6224) This change updates the support data for AudioTrack and VideoTrack. The data was confirmed by doing manual testing and by checking browser-engine change/revision histories. It mirrors data from https://github.com/mdn/browser-compat-data/pull/2863 (https://github.com/mdn/browser-compat-data/commit/b378e47) for AudioTrackList and VideoTrackList (when we first added those).

view details

push time in 23 days

issue openedmdn/browser-compat-data

Intl.DateTimeFormat timeZoneName not supported by IE11

We should add a row to the Intl.DateTimeFormat constructor page's data saying that timeZoneName isn't supported by IE11. On IE11, this code just produces 12:49:

document.body.insertAdjacentText(
    "beforeend",
    new Intl.DateTimeFormat(undefined, {hour: "2-digit", minute: "2-digit", timeZoneName: "long", hour12: false}).format(new Date())
);

(Same with "short" instead of "long".) In contrast, Firefox, Chrome, and iOS Safari include a timezone name (of some kind).

I don't have time to do the update and PR right now, but I'll try to in the next couple of weeks.

created time in a month

PublicEvent

pull request commenttc39/ecma262

Normative: Make array spread accept nullish values

Ran into this just recently, having somehow managed to forget that iterable spread doesn't special case undefined:

doSomething(["hardcoded1", "hardcoded2", ...more]);

...where more was an optional parameter for the function this was in.

Like others here, I don't like my choices for dealing with it:

  1. ?? [] or similar
  2. Different code paths
  3. In my case it was a parameter, so I could have used a default parameter value (I was using TypeScript and disallowing null anyway)

I would much prefer iterable spread to special case undefined and null the way property spread does, because it would be A) useful, and B) consistent.

mathiasbynens

comment created time in 2 months

issue openedOfficeDev/office-js

FilterCriteria objects with invalid null properties

<!--- Provide a general summary of the issue in the Title above -->

Expected Behavior

Being able to use the FilterCriteria objects we receive from autofilter:

let saveCriteria = autoFilter.criteria.slice();

...to (re)apply those criteria later via apply:

sheet.autoFilter.apply(appropriateRange, index, saveCriteria[index]);

Current Behavior

The objects from the criteria array have properties with the value null, but the TypeScript type information says they shouldn't be able to be null (they can be undefined, but not null) and when you try to use them with apply, it throws the following error:

RichApi.Error: The argument is invalid or missing or has an incorrect format.

As a result, you can't use the FilterCriteria object you got to (re)apply filtering criteria.

At the moment I'm working around it by removing those properties:

const entry = Object.fromEntries(
    Object.entries(saveCriteria[index]).filter(([name, value]) => value !== null)
);
sheet.autoFilter.apply(dataRange, index, entry);

Steps to Reproduce, or Live Example

As above.

Context

This issue cost us a couple of hours of trial and error figuring out why the API wasn't working correctly, creating the workaround, and reporting the issue, but ongoing impact is minimal. But obviously it would be better if we don't have to massage the objects like that.

Your Environment

  • Platform [PC desktop, Mac, iOS, Office Online]: Office Online (but presumably would affect desktop Excel as well)
  • Host [Excel, Word, PowerPoint, etc.]: Excel
  • Office version number: Office 365 build 16.0.13014.35904
  • Operating System: Windows
  • Browser (if using Office Online): Chrome

Useful logs

N/A

created time in 2 months

pull request commentmdn/browser-compat-data

Initial compatibility info for WeakRef and FinalizationQueue

@Elchi3 - It looks like the compat data still isn't on the page. Did I do something wrong, or is there a pipeline issue...?

tjcrowder

comment created time in 2 months

delete branch tjcrowder/browser-compat-data

delete branch : feature/weakref-and-finalizationregistry

delete time in 2 months

pull request commentmdn/browser-compat-data

Initial compatibility info for WeakRef and FinalizationQueue

@Elchi3 - Thanks again for all your work walking me through this. :-) Next time it should be a lot smoother!

tjcrowder

comment created time in 2 months

push eventtjcrowder/browser-compat-data

T.J. Crowder

commit sha 15b8a36ec70370a8d261b3f6d5f16490f47a433c

Fix filename for FinalizationRegistry

view details

push time in 2 months

push eventtjcrowder/browser-compat-data

T.J. Crowder

commit sha 6e445d9f650d52f05f48304b8cd0db84cf75f27b

Update javascript/builtins/FinalizerRegistry.json Co-authored-by: Florian Scholz <fscholz@mozilla.com>

view details

push time in 2 months

push eventtjcrowder/browser-compat-data

T.J. Crowder

commit sha 9bdcf74d96d657678fff6d134ec92a07e010e012

Update javascript/builtins/WeakRef.json Co-authored-by: Florian Scholz <fscholz@mozilla.com>

view details

push time in 2 months

pull request commentmdn/browser-compat-data

Initial compatibility info for WeakRef and FinalizationQueue

Some notes on the latest:

  • Firefox for Android is v68 and I'm told by Jon Coppeard at Mozilla it always will be since they're doing Firefox Preview now instead. So "firefox_android" is false, can't be mirrored from "firefox" anymore.
  • Opera is currently shipping on a Chromium v81 base. I couldn't find any public signals about when they'll update to v84 and thus get weakrefs.
  • The proposal doesn't link to anything about JavaScriptCore having support yet. Couldn't find any public signals about Safari, so for now, went with false.

Thank you again @Elchi3 for your help and patience thus far!

tjcrowder

comment created time in 2 months

push eventtjcrowder/browser-compat-data

T.J. Crowder

commit sha b221551eb79ab3dce3a9a85752d05255586bee84

Fix spec URLs on the subfeatures

view details

push time in 2 months

push eventtjcrowder/browser-compat-data

T.J. Crowder

commit sha 97e40b32d3aa51574be0adbf435add216efe1d39

* Correct Firefox behind-a-flag info (it was never behind a flag in the stable channel, just nightlies). * Add entries for constructors and methods.

view details

push time in 2 months

pull request commentmdn/browser-compat-data

Initial compatibility info for WeakRef and FinalizationQueue

@Elchi3 - Man, I really was having an off day, wasn't I? Thank you for all of that, and for being kind about it.

I'll add the subfeatures. I thought the breakdown was only done when there was variability. But A) Am I wrong about that? And B) There is variability, because the support data is by environment, not engine; cleanupSome is likely not to be supported on web browsers, at least not initially, even though it's supported by the engines in them. (I have a note on the method itself.)

So, off to see what the reality on the ground is...

tjcrowder

comment created time in 2 months

push eventtjcrowder/browser-compat-data

T.J. Crowder

commit sha 0f2ee9d60efd46de475865cee9cc78263eb19ce0

Update javascript/builtins/WeakRef.json Co-authored-by: Florian Scholz <fscholz@mozilla.com>

view details

push time in 2 months

push eventtjcrowder/browser-compat-data

T.J. Crowder

commit sha bbe7fecadbd34c40dae2ebed03d4a93bf6781019

Update javascript/builtins/FinalizerRegistry.json Co-authored-by: Florian Scholz <fscholz@mozilla.com>

view details

push time in 2 months

push eventtjcrowder/browser-compat-data

T.J. Crowder

commit sha 693809e438ca3919f3b4056686f78eab6f3478e2

Update javascript/builtins/FinalizerRegistry.json Co-authored-by: Florian Scholz <fscholz@mozilla.com>

view details

push time in 2 months

pull request commentmdn/browser-compat-data

Initial compatibility info for WeakRef and FinalizationQueue

@Elchi3 - Thanks! Done.

tjcrowder

comment created time in 2 months

push eventtjcrowder/browser-compat-data

T.J. Crowder

commit sha 27ce132db2a63eb9a96193afa7c136ac67f9cb9b

Assume Edge v84 is correct as well

view details

push time in 2 months

pull request commentmdn/browser-compat-data

Initial compatibility info for WeakRef and FinalizationQueue

I left Edge at false because I couldn't find anything from Microsoft saying when it would be enabled. But given Edge is now based on Chromium and I can't see any good reason to leave this feature disabled when the Chromium codebase enables it, should we assume Edge 84?

tjcrowder

comment created time in 2 months

push eventtjcrowder/browser-compat-data

T.J. Crowder

commit sha 20de76b95aae06da0c5965f00f608f78444af549

Fix various issues I would have seen if I'd run `npm run test` first. :-| Node.js information is based on https://nodejs.org/en/blog/release/v12.16.0/ and https://nodejs.org/en/blog/release/v13.0.0/. I've verified the flag exists in v13.0.0. v12.16.0 was rejected as a Node.js version, I guess because it's LTS...?

view details

push time in 2 months

pull request commentmdn/browser-compat-data

Initial compatibility info for WeakRef and FinalizationQueue

Can't believe I didn't catch that there were tests I could run. Fixing the issues.

tjcrowder

comment created time in 2 months

push eventtjcrowder/browser-compat-data

T.J. Crowder

commit sha f3058819ceaa232e6d624eaafeb8422d4cedb4fa

Gah! Fix JSON errors!

view details

push time in 2 months

PR opened mdn/browser-compat-data

Initial compatibility info for WeakRef and FinalizationQueue

My first try adding compat info from scratch, apologies for any rough edges.

Chrome version is based on https://www.chromestatus.com/features/5892186633666560 Firefox behind-a-flag version is based on the milestone here: https://bugzilla.mozilla.org/show_bug.cgi?id=1593698 Firefox by default version based on https://hg.mozilla.org/mozilla-central/rev/8cf72e804176

I've verified the Firefox preference in v77.

+82 -0

0 comment

2 changed files

pr created time in 2 months

delete branch tjcrowder/browser-compat-data

delete branch : feature/weakrefs

delete time in 2 months

create barnchtjcrowder/browser-compat-data

branch : feature/weakrefs

created branch time in 2 months

push eventtjcrowder/browser-compat-data

Janet Swisher

commit sha a8cdc17c3a9361cfe59053a1f3ec5463fcb6e7f0

Remove mozbrowser feature (#6149) Support is being removed (https://bugzil.la/1614462), and it was never exposed to WebExtensions (i.e., https://blugzil.la/1318532 was never released).

view details

Janet Swisher

commit sha 659fabb8145b1cf6bb80deb5a7c45269ac6fe22a

Bug re option/label (40545) is fixed in Fx77 (#6140)

view details

Daniel D. Beck

commit sha 42d70b91adf7c4bbd3dba15406a7a0c450ed9721

Revise notes to avoid exclusionary word choices (#6139)

view details

Serge El Hachem

commit sha 99915eae11a01e87e85211830a48c74df1b699a3

Update Safari data for css clamp() (#6142) * Update Safari data for css clamp() * Update Safari mobile data for CSS clamp()

view details

Queen Vinyl Darkscratch

commit sha 7adcb8e11b9a4b3571340bc7fe362030c21dfc40

Update Safari data for AnalyserNode API (#6141)

view details

Queen Vinyl Darkscratch

commit sha 031cba7cc01ffb6bc89d04b2e8c1b72c6c4872fe

Update versions for Attr API (#6147)

view details

lpd-au

commit sha dc48ca5d37ab14b038b506433553389f66c56b5a

Correct Android data for Element.getAnimations() (#6052)

view details

Makoto Kato

commit sha 190f0e6335951a54d4b8a22d5090268760aaa96f

Update autocapitalize attribute support. (#6082) According to https://www.chromestatus.com/feature/4974738740871168, Chrome Android and WebView support this on 66. Also, this attribute doesn't support on Gecko yet. See https://bugzilla.mozilla.org/show_bug.cgi?id=1425291.

view details

Anton Juul-Naber

commit sha cdd9f737ecaa5162af82b79a30ef80ba9426c1cf

Update sharedwokers (#6084) * Accurate changes to SharedWorker Edge didn't have support until 79 IE didn't have support * Mostly accurate changes to SharedWorker Chrome Android doesn't support it Opera Android removed support in v14 Samsung Internet only had support in v4-4.2 * Fix samsung browser versions * Fix unlisted support notes * Fix more unlisted support notes

view details

Queen Vinyl Darkscratch

commit sha 991ebf87cc797124fe0e9752ada9fb054747c390

Update Chromium/Safari data for form novalidate (#6109)

view details

Queen Vinyl Darkscratch

commit sha d4f40b11da9d39ac92a307e25b993d650ab016d6

Update Opera Android + Safari data for contenteditable types (#6117)

view details

Florian Scholz

commit sha f697a3d1372a4ec18648c7ba6364583481e32ac5

Patch release containing data or non-breaking updates only

view details

Queen Vinyl Darkscratch

commit sha f0754c896ba46ce06529149335eeea63db52a4e9

Safari supports trailing commas in functions (#6155)

view details

Queen Vinyl Darkscratch

commit sha 2d72c51f88f3d1ea2044ff5da295fefae757a5ca

Safari supports javascript.builtins.String.matchAll (#6152)

view details

Queen Vinyl Darkscratch

commit sha 37537443bba11562b01779da1be7f5eabba38192

Fix wording in note (#6111)

view details

Queen Vinyl Darkscratch

commit sha 3f503c8dd38e49130e7d0d60ad143e7de74d6294

Update notes for additional NodeJS clarity (#6159)

view details

Queen Vinyl Darkscratch

commit sha a0e394c2706d0327f1e962d2ed55f87df146c437

Samsung Internet 11.0 and 11.2 are retired (#6158)

view details

Queen Vinyl Darkscratch

commit sha bbbd8cc68a4754afd7e0e2b6509b4b11d154cea9

Safari supports Rest in arrays (#6153)

view details

Michael[tm] Smith

commit sha ed46d28ee0aeb369ccac54130f66de5306493c63

Update Push-in-Fx-ESR notes; remove outdated notes (#6119) Per https://hg.mozilla.org/releases/mozilla-esr60/file/default/browser/app/profile/firefox.js#l1573 and https://hg.mozilla.org/releases/mozilla-esr68/file/default/browser/app/profile/firefox.js#l1710 Push is disabled in ESR 60 and 68. Per https://hg.mozilla.org/releases/mozilla-release/file/default/browser/app/profile/firefox.js#l1696 Push is not only enabled in Nightly/Dev/Beta; it’s enabled by default in Firefox 44+ releases, per http://bugzil.la/1153499 (which enabled it for Fx 42), and per http://bugzil.la/1207875 (which subsequently disabled it for Fx 42 and 43 only, but not for any releases after Fx 43).

view details

Anton Bershanskiy

commit sha 89534363b1315637df08e49686d560ac8bbcbfb5

Fix typo in Permissions API descriptions (#6162) Preparatory work for landing descriptions linter.

view details

push time in 2 months

push eventtjcrowder/proposal-weakrefs

T.J. Crowder

commit sha 684c7d4928d2d6b9282c9e272f43aea8a1413724

Be explicit about the fact cleanupSome is expected not to be on web browsers initially, link to HTML issue.

view details

push time in 2 months

create barnchtjcrowder/proposal-weakrefs

branch : feature/cleanupsome-doc-update

created branch time in 2 months

issue commentOfficeDev/office-js

Difficulty working with invalid bindings

@cawise - The hit's not too bad since you can do a batch operation and only fall back when there actually is an invalid binding, but it's definitely convoluted and the hit is there if you have one. Abandoning it for old-style Office automation, or a non-Office solution?

cawise

comment created time in 3 months

issue commentOfficeDev/office-js

Difficulty working with invalid bindings

@lumine2008 & @cawise - I've logged this feature request on uservoice. (@lumine2008 - A preview option before posting would be nice!!)

cawise

comment created time in 3 months

pull request commentmdn/browser-compat-data

Document and element animation events support in IE

@ddbeck - Great, thanks for doing that. Done!

tjcrowder

comment created time in 3 months

push eventtjcrowder/browser-compat-data

T.J. Crowder

commit sha e2ce100eb07066824fe1ad9a5d9c3be77ab45628

@ddbeck confirms that Edge v12 supports animationstart, animationend, and animationiteration.

view details

push time in 3 months

pull request commentmdn/browser-compat-data

Document and element animation events support in IE

@ddbeck - That's a good point. Unfortunately, I downloaded the Edge v12 VM from here but (unlike the IE10 VM I got from there), it won't boot for me under VirtualBox. :-| I can attest to the fact that Edge v44 supports animationstart, animationend, and animationiteration but not animationcancel just like IE10-11 do. :-) Should I at least add that?

tjcrowder

comment created time in 3 months

issue commentOfficeDev/office-js

Difficulty working with invalid bindings

@cawise - We have this problem too. The way I'm working around it at the moment is to loop through all the bindings loading their ids, then calling sync and if it raises an invalid binding error, going through the bindings one by one removing the ones that are invalid. (Which I only know how to do with the old API because of this issue and its related Stack Overflow question -- thank you!) So when there aren't invalid bindings, it's fairly efficient, but when there are it has to slow down and deal with that. Details in this Stack Overflow answer.

cawise

comment created time in 3 months

issue commentOfficeDev/office-js

Difficulty working with invalid bindings

@lumine2008 - Please do post the direct link cawise asked for. Searching for "binding" didn't seem to turn up the feature request.

cawise

comment created time in 3 months

more