It's a fair request but I'd like to see more data on the usage and nature of all those far-less-common vendor keywords. Do any of them use it for the standards-based features that Modernizr tests for? From the WAP examples, for instance, I can tell we don't need to support that keyword because it doesn't get used for any CSS3 features that Modernizr tests.

Until someone provides a distinct implementation that overlaps with Modernizr's tests, I'm labeling this Future.

How much longer does it take to execute when adding these in?

Gooood question. There will be a performance hit for sure, but I don't have a handle on if its a 1% or 10% difference.

An example where this is needed - Opera 10.5 has added full support for CSS transitions using -o-transition but Modernizr fails it.

Beyond that, one can't predict what future properties will be implemented using prefixes by any vendor, so even if there weren't any present examples, surely this is a reasonable request as a future-proofing feature.

The -o- vendor keyword is already part of Modernizr; if it fails in Opera 10.5 then there's either a bug in the Modernizr code or Opera's implementation isn't according to spec.

Given that Opera's support isn't in 10.5 but in Presto 2.3, which isn't publicly available yet (AFAIK), I can't test this either way. If you happen to have access to the development version of Opera with Presto 2.3, could you make a test case of CSS Transitions being implemented that works in your version of Opera? Perhaps we can use that (even without access to that dev Opera version) to deduce where the problem lies.

with css transitions we're currently only testing "transitionProperty" but "oTransition" et all are not being tested. pretty sure this is a trivial fix.

If Presto 2.3 doesn't implement transitionProperty similar to how other browsers implement it, we'll have to revisit this once we get access to a version of Opera with Presto 2.3 so that we can assess the way Modernizr will handle this case. I'm not in favor of simply following each browser's individual direction; this stuff is specced and, whilst DOM properties aren't always specced along, much of this stuff is thus far implemented relatively synchronously between Mozilla and WebKit, and I want to encourage that for Opera and IE as well.

@kuruas

if it fails in Opera 10.5 then there's either a bug in the Modernizr code or Opera's implementation isn't according to spec.

I haven't compared implementations extensively myself, but I have read (somewhere, but it escapes me now, I'll try and find it) that Opera's implementation is different, but closer to spec than Webkits. Given the spec is unfinished, it may be a implementation of current spec, while Webkit was an implementation of a previous iteration of spec. I don't know.

Opera's support isn't in 10.5 but in Presto 2.3, which isn't publicly available yet (AFAIK)

Presto 2.3 has been publicly available since September, Presto 2.4 has been publicly available since November, Presto 2.5 is in Opera 10.5 released (as an experimental build) yesterday.

I'm not in favor of simply following each browser's individual direction; this stuff is specced and, whilst DOM properties aren't always specced along, much of this stuff is thus far implemented relatively synchronously between Mozilla and WebKit, and I want to encourage that for Opera and IE as well.

I'm not an Opera dev, just a user and web dev (stumbled across this when testing Modernizr on findmebyip.com) but I find Opera is generally closer to spec than either Moz/WebKit. The WebKit devs have actually elected to ghost Moz to ensure compatibility with poorly coded sites (if you read their bug tracker you'll see they have a tendency of actually deliberately implementing some Gecko bugs instead of following spec to the letter - which they refer to as being "bug compatible" with Gecko) which is probably why you see synchronicity between them.

I just tested things and it appears opera is exposing transitions as:
elem.style.OTransitionProperty
Note the capital O... I was expecting camelCase... Hmm.

And then,
elem.style.OTransformProperty // returns CSSTranformValue object
whereas in webkit it returns a string:
typeof elem.style.webkitTransform // 'string'
Not a huge deal, but i'm not sure anything else on the CSSStyleDeclaration object (elem.style) returns an object..

And...
elem.style.OTransformOrigin // returns undefined in Opera 10.5
In webkit, where this is supported, the equivalent line returns empty string.

All a little odd... I think some bugs should be filed.

Note the capital O... I was expecting camelCase... Hmm.

That is quite odd. I didn't really consider that the DOM side of the vendor specific extensions might not be well defined, but either way webkit seems at least to be closer to what you'd expect there. camelCase is always the norm.
However, it doesn't seem to be accidental on their part either - DOM equivalents of all of their other vendor specific extensions appear to use a capital O.

And then, [Opera]returns CSSTranformValue object whereas in webkit it returns a string

Yup, I saw that. Opera's implementation is in line with spec there; I suppose the spec didn't have that section when webkit implemented it (or there was no spec, seeing as they invented it). According to spec:

The transform property of the style object returned by getComputedStyle contains a single CSSTransformValue with a type of CSS_MATRIX.

