W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2011

[whatwg] Proposal for improved handling of '#' inside of data URIs

From: Nils Dagsson Moskopp <nils@dieweltistgarnichtso.net>
Date: Sun, 11 Sep 2011 21:01:54 +0200
Message-ID: <20110911210154.63f216ec@desudesudesu>
"Michael A. Puls II" <shadow2531 at gmail.com> schrieb am Sun, 11 Sep 2011
13:54:01 -0400:

> On Sun, 11 Sep 2011 11:30:07 -0400, Daniel Holbert
> <dholbert at mozilla.com> wrote:
> > [?]
> >
> >    data:text/html,<i>here is some italic text<i>
> I don't really like that though as it's not portable. If I wanted to
> copy that from the address field and paste it into a plain-text
> document, it'd look funny like this:
> <data:text/html,<i>here is some italic text<i>>
> And, for mail clients that linkify links in plain-text messages, I
> can see that going wrong with the link (the clickable, underlined
> part and href) ending up as only "data:text/html,<i".

Nitpicking: I'd actually expect it to be ?data:text/html,?.

> > So we can proactively check for >/< characters anywhere after the
> > "#", and if we find them, then we can pretty safely assume that the
> > author intended for the "#" to be part of the document, rather than
> > a fragment-ID delimiter.
> I still don't like it personally as it further encourages authors to
> not encode their data and is not portable. But, if this is to happen,
> it should definitely be limited to mime types that contain markup.
> It wouldn't be useful for data:text/plain (how would you
> differentiate in that case?). And, for text/javascript and text/css
> etc., some other type of lookahead characters(s) would have to be
> used.

I sincerely hope this observation pretty much kills the original
proposal on the spot. Not only would specifying that stuff involve lots
of black magic, all talks about author expectations go off the rails as
soon as interpretation of the data URI depends on the mime type.

Nils Dagsson Moskopp // erlehmann
Received on Sunday, 11 September 2011 12:01:54 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:36 UTC