Skip to content
View in the app

A better way to browse. Learn more.

Web Designer Forum

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Should we really care about to make the CSS file w3c validated?

Featured Replies

We apply vendor prefixes –moz- and -webkit- to use the css3 properties, which is great we are up to date with new technology and participating to improve the web design future, but the downside is that it will not be validated as w3c standards.

 

Vendor prefixes are not recognized as official CSS properties and it will not change as vendor prefixes are proprietary and specific to vendors that invent it.

 

Should we really care about this to make the CSS file w3c validated?

I think these days it's pretty safe not to use vendor prefixes - they were only meant as a temporary thing whilst they were still experimental, but most modern browsers implement box-shadow and border-radius etc now.

 

In answer to your question, I don't think it's important to validate for the sake of it, as long you understand and accept the reason it doesn't validate and you're happy it's not going to have a detrimental effect on the site. Vendor prefixes are a prime example. In XHTML target="_blank" isn't valid which is ridiculous, so I do it anyway (even though I don't use XHTML any more, but you get the idea). That being said, you should always try and keep as close as to can to best practices - we just need a bit of common sense about it I think.

Vendor-specific properties are in the CSS spec. It's the validator that's borked.

To get around that, take a copy of your style sheet and delete all the vendor-prefixed rules. What's left should validate

I've always been under the impression, to keep 'good standards', vendor prefixes should only be used for testing, never in production environments. The basic thinking is that, because its in 'the spec' and you can use it, does not mean its 'ready'; ergo will not validate as its not "official".

 

The problem resides in that the vendor prefixes will be replaced by the official prefixes, the vendors use the -moz etc prefixes because that feature is not yet "fully supported", is still in development, is not tested yet or the official spec may not be final.

 

Of course you can use the the vendor specific prefixes, but be aware relying on them could cause issues down the line and don't expect W3C to validate it because to be blunt, it isn't valid.

 

Whether any of this concerns you or is a problem is purely circumstantial.

Edited by FizixRichard

Vendor-specific prefixes are perfectly safe to use in production because combined with the cascade, they provide built-in obsolescence as long as you declare them in the right order.

 

A user-agent will implement the last valid declaration it finds of the same property. That means you should declare your border-radius like this:

 

-webkit-border-radius: 10px; /* Chrome 4.0, / Safari 3.1 - 4.0  will use this */
-moz-border-radius: 10px; /* Firefox 2.0 - 3.6 will use this */
border-radius: 10px; /* Firefox 4.0+, Chrome 5.0+, Safari 5.0+, Opera 10.5+ and IE9+ will use this */

 

You should be fine if you stick to vendor-specific extensions for which official prefixes have been proposed.

Edited by Renaissance-Design

Create an account or sign in to comment

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.