Meeting minutes
Anssi: welcome back after the summer break, I hope you had a chance to recharge and enjoy some time off
… and welcome to the new participants joining us since our last meeting in June:
… Ruoxi Ran and Philippe Le Hegaret from W3C
… Ruoxi joins as the new W3C Staff Contact, replacing Dom who took the interim CEO role
… Lingyan Zhao from Microsoft
… Amit Varia from Google
… Matt Kubej from Shopify
… Stephan Morris from See Me Please, an accessibility company
… welcome all!
Announcements
TPAC 2026 F2F
Anssi: WebML WG F2F confirmed for Monday 26 Oct 2026, in Dublin Ireland
… first day of the TPAC 2026 week 26-30 Oct
Anssi: a few logistics things to handle, please register for TPAC 2026 and book your travel and accommodation as soon as you can
… register latest by 01 October 2026:
Anssi: I recommend booking the hotel as soon as possible, as Dublin is a popular destination and hotels fill up quickly, discount rate provided at the meeting hotel:
Anssi: our F2F Agenda is a GH issue to allow the community chime in more easily with suggestions, this is considered a living agenda and will be updated as we get closer to the meeting date
<gb> Issue 39 WebML WG/CG F2F Agenda - TPAC 2026 (Dublin, Ireland) (by anssiko)
Anssi: the expectation is we use the F2F to have both discussions on the short-term issues as well as long-term directions
… participants can propose to share demos and implementation updates in a live setting
… we will have meeting participants from across the W3C community, so this is a great opportunity to share your work with wider audience
Anssi: the Community Group meets on Tuesday, 27 October 2026, right after the Working Group meeting
… I encourage all participants to attend both days to get the full picture of the WebML community
Anssi: questions, comments?
New charter proposal review
Anssi: on our June 18 meeting I shared the new charter proposal for this Working Group and called for review
<gb> PR 829 [wg/webmachinelearning] Adds WebMCP in scope (by plehegar)
Anssi: this proposal adds WebMCP as a new WebML WG deliverable, graduating from WebML CG incubation
… WebML WG and WebML CG work closely together, and this charter update prepared by W3C Team reflects that relationship
… as for the WebMCP progress
… WebML CG has initiated horizontal group review for WebMCP, starting with the Technical Architecture, Security and Privacy groups, great collaborations ongoing on that front
… WebML CG has also been actively engaging with the developer community and has received encouraging feedback from developers
… Chrome Origin Trial is ongoing and adoption in the industry is growing based on data shared with the group
… if anyone has further input on the charter proposal at this point, I encourage you to share it to ensure W3C Team can consider your feedback
Reilly: given my experience in the CG, when we add WebMCP as a deliverable, we should schedule a separate meeting for WebMCP given it is highly active work
Anssi: we will consider that
MikeW: I wanted to note that from Apple's side we have an opposing WebKit position
Anssi: noted
[no further feedback or comments recorded]
RESOLUTION: WebML WG has reviewed the charter proposal and approves the direction. WebKit position duly noted.
Anssi: thank you for your support in advancing this important deliverable
… it is my pleasure to shepherd this work
Web Neural Network API
Repository: webmachinelearning/webnn
Dynamic shapes
<gb> PR 945 Add dynamic shape explainer (by miaobin)
<gb> Issue 883 Support flexible input sizes (by huningxin) [feature request] [operator specific]
Anssi: this important feature enables graph dimensions to remain unresolved during compilation
… and instead derive the concrete values from input tensors at dispatch time
… this feature is required by many transformer decoders, vision encoders, generative image models
… the lack of this feature means frameworks have had to implement workarounds that incur significant performance penalty, degrading user experience
… Bin and Wangming have contributed an explainer and Bin has produced an implementation of this feature to inform the design
… Honry also developed ORT WebNN backend support for this feature for end-to-end testing
… I asked the group to review the explainer
… it is a well-written document with many details
… next, Ningxin will share the implementation experience and introduce the key contributions of the explainer
… I'd expect we'd then want to have a discussion on the open questions documented in the explainer:
Ningxin: Bin and Wanming produced a few slides, I will present them
[Ningxin presents slides]
Ningxin: problem statement is MLOperand static shape constraint
… goals to allow a single compiled MLGraph, model dimension as static sizes, defer shape validation to dispatch, allow frameworks learn concrete shapes
… as for non-goals, we do not resolve shapes from input tensor data, we do not redefine operator semantics
[sample code shared for before and after with variable sequence length]
Ningxin: proposed WebIDL changes MLDimension, MLInputOperandDescriptor
… input dimensions representations: static size, named dynamic dimension, unnamed dynamic dimension, unranked operands
… computeShapes() API to perform early shape inference and folding without executing the graph
… if the framework knowns the output tensor shape, this is an optional API to use
… static vs. dynamic output shape example code demonstrates the computeShapes() usage
… new operators introduced to fulfill the key use cases: shape(), squeeze(), unsqueeze(), reshapeTo2d(), and dynamic variants for existing shape-related ops
… reshape() vs. reshapeDynamic(), the latter is a dynamic mirror of its static counterpart to reduce implementation complexity
[WebIDL comparison diff]
Ningxin: deferred validation at build time only check for the most basic errors, e.g. data type mismatch
… vs. shape inference & validation at dispatch time
… where runtime propagates concrete shapes over the whole graph and validates constraints
Ningxin: future consideration include bounded (min/maxSize) dimensions and fine-grained shape queries via rank() and dimension()
… implementation status, Chromium POC with ORT backend, ORT WebNN EP POC, 56 real-world models from Transformers.js top model list validated
… backend mapping discussed in the explainer, ORT, LiteRT and Core ML, welcoming contributions
<Zakim> reillyg, you wanted to ask about reshapeDynamic and restricting to only dynamic dimensions.
Reilly: a question on reshapeDynamic, it takes MLOperand that I assume is a tensor used as a shape, I think that makes sense, wondering if we want to restrict the dimension updates to only dimensions that are in fact dynamic
Ningxin: validation happens at dispatch time, input tensor specified by the user
… validation of all shapes would be straight-forward, similarly to how we do that at build time
… some operators are used to compute the shape, new dynamic shape comes from dynamic one, followed by some arithmetic operator to add a value to size, then shape() can produce a tensor containing the shape information
… when that shape comes to reshapeDynamic, at that time, we can do validation with all concrete values
… dynamic dimensions would be specified by the user
Reilly: about implementablity, sometimes this may require CPU fallback for graph segments that may change
Ningxin: we still hold WebNN validation at dispatch time to know it is safe, what you mentioned is up to the inference engine, some engines may offload back to the CPU
Reilly: I guess my questions is, we can do some validation ahead of time, can also do validation for specific shape, in reshapeDynamic variant we can't do validation of a specific shape because that is determined midway
Ningxin: we do shape compute at WebNN level before we pass to inference engine
MarkusT: thank you Ningxin & team for this work, I will implement this in RustNN to provide more implementation experience
Ningxin: we want to get the feedback from this group and implementability on LiteRT and Core ML at this stage
… when the explainer is approved with the group, could we start landing the implementation in smaller bits then?
Reilly: yes, want to make sure to consider all possible security issues
WebGPU interop: buffering and device selection
Anssi: PR #942
<gb> PR 942 Add initial WebNN-WebGPU Interop specification (by bbernhar)
Anssi: I believe Bryan is on a well-deserved vacation
… we'll defer this topic for later
Low-precision floating-point data types
<gb> PR 938 Add low-precision floating point data types explainer (by mklimenko-nv)
<gb> Issue 930 RFE: Add support for more floating point low-precision ML data types (`bfloat16`, `fp8`, `nvfp4`) (by mtavenrath) [opset] [feature request] [Agenda+]
Anssi: we've received new survey results to inform new data type selection since last discussion, table in Dwayne's comment updated:
webmachinelearning/
<gb> Issue 930 RFE: Add support for more floating point low-precision ML data types (`bfloat16`, `fp8`, `nvfp4`) (by mtavenrath) [opset] [feature request] [Agenda+]
Anssi: looking at the survey results, the group has a clearer view into low-precision data types to be supported in WebNN
… based on these results, Mikhail from NVIDIA has contributed a Low Precision Data Types Explainer, ready for review in PR #938
Low Precision Data Types Explainer (preview)
Mikhail: we see low-precision data types important for WebNN
… this explainer proposes:
… - new WebNN data types for MLOperandDataType: bfloat16 and float8 (a shorthand for float8e4m3)
… - a new scale descriptor for quantization, enum MLQuantizationScheme { "affine", "symmetric-float", "blockwise-float" } via MLQuantizationOptions.scheme
… other proposed changes include:
… - updates to the tensor limits table for allowed data types for different operands
… - a simplified buffer validation mechanism for low-precision floating-point data types
Anssi: Dwayne has already provided review comments, and I encourage the other group participants to review and provide feedback on this important feature
Anssi: any other comments or questions on this topic?
Reilly: I have no concerns with this feature
MarkusT: block quantization, people have been asking for this, but not all backends support this, is this something the group cares about?
Reilly: how much we allow pre-quantization before building the graph
… we could support a lot of input formats, dequantizing them before passing, but this changes performance and memory characteristics of the model
… quantized before, backends would need to quantize or dequantize on their own?
Reilly: two approaches, either fully quantized, or effectively do loop transformation, moving quantization inside the loop in the kernel, as a memory bandwidth performance optimization
… tradeoff of having WebNN implementation dequantize inputs that are in formats not supported by underlying framework, we're not getting the performance or memory benefit
MarkusT: if we accept that dequantization could happens this way, we could support more data types
Reilly: no strong opinion on this topic
MarkusT: do ORT and LiteRT support block quantization is the question
… we're careful to propose a very limited set of data types