Thanks for you concern about the CSS framework. As Jörn mentioned,
there are other UI groups better suited for this discussion. I'd
recommend
jquery...@googlegroups.com for this topic in particular,
next time.
To answer your question though, web standards are highly respected
among the jQuery UI development team. The code in our CSS framework is
under tight control and scrutiny, and I can assure you that any non-
standard or vendor-specific properties we're using have been carefully
considered and are usually applied as a tradeoff in place of uglier
markup workarounds or simply as a forward-looking enhancement.
We use validation as a development tool, but not as an end-goal. In
the CSS framework, we knowingly use a few properties that will trip up
the validator, and I'll explain and justify their use for you here.
- Border-Radius: The majority of the errors in that validation result
are from vendor-specific border-radius rules. We have adopted CSS
corner-rounding as opposed to generating multiple empty HTML elements
to allow an image-based alternative. The result is not only much
lighter weight and faster, but it also enables us to use corner
rounding in ways that would just not be possible given our theming
constraints. Currently, we use vendor-specific border-radius rules in
the framework for both Webkit and Mozilla (-webkit-border-radius, -moz-
border-radius) . These are actually written using valid CSS syntax
according to the w3c CSS3 draft, but the validator does not yet
reflect that rule. We will also add the w3 property (border-radius)
once browsers begin implementing to the w3 spec or when the spec
reaches recommendation status. More info here:
http://www.w3.org/TR/css3-syntax/#vendor-specific
- Opacity: opacity validation errors come with a note that they are in
fact valid in CSS3. Although we generally avoid using opacity in the
framework, there are a couple place where we do, and it requires 2
rules: opacity: 0; filter:Alpha(Opacity=0); . The first is the valid
CSS3 property, and the second is an ugly expression for IE support.
We've opted to do this here instead of requiring an entire separate
HTTP request for an IE-specific stylesheet. Unfortunately, this is the
way to support opacity across all our supported browsers right now.
Any fading behavior on the web that works in IE will use this same
property, though you might not see the CSS because it's inline. We try
to minimize use of inline CSS in our framework, so that's why we've
offloaded opacity to a CSS class in this case.
- Zoom: We don't use this property anywhere in the theming portion of
the framework, but as your error shows, we've used it in the tabs CSS
to trigger hasLayout in IE. If you'd like your tabs CSS to validate,
feel free to make a separate stylesheet for this single rule and
include it via conditional comments. We feel the overhead in making
that change is not worth the benefit of validation. Fortunately, IE
will be moving towards vendor specific syntax in the future,
minimizing rules like this, but we will continue to support older
versions of IE which need this fix.
I will personally look into the cases where we are using zoom and see
if there may be a standards-based alternative to trigger hasLayout in
each situation. Unfortunately, fixes like that can come at a cost, and
sometimes adding valid rules to fix an IE bug can end up breaking the
presentation in browsers that correctly interpret that rule. Despite
being invalid, the zoom property is simply ignored in non-IE browsers
so it is generally harmless, but we'll try to find a workaround.
I hope this addresses your concerns about the framework. In order to
innovate and provide tools that make complex behavior easier for
developers, we do evaluate and take advantage of forward-looking and,
occasionally, vendor-specific approaches.
Let us know if you have ideas for better ways to handle these
situations, given the constraints of the problems we're trying to
solve.
-Scott Jehl
jQuery UI Design Team