TL;DR The combination of these two PRs #645 and #646 make source maps normative and I want to make sure we are aware of it when we make decisions on them.

While I very much agree with the sentiment in this issue that this is a good thing, I believe it will be the first time that source maps are added in an application-visible way to the Web platform. AFAIK previous usages only interact with the devtools and are not observable programmatically.

The addition of sourcemaps here and the mapped* members in #646 mean that the interpretation of sourcemaps by the browser is visible to the application and we now need to have a normative specification of sourcemaps and of the relationship between non-mapped and mapped source position. That's unless we say that mapped* are pure hints to the application and cannot be relied to be portable.

If we don't make them normative then I wonder what would prevent them becoming vendor-specified opaque blobs?

There's already a cross-browser spec for this, and the way I referenced it here does make it normative.
The existing spec is for ensuring that sourcemaps are cross-UA interoperable. Though there's no programatic way to validate this at the moment (I think?), there's pre-existing vested interest by UAs in ensuring cross-compatibility.
I think the main difference here is that we're making this cross-compatibility observable, but I don't think we need much more work do make this happen. I suppose we should reach out to our source-maps colleagues and check!

Discussed at the 2020-04-21 meeting.

As I was talking about on the call, I think the solution used by source maps for JavaScript is a good one: there's no breakable API surface that cares about what the format of the source map is. The browsers need only to support it in their dev tools. If the application wants to apply source mapping to errors, it can do so with a userspace source map library. They ship their source maps along with that library so there's no possibility of breakage.

Taking that approach is compatible with this PR as-is, but requires mappedLine et al to be removed from #646.

Did you happen to get feedback from your team on that approach?

The case we’re worried about is browser A switches to some proprietary source map format, an author develops a page in that browser using this proprietary format, someone else opens that page in Safari’s Web Inspector, sees unreadable shader contents in the relevant panel, and thinks that Safai’s dev tools are worse than browser A's.

But that's exactly the situation with JavaScript source maps. What makes WGSL special?

I also assume each browser would probably reuse the implementation it uses for JS for WGSL, so I really don't think WGSL source maps would diverge faster than JS source maps. Unless we are talking about some format that's somehow conceptually far better than source maps, in which case a browser's dev tools would actually be concretely better for supporting that new format.

But that's exactly the situation with JavaScript source maps. What makes WGSL special?

Our representatives to ECMA are concerned about this too.

@jdashg do you think this should be discussed again at the WebGPU meeting or the WGSL meeting?

For topics that straddle the API/shader boundary, I think the main group is best. In my mind the language meetings are like a sub-group that reports up to the main group, so topics that concern everyone would default to the full main CG meeting.

One idea that came up in a discussion with @jdashg is making this an extension. That would allow us to still test this with the CTS, and yet allow to iterate on that later. For example, if sourcemap v4 standard comes out, we can just release a new extension.