Meeting minutes
anssik: hi all and welcome back after the summer break!
… we'll start by welcoming our new participants, please welcome:
… Johann Hofmann from Google and Ugar Acar from Depixen to the WebML WG
… Brandon Walderman and Leo Lee from Microsoft and Khushal Sagar, David Bokan and Hannah Van Opstal from Google, Preety Kumar from Deque Systems and Jason McGhee, Laura Morinigo, Murad Aliyev and Timothy de Rosen as individual contributors to the WebML CG
… many of the new Community Group participants joined to contribute to the newly launched agentic web workstream that hosts discussions on WebMCP
… I'm happy to see many new folks join us, including individual contributors with very relevant implementation experience from open-source agentic frameworks
TPAC 2025 F2F announced (Kobe, Japan, 10–14 Nov 2025)
anssik: I wanted to share the overall TPAC 2025 plan and gather feedback from you on how to avoid scheduling conflicts for participants
… confirmed time available for the WebML community:
… 10 November 2025, 09:00–16:45 Japan Standard Time
… 11 November 2025, 09:45-18:00 Japan Standard Time
… in the agenda you see Monday for WG and Tuesday for CG, but I'm proposing we'll use the time flexibly as to minimize scheduling conflicts for participants
… I'm aware of Domenic's (Built-in AI APIs editor) scheduling conflict for Tuesday (overlap with WHATWG), any other known conflicts, anyone?
Reilly: this schedule seems OK
… anssik: I'd proposewe cover WebNN and selected Built-in AI APIs on Monday, continue any remaining WebNN topics and WebMCP on Tuesday
… TPAC registration is now open and I see many have already registered, thank you!
… hotel has a discount price with a liberal cancellation policy for TPAC participants
… please see the following links for more information, to register and book the hotel
Agentic web workstream
Repository: webmachinelearning/webmcp
anssik: the WebML Community Group initiated work on agentic web workstream and is now exploring a WebMCP proposal
… WebMCP abstract:
… "Enabling web apps to provide JavaScript-based tools that can be accessed by AI agents and assistive technologies to create collaborative, human-in-the-loop workflows."
Brandon: good summary, would add that motivation to do MCP-style tools in browser is that it has access to state that separate MCP approaches don't, web pages have user identity and state, all this context is available
… there are certain developer community, web is built for humans, this is not going away anytime soon, WebMCP is an incremental step
anssik: the scope of work in this initial exploration phase is an explainer document and a high-level proposal that explores possible API shape without going into spec details
anssik: I also want to acknowledge two individual contributors Alex Nahas and Jason McGhee who both have developed early WebMCP prototypes and will provide additional implementation experience to the group
… please check the OSS projects for more information:
anssik: given the early proposal is shaping up this nicely, I plan to kick off the Community Group charter change process soon to allow the group advance to the more formal specification drafting stage when timely
… if you're aware of folks interested in contributing to this agentic web development, please extend my invite to them to join the Community Group:
https://
anssik: questions, comments?
Operator specific issues
Repository: webmachinelearning/webnn
anssik: as usual, we've focused our issue discussion on operator specific issues
… these issues are scoped to a single operator or small number of operators
… these tend to reduce code complexity and improve maintainability
Simplify the operand layout support of conv2d and pooling 2d operations
anssik: issue #324 and PR #770
<gb> Pull Request 770 Remove pool2d MLRoundingType - Simplify the operand layout support of conv2d and pooling 2d operations (by fdwr)
<gb> Issue 324 Simplify the operand layout support of conv2d and pooling 2d operations (by huningxin) [feature request] [operator specific] [interop]
anssik: this PR was refreshed recently, thanks Dwayne for debugging the esoteric build errors with Dom!
… in PR review there was a question from Ningxin:
… "would dropping roundingType prevent us from supporting dynamic shape (specifying the concrete input shape at the inference time) in the future?"
Dwayne: might be easier for some models for high-level callers if you have this available, original concern was having two different ways and inconsistency
… I don't think it'd prevent us from supporting dynamic shapes? if so, there's a number of other small ops we need to consider too
… e.g. resample has two different ways to do it
Ningxin: dynamic shape is an ongoing topic, discussed with JoshuaL and Transformers.js support where many models are freeDimension aka require dynamic shape
… some are image processing models, pooling is part of those models, the pool operator
… if we need user code to specify the output size, it is hard to spec that at compilation time if the model is to be fixed at inference time
… if we put an algorithm there that can be determined at inference time
… agree with Dwayne supporting dynamic shapes should be a separate issue
Dwayne: did you have another issue related to this?
Dwayne: I will look at this after the meeting, for now we keep roundingType
Support uint8/int8 input for resample2d
anssik: issue #872
<gb> Issue 872 Support uint8/int8 input for resample2d (by huningxin) [operator specific]
anssik: a proposal from Dwayne to add uint8 to resample2d() allowed input data types
… quoting:
"For uint8, currently resample2d is specified to take float16/float32, and so uint8 couldn't reach here anyway. Though, I agree that adding uint8 to WebNN resample makes sense (and maybe even int8), since most incoming pixel data is 8-bit, and this allows the graph to directly accept pixel data to apply any transformations to floating point, without requiring each caller to manually do that outside graph processing."
https://
Dwayne: particularly useful for resample given most incoming pixel data is 8-bit, also many other ML APIs support this data type for this op
<ningxin> cross frameworks and native ML API support survey would be helpful
anssik: implementability to be surveyed, action on the group
Clarify 0D tensor supports axis-dependent operations
anssik: issue #873
<gb> Issue 873 Clarify 0D tensor (rank of 0) support for axis-dependent operations (by miaobin) [operator specific]
anssik: Bin opened an issue:
… "The current WebNN spec doesn't clearly specify whether 0D tensors (scalars) are supported as inputs for operations that take an axis input/parameter."
… Dwayne explained:
"Operators that take exactly 1 axis like {split/argMin/argMax/gather/scatter/...} are incompatible with 0D inputs because the requirement that axis < input.rank can never be satisfied.
Operators that take 0 to N axes like reduceSum/reverse/... are compatible with 0D inputs, because passing axes=[] is a viable nop (like a memcpy of 0 bytes). However, passing an explicit axes=[0] with 0D input would be invalid because axis 0 is not < input.rank."
[ Dwayne summarizes the rationale ]
anssik: would it be helpful to document this rationale in the spec?
Dwayne: the spec should have allowed rank range for these ops
… we should see all the spec tables and check anything with axis says 1 to N
<ningxin> same issue for concat, we should fix those rank range
Normalize the behavior when NaN is used for minValue or maxValue of clamp operator
anssik: issue #874
<gb> Issue 874 Normalize the behavior when NaN is used for minValue or maxValue of clamp operator (by wangw-1991) [operator specific]
anssik: Wei spotted inconsist behaviour in clamp across backends and hardware when NaN is used for MLClampOptions.minValue or MLClampOptions.maxValue
anssik: and Dwayne proposed a solution to normalize the behaviour on the WebNN side by coercing minValue:NaN to -Infinity and maxValue:NaN to Infinity
… similarly to as if these values were left out
anssik: is there a spec bug in the method steps 3 and 5 of https://
"3. Let minValue be the options.minValue if given, or Infinity otherwise."
"5. Let maxValue be the options.maxValue if given, or -Infinity otherwise."
Dwayne: sound right
<ningxin> +1
<ningxin> already prototyped
anssik: the fix is already implemented, that's good
… let's make the corresponding spec change as proposed in the issue
Minimum data type set
anssik: issue #853
<gb> Issue 853 The minimum data type set (by huningxin) [operator specific]
anssik: in this issue we agreed to "making tests for the intersecting opSupportLimits mandatory but anything else automatically skip"
… wanted to acknowledge the great work done on WPT and discuss any related WPT changes to the agreed direction
Reilly: there's some WPT tests failing, these changes should be landing soon to fix this, excited to see this development
<ningxin> https://
Wide review updates
New accessibility considerations
anssik: PR #869 reviewed and approved by the a11y group, also thanks to Dwayne for taking a look
<gb> Pull Request 869 Add Accessibility Considerations (by anssiko) [a11y-tracker]
anssik: any further comments?
… I'll squash and merge this PR
Future-proofing privacy considerations
anssik: issue #875
<gb> Issue 875 Future-proofing privacy considerations of New API feature to identify feature support per operator (by sandandsnow) [privacy-tracker]
anssik: and comments in w3cping/
<gb> CLOSED Issue 156 Web Neural Network API 2025-03-20 > 2025-06-20 (by anssiko) [CR] [REVIEW REQUESTED]
anssik: the context of this privacy feedback is opSupportLimits() API and its fingerprintability
"(1) the spec explicitly communicates that [opSupportLimits] capability doesn't add entropy, that it is just a more convenient way of discovering feature support information that can be inferred from the OS and browser version already"
"(2) To ensure the extension point for privacy controls are in place to prevent the capability from being used in the future for fingerprinting, etc."
… anssik: my proposal would be to add informative text to https://
… I could craft a PR for review and update the privacy group and seek their review
… comments?
RafaelCintron: I think any kind of limits or capability flags by definition add _some_ entropy, the question is how much entropy and how damaging it is, we don't what to allow identify on which specific machine you are, but could detect you're on a machine that has a CoreML backend
… WebGPU and WebGL have a similar capability API consider "this machine can't do float16 in shaders"
… entropy would be greater than zero but we'd do our best to minimize entropy increase
<RafaelCintron> https://
Mike: WebGPU exposes buckets and it's up to the UA to decide how much granularity to expose, e.g. capabilities of lower-end devices in one bucket
… in WebKit we use bucketing, also under-report capabilities to not allow websites to maximize capability use due to memory pressure
Reilly: the other angle is, ensure the behaviour is well-specified so that differences don't add additional fingerprinting, I know this is challenging in WebGPU and graphics APIs
Evaluate sustainability impact
anssik: issue #861
<gb> Issue 861 Evaluate sustainability impact (by anssiko) [tag-needs-resolution]
anssik: wanted to update the group on recent developments at W3C related to sustainability
… there's an intent to sign an agreement between the W3C and the Green Software Foundation (GSF) https://
… this collaboration is expected to kick off Q4-ish
… most recently GSF has focused on carbon footprint of AI systems and published a report of their priorities
Workshop report: reducing the carbon footprint of AI systems
anssik: my suggestion for this issue is to let that colloboration properly kick off and then see if we could get those new experts join us to help evaluate the sustainability impact of WebNN-powered web
… of course, the issue remains open for contributions from anyone
<zkis> Everyone: please help move forward webmachinelearning/
<gb> Issue 815 Query supported devices before graph compilation (by anssiko) [device selection]
<anssik> s/… I'd propose /anssik: I'd propose
<anssik> s/… my proposal/anssik: my proposal