id attribute isn’t good enough for RDFa ‘lite’, apparently it needs the new
Yesterday we at Vísar tested the neat SVG image element hack on all the devices and browsers we had at hand to see how it performed and whether or not it was viable to use in production.
Given this markup:
<svg> <image xlink:href="http://example.com/the-image.svg" src="http://example.com/the-image.png" width="100" height="100" /> </svg>
Here’s a table of what each browser+device downloaded:
|Mob. Safari iOS 4.2.1||PNG|
|Mob. Safari iOS 6.1.3||SVG|
|Chrome 28 Mac||SVG|
|Safari 5.1.9 Mac||SVG|
|Safari 6.0.5 Mac||SVG|
|Firefox 26 Mac||SVG|
|Firefox 22 Mac||SVG|
|Kindle (3rd gen)||PNG|
Note that the Kindle downloaded the PNG despite having pretty good SVG support. Tests carried out locally by watching the Django request logs.
At first, this looked perfect — browsers which supported SVG only downloaded the SVG (apart from IE 10), and other browsers just got the PNG. However, it seems that SVG
image elements can’t be sized with percentages, meaning our flexible layouts were never going to work. I tried to fix it using the dreaded
viewBox and user units (as I have previously to compensate for percentage-based units not being allowed in SVG paths), but that just led to everything being completely the wrong size.
So, (unless someone can show me how to fix this), whilst we think this is a great hack, it’s not going to work out for our product due to the weirdness of SVG sizing limitations.
#todo: write a browser extension which overrides Facebook’s über-shady LinkshimAsyncLink rewriting. What you see should be what you click.
Bookmarklet of the day: jsgif for giving GIFs controls. Pause, skip, reverse — it’s all there and not too slow either!
MDN says FF has “implemented” the SVG text module, then goes on to list 13 presentation attributes which “don’t work”. How exactly does that count as implementing the module? Grr. This is why
@supports is doomed.
Just in case anyone was wondering, the “HA HA HA SOUP” bookmark in those gifs is this bookmarklet:
document.createTreeWalker is actually pretty great.
Musing on why we only turn to natural language for defining the behaviour of out applications instead of the business logic itself.
Rough ideas: gist.github.com/barnabywalters/6188240
Find of the day: everything2.com
Trying to think of a good reason to make a #js library called bach.js
Aaron Parecki seems like that would be blurring the line between presentation and behaviour — where do you stop? Weather media queries? Proximity? Acceleration?
Pondering the utility of a “draft blog post titles” listing on my homepage, partly as a teaser, partly as a reminder to myself
Laughing at the @twitter docs using “t.co” and “best practices” in the same sentence: dev.twitter.com/docs/tco-url-wrapper/best-practices
I’m thinking the time might have come to write a wrapper around #php DOMDocument which actually makes it usable. Thoughts:
querySelectorAllare implemented for both the document and individual elements via Symfony XPath → CSS converter and relative XPath queries