I am using to check my CSS http://jigsaw.w3.org/css-validator but I get error for -webkit-border-radius, -moz-border-radius and border-radius. I know that this site test for v2.1 and all these border-radius is from v3. So why they don't use CSS v3 as testing? Or CSS v3 should't be used?
They do, you just need to select the profile under More Options. The default is CSS level 2.1 as that's the most complete and final standard as of now. CSS level 3 is still in its early drafting stages — meaning any part of the spec can change drastically — and even the validator may be wrong sometimes, so it's not made default yet.
Bear in mind that vendor-prefixed styles will never validate as they are non-standard, but as Juhana says you can at the very least have them trigger warnings to allow your CSS to validate tentatively.
Related
Why don't browsers autocorrect CSS3 transitions? The only difference between the Safari/Chrome and Firefox CSS transition is "moz" and "webkit". Surely firefox could just add an autocorrect feature to change every instance of "webkit" in the css to "moz" and the problem would be solved. Or is there something more?
Normally the -moz and -webkit are for CSS selctors are properties that are are specific to the the browser engine. The selector could be unstable, or act differently in each browser as they refine the behavior.
They don't want to "autocorrect" to the other implementation because the other browsers interpretation of the CSS property could be different. It could cause problems about what CSS property should "win" in the event of a conflict. Lastly, it could increase development time for each browser since they would need to figure out what the other browser engine is doing.
In the end what you want is to not use any -* prefixes at all. For that to be possible there needs to be a standard syntax and behavior defined by the, wait for it, CSS standard. Then instead of repeating *-opacity: ... several times with different prefixes, you just write opacity: ... once, like any other CSS declaration.
Vendor specific prefixes are there to allow browser specific behavior regardless of what the current standard says. It allows vendors to implement new features for which no standard exists yet, or to test the implementation of features before committing to it. The end goal is always to implement all features defined by the standard in the way the standard defines it; but you won't get there over night. New features need to be tested as widely as possible to find problems with their implementation or possible problems in the standard itself. This testing happens by making features available through vendor specific prefixes.
When you use a documented standard feature like opacity, it's pretty sure that it works consistently across browsers (*cough*letsforgetabout*cough*IE*cough*forasecond*cough*). When using a vendor specific prefix feature, it means you're using a feature at your own risk which is subject to change and/or may not work consistently (yet). Browser vendors don't touch each others prefixes for a reason, they work towards the standard and eventually make the feature available without prefix.
I'm almost done with a project and now I'm facing a problem I don't know how to solve.
I did the whole css styling with the box-sizing: border-box (with ie6/7 polyfill) applied and it worked like a charme on every device I tested, until I picked up a blackberry. It doesn't support box-sizing (actually it does, but only from the very last version) and now all my layout is broken. Since the project is almost finished I don't want to go back and update every single stylesheet to not use that css rule. What do you think would be the best way to tackle this?
speaking about this:
http://caniuse.com/#search=box-sizing
Thank you
The first suggestion is that you could perform a server-side detection of the BlackBerry browser and if the version detetcted doesn't support the box-sizing property just send to the client an overriding stylesheet on the cascade, containing all the necessary rules (with an higher specificity, of course) to correct the wrong style.
Otherwise, if this method still need too much work to fix, you could try to serve a non-strict doctype for that specific browser only and see what box-model is used by that browser. For sure it's a bit hacky method, but maybe this change could have some good impact and "straighten" your layout.
I am simply wondering if there exists a global CSS reset for CSS3. Something along the lines of the commonly-used versions created by Eric Meyer or YUI, but for CSS3 specifically. I've queried channels such as Google, Github and here on SO, but haven't come across a comprehensive solution.
Edit:
The term "reset" is probably misleading since it deals mainly with resetting browser default settings. "Recalibration" may be better suited.
I should clarify and put forth a use case.
This would work in tandem with the normal CSS reset yet also handle any styling caused by rotation, box shadow, animation, border radius, etc. For example, as mentioned before on this post:
-webkit-transform:none; /* Safari and Chrome */
-moz-transform:none; /* Firefox */
-ms-transform:none; /* IE 9 */
-o-transform:none; /* Opera */
transform:none;
The above snippet, and others like it, would be associated with any HTML tags that might get affected by them, as it is with current CSS resets.
The implementation need for this would probably not be too common if you are in control of your properties. However if you are, for example, creating an app or plug-in that will be used across different domains, where the styling of the pages the plug-in script is invoked on can influence that of the plug-in itself, then something like this would be very useful.
I realize there are other ways to tame CSS inheritance and handle cross-domain issues, but this question is put forth regarding the CSS3 reset directly.
Much thanks.
The real way to solve your problem is either to use the scoped attribute, or to create your widget using the Shadow DOM.
This way, you can insulate yourself from external CSS. Unfortunately, neither are really ready for use, so yes, you'll have to manually protect yourself.
The alternative is to set everything (transform, font-size, padding, etc) in your code with !important, rather than resetting it to 0/none, then setting it anew.
I have two issues I have ignored so far, but I will really appreciate some light shed onto them.
First: how can I solve differences between Safari, Chrome and Firefox and the various tags that their engines render differently? Should I just write down the right attribute for each in the same css rule? Is there no better way?
Is there a way to separate the CSS sheets for these browsers as I am doing for IE? Is this recommended?
Second: What about CSS3 attributes? Should I just write them again in the same rule after the CSS2 attributes?
Will this cause problems validating the CSS with WC3?
Welcome :)
If you start without the prefixes, you should write the code, generally, with all the semantically appropriate tags, first.
Then, you can decide what your goals are.
If you want W3C compliant CSS files, then you'd need to strip out the vendor specific prefixes by default. This would then allow the latest browsers to pick up the standardised CSS properties if they support them.
This will target less of your market than you might wish, so then you should ask if progressive enhancement is a possibility. If you can reasonably enhance the visuals by using css applied after the page has loaded, such as applying styles with jQuery, MooTools or Prototype libraries AND these libraries are already serving a purpose in your website, then you could apply additional styles with those libraries (and possibly use them in conjunction with Modernizr to determine which elements you may want to additionally support.
However, it's likely that a browser will skip a property it doesn't understand and will render the ones that it does, so I'd suggest that if you code it to W3C Standards first and then add in your additional vendor prefixes 'before' the final (correct) one, then you'll likely have satisfied reasonable measures to be compliant and meet design needs.
Edit:
There is a little bit of confusion between validation results from:
http://validator.w3.org/
and writing valid code related to vendor prefixes to get CSS effects cross-browser:
List of CSS vendor prefixes?
for working on some cross-browser CSS, you might find http://csspie.com, for IE compatibility with some CSS3 properties, useful along with http://www.colorzilla.com/gradient-editor/ for cross-browser gradients and http://cssplease.com for code that gives you alternative vendor prefixes, including different versions of IE support for many different properties.
In terms of validation, here's what W3C says about it: (see comments here: W3 VALID cross browser css gradient,) and official docs here: http://www.w3.org/TR/css3-syntax/#vendor-specific
If you code according to the specifications first and test your code out against that and then add in your vendor prefixes to get the same effects on the browsers you want to support (see progressive enhancement: What is Progressive Enhancement?) then you can be more confident that your code is supporting the appropriate standards, adding value to those with more advanced browsers and still useful for those without additional features (see also WAI III compliance, 508 compliance and others if you want to write a more inclusive site).
Caveat: Web Apps may not always be inclusive or follow these guidelines depending on who the audience is.
If you are using jquery on the site you may want to look into PrefixFree. It's a script that adds the vendor prefixes for you, so for example your put border-radius:6px; in yor css and it reads the browser and adds the appropriate vendor prefix for you via js. I like it cause it keeps my css docs more readable.
Any solution for reducing browser compatibility problem while writing css style.
These three are the main points you need to do yourself:
Write correct markup - make sure it validates
Make sure your markup is in standards mode
Write correct CSS - make sure it validates
In addition, you can do some of the following to reduce the amount of headache:
You can use a CSS framework, like Blueprint, 960.gs, YUI CSS library, etc.
For Internet Explorer -related issues, there is ie7.js and ie8.js
Know how HTML and CSS work
Test in all browsers you target
You may also want to use a CSS reset file to start on the common ground.
Well, as of now there is nothing like fixall() which will make all browsers compatible...however, you can reduce compatibility problems by using the correct doctype.
Read thisarticle on using doctypes. Also, validate your markup.
Edit: You can go to Browser shots to see screenshots of your web design in different browsers.
Discipline!
Validate your HTML. Use a correct DOCTYPE.
Use standards, hack the bugs.
Be descriptive, or use a reset stylesheet.
Simple -- test, test, test.
First thing, you should have at least these browsers on your computer: FireFox3.5B , InternetExplorer7 (+ optional Safari 3, Google Chrome 2 Beta and Opera).
Now for a more definite answer:
avoid css3 styling like "opacity" et cetera as CSS3 is not a standard yet. Instead use Javascript libraries like jQuery to apply those effects selectively
avoid png transparency like the plague... instead use dithered gif transparency (this is now somewhat old, as it now works on IE7+)
Test and test and test