Not a trace of said data in the APIs I'm afraid, so for now it's a no. But I'll see what I can do through other means.

Float weirdness and attribute duplication have been fixed with a code transplant from TF2B proper. (Both bugs are result of API weirdness (Thanks Valve))

As for sheen/killstreaker, the answer is likely no as there is probably no API support for listing that data. If you could provide a screenshot of what the tooltip should be and an reference item of TF2B however I can at least take a look.

That feature isn't really in sync with the modern storefronts, so it not working is to be expected. It needs reimplementing.

Seemed to be an API/Memcached issue, it's fixed now.

Oops, that JS shouldn't have been pushed out. Fixed the tooltips and etc, got a few other things that'll need a tweak though.

Will take a look at australium icons later.

EDIT: Australium icons should mostly be visible now, a certain person who shall remain nameless may have passed me the wrong prefix names for the model icons.

EDIT2: Aaaand fixed that weirdness with the gifts on the first page of that linked profile. Keep the bugs rolling in people. (Preferably in a new thread per issue)

I've "fixed" it for the meantime with the prefixed property while people gradually update to Fx 29 and the Australis drama settles down.

I highly dislike polluting CSS with prefixed properties, once the aforementioned transition and drama have passed - said property will probably be nuked.

Doing a quick check on the CSS property that fixed the issue (box-sizing) it seems that Firefox was rather slow on the uptake, Mozilla only added unprefixed support as of Fx 29.

Details: http://caniuse.com/css3-boxsizing

@Tresmer, when you say Fx 28 was broken at any zoom level, do you mean the default page view too? (i.e. 100% zoom)

This bug has now been fixed.

However I will add that this particular area of TF2B is going to be undergoing some changes/adjustments, so things may break again briefly in the future.

Oh believe me, I've tried. As have other site owners.

We either need to make our voices louder to be heard, or make a better case for what we're asking for. Personally I tend to view the latter as being more inline with how Valve operates.

Ah well, I'll see what I can do, and on the last point - Thanks!

I wouldn't rule it out entirely. It's just a matter of contacting the right people and making a case for why them taking the time to work on said APIs is valuable for both Valve and the community at large.