CSS error fest

54 views
Skip to first unread message

Gilles

unread,
Apr 8, 2009, 6:15:20 AM4/8/09
to jQuery Accessibility
I didn't find any group for the CSS framework so will post this in
here.

I was wondwering why is the CSS framework generate tonnes of errors
and using tonnes of browser specific CSS attributes. I mean sure it
give great result in some browser (which are not the leading browsers
yet unfotunately) using the widgets because it modify the DOM and
therefor your original code can stay validated.

However for a plugin I work on I was using tabs widgets to do a little
homepage, but only had one tab so to make the page load faster I just
use the CSS framewoork to display the same thing.

When I check the CSS validity of it I was shocked tho...

http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fcodeserenity.com%2Fjquery%2Fscriptless%2F

39 errors :(

Why are standard not respected? I can kind of understand starting
using CSS3, but I really don't get the point of using browser specific
attributes. I don't even understand why browsers do it, it's horrible,
it's not recognise in the standard and it is just teaching people bad
pratice.

Standards are here for a reason and I am horrify that browsers
developers seems to ignore them like Microsoft did for so long.

Anyway, was not there to complain about browsers, but more to say I
was very disappointed that the jQuery UI team created a framework that
contains so many errors.

I can now scrap the JQuery UI CSS framework and redo the design
myself, what a shame and what a waste of time, the framework is
suppose to help us build better website and faster, not the other way
around.

Sorry if I sound like complaining a lot, I usually just claim how
great is JQuery and everything around it, I LOVE JQuery, I LOVE JQuery
UI (also I dont' get why accordion can only work properly in Firefox
when earlier version of it still work perfectly in IE (same for
effects)) but now I am sad to say I HATE the CSS framework :(

Any chance it ever get done with the standards respected?

deafninja

unread,
Apr 8, 2009, 7:37:38 AM4/8/09
to jquer...@googlegroups.com
Ummm jQuey is NOT a CSS framework it is a JS framework. I think you
need to take a step back and try learning how to use jQuery correctly
because you are in charge of the CSS not jQuery.

Sent from my iPod Touch.

Jörn Zaefferer

unread,
Apr 8, 2009, 7:53:51 AM4/8/09
to jquer...@googlegroups.com
He's probably referring to the jQuery UI CSS framework. The correct
list for that is jque...@googlegroups.com

Jörn

DeafNinja

unread,
Apr 8, 2009, 9:06:36 AM4/8/09
to jquer...@googlegroups.com
ah ok thanks because I was very confused on this post. 

Thank you for clearing that up and providing him a direction to go to.

M

ScottJehl

unread,
Apr 8, 2009, 11:25:35 AM4/8/09
to jQuery Accessibility
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



Gilles

unread,
Apr 9, 2009, 5:03:00 AM4/9/09
to jQuery Accessibility
Ok that for pointing to me the group I was not sure it was the right
group.

And sorry now I look back it was slightly agressive, I didn't mean
too, sometimes I just get too angry about some things in that area and
really I shouldn't I hope I didn't offend anyone. If I did I am truly
sorry.

Scott thank you for all the information (and the link), also I can
understand why use the browser specific extension I just think until
CSS3 is there it should not be used. I do understand the advantages of
course, mostly the lightness of it and the fact that the framework is
future proof (just need to replce those with CSS3 ones), and I have to
say I kind of like IE being penalised by it, the only issue is that if
one want to do round corner on the JQuery UI element you would have to
go and edit the HTML generate by the widget. Like you must know in
most real world cases (websites for clients ect) things need to look
perfect specially on IE still. I hate it but it is how it goes until
CSS3 is supported by all.

I have push work to use JQuery because, well, it's the best out there
in my opinon and some developers here didn't know javascript well and
JQuery eased the pain, but now some cool widgets like the tabs and
others we just can't use because our policy state that the design
should be exactly the same in IE6, IE7 and IE8 (also the IE6 support
is suppose to go down a bit)

I was not too bothered about the opacity bit to be honest, it is valid
CSS3 and I can see why it was put in (future proof), it just show in
there, but to be honest it is not something you widely use here so I
can just go and remove it myself.

Zoom I was also aware that it is used to fix some IE bug, to be honest
till I did the test didn't even know it was actually throwing errors
as i never used it in the past. But that would be nice if that could
be addressed.

I wish I could give you any ideas, but unfortunately having 3 kids my
time is limitted to get specialist into anything these days (will be
easier when they are teens :p), normally I am more a server side type
of guy and at the moment trying to get better in javascript/jquery
mostly, getting there slowly :)

Have you considered maybe a CSS3 and CSS2 version?

I mean I do realise it would increase your workload, but maybe just
have one release of the CSS Level 2 more for legacy type of thing and
just not support it. But then again that always bring on more people
complaining (like me :p) I might give it a go myself to be honest, or
at least try to remove the thing that generate errors and warnings (I
hate warning too wether it is css, html or php, I admit I am a bit
obsessed)

Thanks a lot again for all the information and reason of why you went
down this road. I normally use my own CSS but thought I gave a go at
the framework on its own without the widgets.

Otherwise you guys rock and like a lot of members I appreciate the
time and effort put into providing us with JQuery solutions, after
it's never easy to make everyone happy. Before my babies arrived I run
a couple of open soruce projects and I know sometimes users can be
exigent even for a free solution, just like I was on that one :)

Scott González

unread,
Apr 9, 2009, 8:37:12 AM4/9/09
to jquer...@googlegroups.com
Hey Gilles,

As for rounded corners and your design needing to the exactly the same in all browsers, you can use another plugin to add the rounded corners in IE or you can just customize your theme to not use rounded corners.

As for opacity, your only option is to not use opacity if you won't use browser-specific rules.  You should be aware though that if you're doing any fading using jQuery, you're using invalid CSS rules.  We're all standardistas here, but in real life standards only get you so far.  Using a property like filter to get opacity in IE just isn't a big enough concern for us to completely drop the use of opacity.

That really just leaves us with zoom, and I'd have to fall back to the "standards only get you so far" argument again.

The bottom line is there's no way to do this perfectly.  Either we're keeping our markup lean and falling back on slightly invalid CSS or we're adding bloated markup.  Either way, we're compromising somewhere and therefore we'll be upsetting some people.  We understand your concerns and we weighed these exact concerns very heavily before deciding to support features such as rounded corners in our CSS framework.

I hope you can tweak your theme to meet your company's requirements.  If you run into any specific problems, you can always ask for help on the jquery-ui list.
Reply all
Reply to author
Forward
0 new messages