W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2013

Re: [whatwg] The src-N proposal

From: Qebui Nehebkau <qebui.nehebkau+whatwg@gmail.com>
Date: Tue, 19 Nov 2013 01:28:31 +0000
Message-ID: <CAF_oMa2sXKOr2YZBDkBdnqyjG2SLLmkowFV3ARgh2h9AhkueXA@mail.gmail.com>
To: whatwg@lists.whatwg.org
On 18 November 2013 23.18.37, Bruno Racineux wrote:
> For all it's worth, my outside take on both of srcset and src-N has always
> been that it's not DRY enough, and more unnecessary bloat to pages, due
> the long unnecessary repetition of img-path(s) for each img of similar
> size, repeating the same pattern over and over for image galleries, and
> lack of src-template (or regex pattern) approach to this problem.

I agree for the most part, but URL templating, including with regexps,
is definitely not the way to solve this problem. Although it's probably
true that most uses will have very similar URLs with only minor changes
for each image, the spec shouldn't require that, nor should it be
difficult for authors to do otherwise. Many people seem to find regexps
difficult to understand, and the regexps involved would only get more
difficult as the complexity of URL patterns increases. Forcing authors
to use them sounds like a great way to guarantee cargo-cult programming,
where authors will just drop in a regexp they've seen before without any
understanding of why it works the way it does or how to change it to
suit their needs. This seems obviously undesirable.

Personally (and I'm not a browser implementor or anything), I think the
ideal solution to the URL repetition problem would be the case where
authors can supply multiple base URLs for the document, and the choice
of base URL is made either contextually or according to some replaced
token in the relative URL string. The replaced token case could
potentially be backed up by server-side redirection, I guess. This would
be much more generally useful and not require people to engage with
excessively complex syntaxes or name their files according to a rigid
Received on Tuesday, 19 November 2013 01:29:16 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:14 UTC