As this looks like a feature request , marking it as untriaged for further inputs on this.

Thanks!

Looks like the spec should be updated first: https://docs.google.com/document/d/1U1RGAehQwRypUTovF1KRlpiOFze0b-_2gc6fAH0KY0k/edit

I don't think the spec needs to be updated at all; it already has everything it needs to support my request, I believe.

For example, it was originally conceived for JS source-mapping, but without any changes to the spec it's already being used for CSS source-mapping. So it seems HTML source-mapping could follow the same lines.

The sourcemap v3 spec is intentionally designed as "language agnostic", meaning it can basically work to map any type of source files (not just JS). The mapping is simply line and column based, so it should be possible to use it to map between any two text file formats. Some quotes from the spec that highlight this:

"...although the format itself is language agnostic"

"While the source map format is intended to be language and platform agnostic..."

"There are two suggested ways to link source maps to the output.  The first requires server support to add a HTTP header and the second requires an annotation in the source."

"This recommendation works well for JavaScript, it is expected that other source files will have other conventions: CSS  /*# sourceMappingURL=<url> */"

-------

Am I missing something that this spec couldn't handle HTML/DOM to template source-mapping?

Some more info (from a thread on mozilla bug tracker for this same kind of feature):

It may perhaps be more appropriate to think about this feature in reference to the "View Source" tool instead of the DOM inspector. For some pages, the DOM is constantly changing, so keeping a mapping back from live DOM elements to the original source (templates) may not make sense. But it should be straightforward to map from the originally delivered HTML to the original source. Of course, just like with code, it'd be helpful if I could see both the actual HTML the page was built from AND the original template content. Switching between them is quite useful to handle different use cases.

Alternately, I would be OK if the DOM Inspector had an "Original Source" kind of tab added to it. The default view of the inspector can still be the live DOM, but I can click to switch into that other mode if I'm trying to see where the page state came from. For example, there may very well be sites where the dynamic nature of the DOM isn't much if any, so the original source templates are closely related to the current state of the page.

I should also mention that some sites (like mine) not only are delivered by templates from the server, but also use dynamic templates in page to create dynamic DOM elements. So in that scenario, if the page/app had a way to "inject" the sourcemaps info dynamically for each newly templated item (maybe on a per-DOM-element basis), then it would still be reasonable to still show these templates in the DOM inspector instead of only in view-source.

We don't have cycles to work on this in the upcoming year. But we'll be happy to review patches!

If you think this is important and should be prioritized, please  re-file with justification.

Thanks.