w3c CSS validation error in system.base.css, system.theme.css

W3c validation do not support browsers specified CSS hacks.

Why is this closed? ravuriharish points at a valid bug: due to the usage of -moz-border-radius and -webkit-border-radius in system.base.css, all Drupal 7 sites fail to validate according to W3C standards.

This is not good. Can we solve this in a way that Drupal sites will validate again?
Bumping it to normal and re-activated. Please elaborate on why you think this is not a bug.

Drupal using browsers specified CSS hacks (-moz-XXX, -webkit-XXXXXXXX) which not include in W3C standards Validator. no way to fix it unless drupal lost those effects.

I'd like others to step in. The fact that W3C doesn't validate those effects is no reason to close this. We should find a way to let Drupal sites validate again. If this means that we lose specific effects, so be it.

For instance, we can make those effects (if needed) optional using a settings checkbox. So admins can decide if they want the effect that breaks validation. Or we might find a way to achieve those effects without using the browser-specific hacks.

Jquery UI is part of core and it has the following css in it:

/* Corner radius */
.ui-corner-tl { -moz-border-radius-topleft: 4px/*{cornerRadius}*/; -webkit-border-top-left-radius: 4px/*{cornerRadius}*/; border-top-left-radius: 4px/*{cornerRadius}*/; }
.ui-corner-tr { -moz-border-radius-topright: 4px/*{cornerRadius}*/; -webkit-border-top-right-radius: 4px/*{cornerRadius}*/; border-top-right-radius: 4px/*{cornerRadius}*/; }
.ui-corner-bl { -moz-border-radius-bottomleft: 4px/*{cornerRadius}*/; -webkit-border-bottom-left-radius: 4px/*{cornerRadius}*/; border-bottom-left-radius: 4px/*{cornerRadius}*/; }

And we are NOT going to change jquery UI css.
So please don't try to fix this. As long as there isn't a true HTML5 and css3 standard sites are doomed to being invalid.
Just look over these errors and see them as "warnings".

"Or we might find a way to achieve those effects without using the browser-specific hacks."

In a few years we can :). Just be patient. The border radius is almost standard in chrome and firefox.

If anything we're going to add more vendor specific extensions, IE10 will support -ms for example and we're already proposing to use this in Bartik.

In any case you can select how to handle vendor extensions using the options and since we are using CSS3 you should use the CSS3 profile to validate against - the OP is using CSS2.1.

There were big discussions around this issue for D7 and it was decided after much discussion that use of vendor extensions is OK, we use hardly any of them and can be handled reasonably well with the options in the W3C CSS Validation Service.

Is there a bug against this in jQuery?

If anything we're going to add more vendor specific extensions, IE10 will support -ms for example and we're already proposing to use this in Bartik.

I totally agree with keeping browser hacks in, but shouldn't things like this:

  clip: rect(1px 1px 1px 1px); /* IE6, IE7 */

be in an IE only CSS file? Not a huge deal, but this just adds to validation errors under all browsers..

I am new to Drupal and looked over default system CSS, but see no IE specific CSS files... or am I missing something? (I am running Fusion theme base which does have IE specific CSS...)

In Drupal 8 there are very few IE hacks or workarounds, its been a discussion to have an IE stylsheet and it may be something to consider since we are still supporting IE7 in Drupal 8 (as it stands, there is an open issue to drop support for this browser). AFAICT comma seperated values is only a recommendation, not a hard requirement, so this may be one of those instances of an over-zealous validator.

All Dutch governmental websites should adhere to the Web Guidelines (www.webguidelines.nl) and part of those guidelines is that the CSS should validate. Which basically means that Dutch Governments cannot use Drupal 7 out of the box. This is a pita. What about making the usage of jQuery UI optional?

Hi

IMHO, it is wrong to say "... sites are doomed to being invalid". And I honestly don't understand why someone would be strongly arguing against fixing a BUG. If meeting W3C standard is not among your goals, then you should know that there is only a few others that will agree with you. People has been sent to the moon. So it's not a simple CSS issue that is going to stop us. This needs to be fixed one way or another.

Personally, for the moment, here is what I do:

1. I accept the fact that I don't need these CSS3 generated rounded corners. I lived without them so far. So I can wait a little longer until they are widely supported.
2. I copy all the problematic CSS files from Drupal's system module (system.base.css and system.theme.css) into my theme's css folder. I DO NOT RENAME the copied css files.
3. I modify my theme's .info file to include the copied CSS file ...stylesheets[all][] = css/system.base.css
4. I refresh the theme registry to ensure that Drupal notices the changes made in the .info file.
5. At this point, you will notice that the copied files will be loaded only from my theme. So I can change them as I wish.

There is one exception though. The clip() function. That does not validate at all. The reason for using it in a first place is (I quote) "Hide elements visually, but keep them available for screen-readers.".

A better way to have a hidden content that will still be available for screen readers is to use off screen positioning. Here is how:

Original troublesome CSS found in system.base.css

.element-invisible {
  position: absolute !important;
  clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
  clip: rect(1px, 1px, 1px, 1px);
}

Modified working version in which I simply use absolute positioning to move the element off the screen.

.element-invisible {
  position: absolute !important;
  left: -1000px;
  top: -1000px;
}

An even better way is to make ensure that no matter which method you use, you MUST update the html aria-hidden attribute (possible values are true or false) because some truly assistive technologies rely on it to determine if a content is marked as visible or hidden. Normally, this attribute should be synchronized with the CSS visibility and display properties.

I hope this helps.

Cheers

asiby - the offscreen method of hiding content is fundamentally flawed and we have proven this repeatedly over the course of D7 development which is why it was rejected and the clip method adopted. This method may work for your limited use case but presents significant problems in others.

The fix is not to change the method, but to move the problematic CSS to an IE stylesheet (if you need to for whatever reason), for core its fine how it is.

Jeff, can you please elaborate about the flaws that you have identified with the off-screen technique? I would be interested in hearing about everything single bumps you have faced and hopefully, that may help us move towards an acceptable solution.

I agree with you for having IE specific stylesheet. For that reason, here is what I suggest in the mean time ... We can move the IE specific non standard clip() function (among others) into the corresponding IE specific CSS (IE, IE6, IE7, IE8...). At that point, even if it does not validate, at least will know that the invalid CSS will be specific to IE which is not valid as a whole to begin with. Mixing invalid CSS with the main CSS files will make the validation fail for all the other good web browsers.

You might thing ... Big Deal!!!! ... but yes it is a very big deal. Specially when you have clients that have to meet strict technical requirements so that the funds can be approved for the site you are building for them ... so that you can get paid. This happens frequently for anything that is funded (on way or another) by government money.

By the way, that's also the main reason why someone would choose the lexicon module instead of the glossary module. The same goes for AddToAny versus another one that I can't recall at this time.

Soon, we are going to have to add a flag to determine if Drupal modules validate against W3C and WAI-WCAG standards and for which version and level of the standards.

There are several mammoth threads that detail the discussions and findings regarding methods for hiding content, you are welcome to read those.

Just to chime in... If anyone else has the issue that lead me to this thread I'd like save them some time.

Recently I was onboarding one of my remote employees and they were not seeing SimpleAds on the site. In inspecting the code I saw that the section was being hidden by the system.base.css file.

After further investigating and testing we noticed that the ads were displayed in other browsers and I've always been able to see them on my end.

So, the culprit was an extension in Firefox called Adblock Plus 2.4.1. Once we disabled it and that solved the problem for us.

I use Bootstrap as my base theme and write valid code so I was really thrown for about an hour when it finally came to us during a casual conversation during testing.

Anyway, I hope that helps someone.

- Cheers