Fragment identifiers in data URIs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Fragment identifiers in data URIs

Manuel Strehl-3
Hello,

I tried to find documentation about fragment identifiers for data URIs, but haven't discovered any so far. RFC 2397 seems to be quiet about the very possibility to have such identifiers. It's only noting, that "data" is specified as "uric" from 2396 (which happens to exclude "#"). Therefore it seems, the behavior of this is undefined:
   
data:<h1>%20id=%22FOO%22>ABC</h1>#FOO
I tested Firefox and Chrome, and both react differently, Firefox cutting off the data: URI at the hash, Chrome just outputting it and the the rest.

A normative rule would be great. One use case: SVG filters embedded in CSS stylesheets. CSS filters can be used like this:
    filter: url(svg-url#element-id);
But we cannot address them, when the SVG is embedded as data URI:
    filter:
url(data:image/svg+xml,.....id="FOO".....#FOO);
Cheers,
Manuel
Reply | Threaded
Open this post in threaded view
|

Re: Fragment identifiers in data URIs

Julian Reschke
On 2013-07-18 16:19, Manuel Strehl wrote:

> Hello,
>
> I tried to find documentation about fragment identifiers for data URIs,
> but haven't discovered any so far. RFC 2397 seems to be quiet about the
> very possibility to have such identifiers. It's only noting, that "data"
> is specified as "uric" from 2396 (which happens to exclude "#").
> Therefore it seems, the behavior of this is undefined:
>
>
> data:<h1>%20id=%22FOO%22>ABC</h1>#FOO

No, it's not undefined. But yes, RFC 2397 really needs an update to
align it with RFC 3986.

> I tested Firefox and Chrome, and both react differently, Firefox cutting
> off the data: URI at the hash, Chrome just outputting it and the the rest.

That's a bug in Chrome. See
<https://code.google.com/p/chromium/issues/detail?id=123004>.

 > ...

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: Fragment identifiers in data URIs

Manuel Strehl-3
>> data:<h1>%20id=%22FOO%22>ABC</h1>#FOO
>
> No, it's not undefined. But yes, RFC 2397 really needs an update to
> align it with RFC 3986.

Thanks for the answer. With undefined I mean "this string is not something, that's defined in RFC 2397". Apart from that, could you point me to any normative statement about "#" in data URIs? (I've got the impression from RFC 3986, that "data" in 2397 could be aligned with "hier-part" in 3986, which'd allow query parts and fragment identifiers, but I'm not sure, if that's the correct way to read it.)

> That's a bug in Chrome. See
> <https://code.google.com/p/chromium/issues/detail?id=123004>.

Thanks for pointing me to that report!

Cheers,
Manuel
Reply | Threaded
Open this post in threaded view
|

Re: Fragment identifiers in data URIs

Julian Reschke
On 2013-07-18 16:48, Manuel Strehl wrote:

>  >> data:<h1>%20id=%22FOO%22>ABC</h1>#FOO
>  >
>  > No, it's not undefined. But yes, RFC 2397 really needs an update to
>  > align it with RFC 3986.
>
> Thanks for the answer. With undefined I mean "this string is not
> something, that's defined in RFC 2397". Apart from that, could you point
> me to any normative statement about "#" in data URIs? (I've got the
> impression from RFC 3986, that "data" in 2397 could be aligned with
> "hier-part" in 3986, which'd allow query parts and fragment identifiers,
> but I'm not sure, if that's the correct way to read it.)

Data URIs are URIs; URI syntax is defined in RFC 3986. RFC 2397 only
defines the scheme-specific part; thus it doesn't mention fragment
identifiers (and yes, it should, because they way it's written causes
confusion). See also <http://www.rfc-editor.org/errata_search.php?rfc=2397>.

> ...

Best regards, Julian