What we have is an IMG Tag of form:
<img class="xr_rn_ xr_rnsp_ xr_ap xr_rno_http://localhost:8000/virt82a17d19/index_htm_files/2.png " id="Artistes" src="http://localhost:8000/virt82a17d19/index_htm_files/2@2x.png" alt="" title="" style="left:600px;top:322px;width:176px;height:133 px;">
Never having looked into the coding, I imagine the equivalent as a dialogue between the browser and the HTML file.
Little Browser: What have you got?
Code: Well I have an image here in my src that you I've started to downloaded -
2@2x.png. Can you use it?
Little Browser: Well, it's a bit too rich for me.
Code: OK. use this other one that you'll have to download instead - 2.png.
Little Browser: That's OK. Pity about the first one though. My Big Browser eats Retina images for breakfast.
Big Browser: Yup! Tasty too. I throw all the tiddlers back. In fact, I never see them.
What Big Browser does is downloads all the @2x images and roe.js cancels the others.
It is possible that as the @2x render starts for the first image, roe.js checks with Little Browser and uses JavaScript to switch round all the srcs to the 96dpi versions.
I would save all my images at 192dpi and just offer up <img id="Artistes" src="http://localhost:8000/virt82a17d19/index_htm_files/2.png" alt="" title="" style="width:100%; height:100%;">.
Retina Browsers will render at the intrinsic size and non-Retina ones will have to scaled accordingly.
The downside is you are sending an image that is four time that required.
This may not be a problem if you are also using the same image as a larger pop-up, a thumbnail, in more than one location and in Variants, all at different sizes.
Xara produces different intrinsic sizes for all of these and then, additionally, all the Retina equivalents.
Each HTML fetch has a lag and the overall page render can end up slower.
To do what you are suggesting by adding the the ClassName "xr_xn_" but you also have to knit in the non-Retina path and provide both images.
Edit one and you must edit the other. Change the path...
Acorn
Bookmarks