There's then an extensive section on using CSS Matrices in javascript which seems quite interesting.

Some more info on vendor-specific DOM equivalent style properties in general:

An Opera employee tells me:

AFAIK DOM 2 Style says that any letter after a hyphen should be capitalized when converting a CSS name to a JS property, though I won't go hunting for a link to prove that

Also, mozBorderRadius returns undefined, while MozBorderRadius works - so it appears that the initial capitalisation is standard, and only webkit gets this wrong.

The capitalization of these vendor properties is really messy, with Webkit being the only one to follow DOM standards in their extension and Mozilla/Gecko and Opera simply choosing to Capitalize their extension even though nothing else in the DOM world does that.

It seems to me that we should do a full study of all vendor properties and see if there is a single pattern to be found. I suspect that there is, and it's "webkitProp, MozProp, OProp" — no idea for MS/IE though.

If that is indeed what the findings will produce, we'll know what to do going forward (with Modernizr 1.2).

Anyone who already has data on this, please link it up here. I'll create a Google Docs page to keep track of this all and aggregate any existing results, then start testing to fill in the remainder (or simply all of it).

– Faruk

Firstly Webkit also capitalises - it does both, which seems even messier as you're just overpopulating the object with duplicate properties. You have both WebkitBorderRadius and webkitBorderRadius - I'm guessing the first one is the proper one.

Secondly, the whole idea of prefixing vendor-specific properties with hyphens is that hyphens are not normally used for regular properties - the non-camelCase form of the DOM equivalents is most likely for the same reason, making them deliberately different from normal, non-experimental properties.

I'd say the best option is to drop support for the camelCase ones altogether and capitalise them all, as this seems to work on the three main ones at least. WebkitProp, MozProp and OProp all work. webkitProp is the extra anomalous one there.

no idea for MS/IE though.

My preliminary testing of IE8 tells me that MS completely ignore all precedent and web standards on this and don't put any prefix whatsoever on their DOM properties - which is nice.

So the DOM equivalent of -ms-word-wrap for example is just element.style.wordWrap

I'm not sure how this should be handled - this means if/when IE actually add support for wordwrap, any sites who have chosen to use -ms-word-wrap may break! And they say they don't want to break the web. Perhaps IE vendor-specific properties should just be ignored altogether...

The hyphenated prefixes in CSS make perfect sense, indeed. It's when those get translated into DOM properties that things have become messy, because even considering that Webkit does (somewhat) play along, all of these properties become camelCase when the spec finalizes.

I don't understand what you're saying there. The logic seems identical in both cases:

1. All experimental CSS properties start with a hyphen, as no normal ones will ever start with a hyphen.
2. All experimental DOM style properties start with a capital, as no normal ones will ever start with a capital.

It's a very clean and intelligent way of avoiding the possibility of future clashes (however very unlikely they may be).

all of these properties become camelCase when the spec finalizes.

The experimental properties never "become" camelCase - they are treated as being entirely separate and different to the new standards-based camelCased ones. When the spec finalises, both the new camelCase (unprefixed, standards-based) DOM property, and the old experimental capitalised one must coexist as some websites will be relying on the old experimental one, while other websites will want to use the new one.

Unfortunately, IE scupper themselves here as they can't possibly do the above without breaking websites.

Sorry, "become" is definitely a wrong term to use here.

Anyhoo, this discussion has gone on for a lot longer than necessary already: Modernizr'll change its detection path for experimental props in the next release. Thanks :-)

Gracias lucideer! :)

All other vendors use camelCase and not UpperCamelCase. I noted this bug when 10.5 debuted and I assume it will be fixed very quickly. I re-poked some staff members and hopefully they can light some fires under the right people.

@fearphage
Sorry but you're wrong there. WebKit, Gecko and Presto ALL use UpperCamelCase - neither Gecko nor Presto use camelCase (WebKit duplicates functionality and does it both ways) - as I said above.

Also, you may have noticed this first in Opera 10.5, but Opera has always handled these properties in this way, it is neither new nor is it a bug. Hallvord mentioned to me that he believes spec states vendor-extensions must me capitalised to distinguish them from normal properties, though I've not found where it actually says that.

This testcase that only works in Gecko and Presto unfortunately, but demonstrates what I mean anyway. There's no such DOM property as element.style.mozBorderRadius at all.

Adjusted in:
http://github.com/Modernizr/Modernizr/commit/e3f5d3008d70a56dfa630a7f458fa6f58a9e2daf

(also fixed the copyright year in this commit)

@lucideer Thanks for the clarification. I stand corrected.