HTML attribute for template URLs?

[LeaVerou]

Per https://www.w3.org/TR/design-principles/#naming-of-url-attributes , attributes for URLs should be called href or src unless there is good reason.

MapML uses tref for URL templates like : https://maps4html.org/MapML-Specification/spec/#the-link-element-0

Example:

<maplink rel="tile" tref="https://tile.openstreetmap.org/{z}/{x}/{y}.png"></maplink>

Should they be using href instead? Is there any guidance or precedent for attributes containing URL templates?

[jyasskin]

I don't know of any precedents for URL templates in markup, but that doesn't mean there aren't any.

If I'm reading the spec right, this use is for loading tile images into a map. That puts it in the "causes the resource at the given URL to be loaded" category from https://www.w3.org/TR/design-principles/#naming-of-url-attributes, meaning it should be src instead of href (modulo any adjustments for being a template instead of a URL). Also, maybe it'd make more sense to use <source> instead of <link> here?

[LeaVerou]

Great point re:src (and <source>)! But the core question still stands: should they be using src or some variant, e.g. tsrc?

[prushforth]

If I'm reading the spec right, this use is for loading tile images into a map.

Yes, as well as other resources. The proposed <extent> element acts like a "map form", in that as it gets "filled out" and submitted (to the URL created by supplying values to the URL template in the tref attribute), the child <link> element fetches and loads the appropriate resource as specified by the rel attribute, processing it according to its type attribute, if specified. <link> and <source> are both void elements, so no difference there, but at the time I wrote the spec I thought that this implementation of a URL fit better as an extension of <link> than of <source>. Also, if I recall correctly, <source> implies, or can imply, a choice among resources that could be loaded, and this situation didn't seem to call for that.

That puts it in the "causes the resource at the given URL to be loaded" category from https://www.w3.org/TR/design-principles/#naming-of-url-attributes, meaning it should be src instead of href (modulo any adjustments for being a template instead of a URL).

That was actually why a new attribute tref was proposed, because before template processing was completed, it shouldn't be considered a URL, and after processing it could be used as the value of the sibling .href property (perhaps). Anyway I imagine that could be applied to the <source src> attribute, with similar considerations.

In sum, <link> was used because of the importance of rel in this situation and similarity to stylesheet and icon resources using <link>.

I don't know of any precedents for URL templates in markup, but that doesn't mean there aren't any.

I could not come up with a better way to get the values from the map into the URL. I started by having an action attribute on <extent>, but this turns out to be way more implementable and efficient, and similar to how web maps actually work already.

[mikewest]

Somewhat tangential to the naming discussion, but I wonder whether any discussion of URL template strings should point to URLPattern's syntax as something with which it would be helpful to encourage compatibility? That is, it would be nice if the template worked both to generate a URL and to match aganst/extract data from a URL.

[jyasskin]

@mikewest It would be nice if the same syntax supported both matching and generation, but I didn't see generation support in URLPattern. Am I missing something?

[mikewest]

No, there's no generation support that I know of. I'm really just suggesting that if it's reasonable to define the names folks should use when describing URL templates, it's likely also reasonably to suggest that we build a thing into the platform that makes substitution into those templates possible. I was imagining a model in which a strict subset of URLPattern's syntax (really just matching group names, I think) could act as substitution anchors in the template. That's possible only if the syntax is equivalent on both sides.

Just a tangental suggestion for the future. :)

[wanderview]

Its a long requested feature in URLPattern (with recent discussion): whatwg/urlpattern#73

cc @domenic @sisidovski

[LeaVerou]

Btw I opened w3ctag/design-principles#579 to track the higher level issue of whether we need two different standards for describing URL patterns in the web platform or whether we should steer folks towards URLPattern for matching and URI Template for generation (in which case MapML is doing the right thing).

[domenic]

Chromium is actively prototyping generation as well, because of a couple of recent platform features that have asked for it. So I'm hopeful we can converge on a single syntax (URLPattern).

[jyasskin]

We (me, @lolaodelola, @ylafon, @matatk, @dandclark) talked about it in a TAG breakout today, and there was a sense that just adding t to href or src could be confusing. Perhaps it would make sense to use srctemplate (or hreftemplate when it's about navigations)?

We also generally agreed that we wouldn't be confident enough to make this a full principle with just this one use so far. It'll be good for MapML to keep talking to the community about how to name these, but there's a good chance that we'll learn something from MapML deployment that'll give the next instance a good reason to diverge somewhat.

[domenic]

It's worth noting that HTML has a (very old, not great) precedent for this with registerProtocolHandler(). The processing model is: parse the input as a URL string with some extra validation, then serialize it, then replace the first instance of the string "%s" with the passed-in value, then re-parse as a URL.

Hopefully nobody else does this! But if any guidelines get written up here, it's probably worth pointing out as a precedent.

[jyasskin]

Good point. That also reminds me that the OpenSearch protocol exists, with a templating system described at https://github.com/dewitt/opensearch/blob/master/opensearch-1-1-draft-6.md#opensearch-url-template-syntax. That system informed the URI Templates design, and it includes an {optionalParam?} syntax that's not in RFC 6570.