Meeting minutes
Repository: webmachinelearning/webnn
anssik: please welcome Sun Shin from NVIDIA to the WebML WG!
anssik: also, please welcome Thomas Beverley and Rhys Jones from AxonZeta to the WebML CG!
… Tom and Rhys have developed AiBrow browser extension that implements the built-in AI APIs defined in the CG and have also extends it with new advanced features
Incubations
anssik: the WebML Community Group met at EU-APAC friendly time on Mon 26 May 2025
https://
https://
anssik: Tom and Rhys joined us to share their implementation experience from AiBrow browser extension
… this new implementation of the built-in AI APIs extends the Prompt API with e.g.:
anssik: notably AiBrow aligns with Mozilla's extension-based API proposal with its support for custom models
… I expect to see future work in the CG around custom models given multiple implementations
anssik: WebML CG also adopted the Proofreader API, and this spec is now open for wider community contributions
webmachinelearning/
anssik: we reviewed Prompt API security and privacy considerations, noting a lot is shared across built-in AI APIs
… the shared parts are now parked in the Writing Assistance APIs spec and cross-referenced from elsewhere
… interested folks should definitely review these considerations, TAG feedback has been incorporated already
https://
https://
Operator specific issues
The minimum data type set, web-platform-tests updates
anssik: issue #853
<gb> Issue 853 The minimum data type set (by huningxin) [operator specific]
anssik: this issue is a follow-up from TPAC 2024 and our previous telcon:
anssik: Ningxin documented his finding from the minimum data type set implementable across all Chromium backends DirectML, TFLite and Core ML (thanks!)
Ningxin: promising results, all ops have data type overlap except two ops
… I shared JSON output with details
… - l2Pool2d: it is not implemented in TFLite backend yet
… - sign: it is not implemented the CoreML backend yet
… for other ops, if you expand the table, I shared the intersection for opSupportLimits()
anssik: Reilly proposed changes to w-p-t
… make tests for the intersecting opSupportLimits mandatory
… others skip automatically if not supported
ningxin: Bruce is working on wpt, starting with logical operators
… graph level has no uint in Core ML, we're changing wpt for logical operators to adapt to this graph level output
… for this logical operator we will cast uint8
ningxin: in the future we try to manage the test cases with minimal data type tests as mandatory and others will be made detectable
layerNormalization, Core ML question/clarification
anssik: issue #748
<gb> Issue 748 Is there a reason to support out of order `axes` for layerNormalization? (by philloooo) [question] [operator specific]
anssik: with MikeW around
… I'd like to see if we can clarify layerNormalization axes Core ML behaviour
… specifically whether "out of order" means nonincreasing or noncontiguous?
Dwayne: the question is whether Core ML sorts the axes?
MikeW: generally, if we can repro, it helps expedite
Dwayne: I will provide a snippet and tag MikeW in the comments
triangular
anssik: issue #768
<gb> Issue 768 Consider removing or redesigning the `triangular` operator (by a-sully) [operator specific]
anssik: based on our previous discussion the consensus seems to be we keep this op?
anssik: confirming we have consensus to keep this, any concerns or question?
[ MikeW and Dwayne thumbs up ]
anssik: we have an agreement to keep triangular, the editors can close this issue
<ningxin> +1
Other issues and PRs
anssik: I want to acknowledge a few issue with PRs that welcome review and feedback
isNaN and isInfinite operators
anssik: issue #811 and PR #858
<gb> Pull Request 858 Add `isNaN` and `isInfinite` operators (by fdwr)
<gb> Issue 811 Behavior when there are NaNs in argmin/max inputs (by philloooo) [interop]
anssik: we made a group decision to add isNaN op and we now have PR for isNaN and isInfinite (thanks Dwayne!)
… the IDL change is as follows:
partial interface MLGraphBuilder
{
...
+ MLOperand isNaN(MLOperand a, optional MLOperatorOptions options = {})
+ MLOperand isInfinite(MLOperand a, optional MLOperatorOptions options = {})
...
};
anssik: see the PR for rationale to include both together, mappings to backend functions, some questions
Dwayne: questions are Q&A for the audience
roundEven operator
anssik: issue #817 and PR #859
<gb> Pull Request 859 Add `roundEven` operator (by fdwr)
<gb> Issue 817 Rounding operators (by fdwr) [feature request] [interop]
anssik: another PR from Dwayne (thanks!!) per our discussion on rounding operators
partial interface MLGraphBuilder
{
...
+ MLOperand roundEven(MLOperand input, optional MLOperatorOptions options = {});
...
};
Dwayne: Core ML does not have direct mapping but can compose it with two ops
MikeW: I just approved this PR
Wide review
anssik: we have received new wide review feedback
… i18n is completed, TAG/Architecture, a11y & Privacy await feedback integration, only Security has no review feedback yet
w3ctag/
<gb> CLOSED Issue 1072 Updated review of Web Neural Network API (by anssiko) [Topic: Design Principles] [Resolution: satisfied with concerns] [Topic: Machine Learning]
Accessibility
anssik: a11y review focused on ensuring use cases consider accessibility
<gb> Issue 350 WebNN Review (APA thread) (by matatk)
anssik: I volunteered to integrate their feedback, but a11y reviewers wanted to open an issue and/or submit a PR themselves which we can then review, appreciate that
Architecture/TAG
anssik: TAG review was completed with a resolution: "The TAG is satisfied with this work overall but requires changes"
w3ctag/
anssik: the trend is good, the previous TAG review was resolved with "satisfied with concerns"
anssik: I'll break down the TAG review feedback:
… first, we asked TAG for advice on naming lowercase 2d vs uppercase 2D
> TAG: On operator naming, "2D" is an initialism (for "2 Dimensional" or similar), and so the guidance in https://
anssik: issue #821 is for this naming consideration
<gb> Issue 821 Operator naming 2D vs 2d (by fdwr) [conventions]
anssik: TAG points us back to the Design Principles, since we felt that doc was not explicit in this case it is up to us to decide
… to help us make an informed decision, I added some data to the issue with diffs of various options we've considered
diff of naming options
… it looks like going all uppercase D would introduce a lot of breaking changes to the API surface
… would this be too big a breaking change at this stage?
… renaming gatherNd and scatterNd to lowercase "Nd" would keep us consistent within this spec, be a smaller breaking change
… I note naming is not always consistent across all the Web APIs for historical reasons
… if we diverge, we could note in the specification it uses a domain-specific naming convention for a reason X to not surprise web authors and to also warn other API authors to not copy the naming convention blindly without consideration
<gb> Issue 821 Operator naming 2D vs 2d (by fdwr) [conventions]
zkis: I see a comment from Josh re WebGL alignment
Dwayne: given the precedence of uppercase, prefer consistency
<zkis> +1
Dwayne: if WebNN is not used directly, then we need to update ORT and samples
MikeW: I suppose we could do deprecation for old names to gracefully migrate
Dwayne: we could do that adding an alias
ningxin: probably we can assess the compatibility impact and leave the issue open for collecting that feedback
Dwayne: a lot of ML APIs use snake case due to Python
>TAG: We would appreciate if the WG would evaluate the likely impacts on sustainability from introducing this API, perhaps in collaboration with the Sustainable Web IG. There are several competing likely effects, including the comparative energy efficiency of personal devices vs datacenters, the greater efficiency of WebNN over WebGPU for the same workload, increased use of neural nets as they get easier to access, faster device
obsolescence if older devices can't effectively run the workloads this API encourages, and likely other considerations. Any sustainability impacts might be balanced by increased utility and privacy, but it would be good to know what we're signing up for.
anssik: purpose-built ML accelerators aka NPUs are generally known to be more power-efficient than GPUs
… other considerations to respond to the sustainability question?
zkis: we could include sustainability aspects in the device selection explainer
Rafael: as far as sustainability, WebNN does better because it can use NPU and can use it together with CPU and GPU
mozilla/
WebKit/
<gb> Issue 1215 Web Neural Network API (by iampi31415)
<gb> Issue 486 Web Neural Network API (by iampi31415)
>TAG: We endorse the concerns that Chrome expressed in webmachinelearning/webnn#453, that WebNN is a proposal that browsers implement a compilation and optimization engine for yet another high level language, on top of the Javascript, Wasm, and WebGPU engines that we've already signed up for. WebNN might be worth doing, but it's a relatively high cost, and we'd like some evidence that it's going to pay off.
<gb> CLOSED Issue 453 Google Chrome Feedback on WebNN: aiming for broad device coverage and maintainability (by vsekhar) [process] [opset] [use case]
anssik: #453 was closed as completed, I think we should make sure the explainer clarifies the relationship with Wasm, WebGPU
<gb> CLOSED Issue 453 Google Chrome Feedback on WebNN: aiming for broad device coverage and maintainability (by vsekhar) [process] [opset] [use case]
anssik: we have a section where we explicitly talk about WebGL/GPU relationship
anssik: we could similarly talk about Wasm vs WebNN, what would be the key message to highlight?
anssik: overall, TAG is happy and closed the review, an action on the group is to report back
… TAG also shared they like the Ethical Principles for Web Machine Learning effort
Internationalisation
anssik: the i18n review has been completed and all feedback addressed by PR #851
<gb> MERGED Pull Request 851 Note Unicode sequences in Security Considerations (by anssiko)
Privacy
anssik: Privacy WG reviewed the WebNN API at their latest meeting, all the feedback was about the opSupportLimits() API future-proofness
… the ask was to ensure opSupportLimits() design is compatible with a future where there may no longer be 1:1 correlation between the OS/browser version and the support per operator
… I responded to their questions and we're awaiting their response
Security
anssik: no security review feedback received yet, if there's any recent input from the Chromium security reviewers, please let me know
Rafael: TAG feedback about new language, it is not a new language it is a new JS API and unlocks new devices that cannot be reached from Wasm and WebGPU
… they say, maybe the payoff is not worth it, that's why we do an OT and put it in front of developers to test
Query supported devices
anssik: we split this issue in two: "before graph compilation" and "after graph compilation"
… first, I think we all agree we want to document the motivating use cases in the explainer, be use case driven in our API design
… we have the first stab at the "before graph compilation" use cases in the explainer that maps use cases to possible device selection preferences
anssik: we should similarly document use cases for "after graph compilation"
After graph compilation (MLGraph.devices)
anssik: issue #836 and PR #854
<gb> Pull Request 854 define graph.devices (by philloooo)
<gb> Issue 836 Get devices used for a graph after graph compilation (by philloooo) [device selection]
anssik: Phillis implemented the MLGraph.devices API in Chromium (thanks!) across Core ML, DirectML and TFLite backends
… I'd like to first discuss the implementation experience
Rafael: I have reviewed the proposal and Mike has provided feedback
… I tend to agree with the feedback, one concern I have is web developers get an impression that NPUs are always slower than GPUs and better for battery life and make decisions based on that
… can make sense on some platforms, while on some otherplatforms NPU may be better than GPU
Markus: I can understand people might jump to premature conclusions when they see NPU supported or not
… generally I'd jump to a conclusion using hardware is faster and more power efficient, for my use case I'd say if I see CPU offered without NPU and GPU, I'd consider it won't run our use case real time
… this would cause an UX glitch visible to the users
… is it possible to rank the devices with estimated execution speed
… can we figure out if something is able to run in less than 35 ms
zkis: I want to say I'm trying to document the use cases based on feedback in this issue, I see NPU is not considered the main use case, trying to figure out if WebNN supports running the graph on GPU, before and after model building
… use case seemsto be can the app use WebNN or not
Rafael: would it be better if we maybe return "hardware-accelerated" or "not-hardware accelerated"?
… w/o acceleration, could use a fallback path
… in graphics APIs, sometimes running in software mode is okay as a fallback
… Ningxin asked about Windows ML implementability
Rafael: we can explore the Windows ML path, DirectML can only pick one device
ningxin: we could look at the native space, this capability is supported across Core ML, DML, TFLite, what's the use case for native apps?
Markus: wanted to ask MikeW, you commented you never know what device is used by Core ML?
MikeW: we could propose this new feature for Core ML, a change might take a long time
Before graph compilation
anssik: issue #815
<gb> Issue 815 Query supported devices before graph compilation (by anssiko) [device selection]
anssik: at our previous meetings we discussed various device selection hints (names in quotes are placeholders):
… "prefer CPU", "prefer NPU", "prefer GPU", "maximum performance", "maximum efficiency", "minimum overall power"
… to help move this feature forward, I crafted a use case PR #855 based on our meeting discussion that maps the considered device selection hints to use cases
<gb> MERGED Pull Request 855 Add device preference use cases to explainer (by anssiko)
anssik: (this PR was also an experiment on how coding agents could work in the spec authoring space)
… feedback on the use cases welcome
zkis: we are in mapping phase in map-reduce, need to continue this work