This is obviously due to
their use vendor specific webkit properties, which cause horrible amounts of errors because vendor-specific properties are not valid by the W3C.
The sliding of the navigation and the fading of the content is all done by -webkit-animation-duration: 0.4s; -webkit-animation-name: acceleratedReveal; and other webkit transitions/transforms
and the navigation is styled using -webkit css gradients if supported and images if not supported.
I just wanted to post this thread to see what other websites with horrible amounts of vendors specifics do you see out there?
I have heard of that, but I am a not a supporter of this at all.
They are vendor-specific and should only be used for testing.
The majority of these properties are in working draft by the CSS Working group and official and valid methods of achieving these things are being worked on.
If people just refer to vendor specifics then they may never go to the official syntax, even when it is recommended and released.
The other issue is that the syntax for the vendor-specifics are sometimes slightly and sometimes completely different. Which makes it hard to manage and read.
This is also a propagate for having support in only a few browsers.
Chrome & Safari now first support border-radius and box-shadow, the official syntax, before they support the -webkit syntax, which is how it should be.
Technically since vendor extensions aren’t part of CSS (in the sense of, it’s not valid) it makes sense that they are invalid. The validator doesn’t recognize them.
I do think that they should just be warnings, and not errors, because it’s clearly not invalid CSS, but rather just vendor specific. But taht’s just me, the validator obviously doesn’t agree :).
If the “standards” became standard in a more reasonable timeframe, then I’d buy that argument. But considering the timeframe these organizations work at, it’s just an unrealistic concept.
But if the browsers provide a method for a feature the customer desires, then there’s no reason not to take advantage of them as long as the awareness is there that it is only a benefit to those that support that feature.
Corner radiuses are a prime example. I can use the css3 border radiuses (which is NOT a standard yet) to show rounded corners without having to hassle with extra divs, images (and the issues that can do with expanding content and various window sizes). I only have to provide a method for those users that are on IE8 and earlier. That’s one browser to hassle with instead of worrying about all the different types.
And if the client doesn’t want to worry about the IE users? No harm, no foul - they just don’t see the rounded corners - theirs are square. Still completely functional and visually appealing - the newer browsers just see something with a little more polish to it.
If people just refer to vendor specifics then they may never go to the official syntax, even when it is recommended and released.
People who develop (no pun) bad habits will find a way to develop bad habits no matter what. But many people already include the “current” standard syntax along with the vendor syntax in an attempt to make the page future proof, but since there might always be a moz 3.5 rolling about that you might want to support i dont see the harm in adding “-moz-border-radius” or “-moz-whatever”.
It’s not like the having a standard way would not have been optimal, but that NOT reality imagine if instead of relying on js or hacks all we would have had to do to support IE 5-7 was add -ie- ( in a sense we do this with conditional comments). Simply put there is and not probably will never be much code compliance in UAs today. Even if all of the UAs become compliant day after tomorrow alder versions will still linger for a bit… so despite the non validation… prefixes are not as evil as people are making them out to be.
BTW,
my solution to this is I code with the current standard syntax, but keep a separate @import for all prefixes… the main style sheet is thus totally valid and I can provide support for a wide range of vendors and versions and it still cleaner than what I have to do to support IE.
I don’t think it’s fair to say that they “should not be used” … more a case of “should be used with care”. The whole reason for having vendor-specific properties is to allow authors to safely use them before they become part of the spec. As long as you check that you are using the right method for each browser, where in some cases the implementation differs, you shouldn’t cause any problems for any user.
I think the bottom line is that you use vendor extensions and CSS3 with care and ensure that the page degrades gracefully if the property is changed at a later date or that a browsers doesn’t support them now.
There is no foolproof method because even the css3 specs can change as happened with border-radius so there is no guarantee either way. In this case it was the vendor specific version that survived.
Whether these extensions should validate or not is another matter but perhaps the vendors should have a validator tool to check the code you are using is correct according to their specs. The prime purpose of a validator would be to check that you are using code correctly and if you can get malformed vendor extensions to validate then it’s not much use.
You can for example find a typo like “position:relativx” when you run it through the validator but if extensions are allowed you would not find a similar typo in the vendor extension.
I use validation as a means to an end and not for validation’s sake.
