I can't find anywhere the specs for the use of an @ in srcset
https://html.spec.whatwg.org/multipage/embedded-content.html#embedded-content

Thats right. Now I think it's not a failure of the plugin. In the tutorials I bookmarked the authors writing it and Google (1) and Apple (2) doing it also. So in the theory the plugin works right like the standard.

1: https://developers.google.com/web/fundamentals/media/images/images-in-markup#use-relative-sizes-for-images
2: https://developer.apple.com/library/mac/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Optimizing/Optimizing.html

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4995.

Such usage does not appear in the spec, agreed, and it isn't in any examples at: http://responsiveimages.org/ so in fact I don't think that is ideal markup pattern for a . I've used the picture element before and nevr noticed an issue, simply because I followed the markup of the spec and didn't adopt a @2x. naming pattern.

That said, this is not an abnormal usage or something that would be totally unexpected so I think we should consider trying to fix the cloaking plugin to ignore @ appearing within .

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4995.

AFAIK, "@" is a valid (if rare)character in a filename, so whether it is used in a particular web spec or not is really irrelevant, valid filenames should not be converted to email links and mangled.
This comment might appear twice due to network issue.

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4995.

The @ symbol is a valid character for a filename. However it's a reserved character in an URI, and thus shouldn't be used for filenames which end up as part of an URI.
See RFC 3986 Section 2.2 for reserved characters and 2.3 for unreserved ones.

Characters that are allowed in a URI but do not have a reserved
purpose are called unreserved. These include uppercase and lowercase
letters, decimal digits, hyphen, period, underscore, and tilde.

Interesting enough I learned in #5001 that Apple actually seem to require the @ in the filename. Even if it's a reserved character according to the RFC.
Not sure what to think about this...

I'd say that Apple is wrong in this case and, I suspect, they will change their position in future as the <picture> spec becomes more widely adopted.

What if you named your image like large@@2x.jpg? This is pretty weird and silly but it should be enough to avoid being mistaken for an email address.

The RFC Bakual linked to (thanks, it was actually useful) flat out says the correct solution to URI reserved characters in filenames is to use percent encoding. Then again IIRC the RFC is somewhat detached from what browsers actually support. Percent encoding SHOULD still work, though.

The real question is whether this should be handled by the emailcloak or if it should be taken on trust that whatever created the URI encoded it properly. Since the only reason this causes an issue is that emailcloak does something off-spec with @ characters, my vote would be to handle it. But my regexp-fu is weak, so my vote doesn't really count.

I am curious to see what happens when the mailto is attached to such an image.
What would be the code? Would it work when the backup image is not used?
Also, it seems that using the @ may not be limited to <picture> but also could be used directly in an <img

Hello @Bloggerschmidt

Thank you for your contribution.

The last comment here was on November 7th 2014. I have not been able to reproduce the issue with the current code.
I am closing this issue but feel free to open if you believe it needs further attention.

Thanks for understanding!