Results 1 to 7 of 7
Dec 14, 2012, 10:07 #1
Getting lots of errors with CSS Validator "mobile"
I'm working on a mobile website.
When I run the W3C CSS validator in CSS3 mode, I get about 78 errors.
When I run it again but I set the profile to "mobile", I get over 500 errors!
Most of the errors are of this type :
- Property border-radius doesn't exist in Mobile but exists in [css3] : 0.7em 0.7em 0 0
- Property box-sizing doesn't exist in Mobile but exists in [css3] : border-box
- Unknown pseudo-element or pseudo-class :last-child
- Property box-shadow doesn't exist in Mobile but exists in [css3] : inset 0 2px 0 #cccccc
I don't really understand, to me these CSS rules are OK to use. Worst case scenario they could generate a warning of some of the mobile browsers don't understand them but why give me errors?
The client is asking us to reduce the number of errors, and I think there are a few things we can improve indeed, but I have no intention of removing border-radius or box-shadow!
Thanks in advance for your help
Dec 14, 2012, 13:33 #2
- Join Date
- Jun 2012
- NJ, USA
- 46 Post(s)
- 2 Thread(s)
What is your development environment? Browser? Code Editor? etc. How do you test your pages, especially for cross-browser/UA compatibility?
Your message doesn't ask for help in any of these areas, it seems to ask for validation of your attitude. I disagree with your attitude. Sounds shallow. Mobile agents do not support the same range of css properties as desktop agents; and html5 and css3 are still works in progress. On the other hand, if the finished page renders properly across the desired target audience, then the client might need to learn more about the conventions used by the validator and how they are applied.
Semantics (terminology) or problem (poor UA support)?
Dec 14, 2012, 15:42 #3
Thanks Ronpat for your answer although I'm not sure I deserve the tone.
I'm quite new to mobile development so I'm just trying to understand why I'm getting so many errors. The website is to be viewed on smartphones and I actually thought that smartphone browsers were on average more evolved that some of the old desktop browsers.
We're getting a really good grade on W3C mobileOK Checker http://validator.w3.org/mobile/
So I'm just surprised that so many properties such as border-radius or even inline-block are seen as errors by the W3C CSS Validator in "mobile" mode.
I gave the link to that service in my question, so that answers yours about how I test my pages (http://jigsaw.w3.org/css-validator/)
To tell you the truth I'm working as a project manager on this project which was already built before I joined the company. I used to be a front-end dev so I understand HTML/CSS. The client has asked for improvements they're entitled to but I'm running some tests to see what we could improve and optimize.
I didn't expect to have to "optimize" or even remove things like border-radius.
I would think that, just like on desktop browsers, if a browser doesn't support border-radius it would just render square corners. Why generate an error? I'm trying to make sense of this, that's all.
I'm wondering what to say to the client because I don't think they'd want to give up border-radius or box-shadow.
Dec 14, 2012, 16:41 #4
- Join Date
- Jun 2012
- NJ, USA
- 46 Post(s)
- 2 Thread(s)
No disrespect intended; just expressing an impression. You sounded a little naive at first. I now see that you have more responsibility and experience than I imagined.
IF the properties that the validator flags as "errors" are being rendered properly in the target user agents or are degrading properly, then I would explain that to the client. If they are not, and the client still likes the visual effect, then other (older?) methods are probably available. I would guess that programming for mobile agents is a lot like programming for the widest range of desktop browsers (brands and versions). One just has to learn what works where. I suspect that might seem like quite a learning curve at first.
border-radius for example is new and still being implemented by vendor specific prefixes in some browsers that have not yet been programmed for the "standard" syntax. I imagine the evolving mobile market is hard to keep up with. There may be a site somewhere that lists which css properties are compatible with which mobile OS's.
It would probably be more helpful if someone else would enter this conversation with you who has experience programming for mobile devices as mine is almost nil.
Dec 14, 2012, 20:15 #5
- Join Date
- Mar 2009
- Melbourne, AU
- 389 Post(s)
- 5 Thread(s)
Remember that validators are pretty dumb, and just check your site against some rules they have. If they haven't been told about CSS3, for example, or vendor prefixes, they will go all wobbly at the knees, when in fact there's nothing wrong with these at all.
The validators are handy for alerting you to any serious problems that may affect page rendering. But if the pages render fine, the validator is otherwise useless. Getting worried about validator results when the page renders fine is misguided. The key is not to show clients these results, as they are likely to get freaked over nothing.
I admit I don't do "mobile" validator checks much, but I assume they are telling you about the more basic mobile devices. Those devices are pretty limited in what they can display, which is why some people these days are advocating "mobile first" design, which involves serving up a pretty basic version of a site that will work on the simplest devices, and then adding in more CSS for smarter devices like smart phones and desktops—excluding IE < 9, of course.
If you serve up something simple to simple mobiles first, you can avoid the horror of seeing your desktop site run through the mobile validator.
Dec 15, 2012, 14:49 #6
- Join Date
- Jan 2003
- Hampshire UK
- 153 Post(s)
- 3 Thread(s)
Validation is a means to an end and should only be used as a guide for you to check that the errors it produces are applicable to your situation. If you look at the errors and understand why they are errors you can either ignore them if not relevant or fix them if they are pertinent to the project.
The mobile profile is a very basic profile mostly a subset of css2.1 but not all of css2.1. It is there to check the lowest denominator and should really only be used for the most basic of devices and not as a guide to how code will render on all devices. The mobile world is speeding ahead so you can't base an iphone's capabilities by checking out the mobile profile. You would need to use the most modern profile of css3 as the iphone understands those as well as any modern desktop browser (or perhaps more so). I don't think the validator will ever catch up with mobile devices anyway as new devices arrive daily and when that mobile profile was written it knew nothing about the devices out there at present.
In the end the validator can tell you nothing about how your code will render on a device only if the code conforms to a certain profile. Many valid documents will render horrendously if the author has coded the page incorrectly. You can build a wall with bricks but if you don't align them properly the wall will fall over.
As an aside you can set the w3c validator to generate only warnings for vendor prefixes and thus take them out of the equation anyway.
Dec 17, 2012, 01:42 #7
Thanks to the 3 of you for your help.
@ralph.m, I didn't show the errors to the client, they showed them to me
To be honest I didn't even know there were different settings to the CSS validator until now...
@Paul O'B that's what I was hoping to hear, so this is meant for really basic phones, which we are not targeting in this project. It's a responsive website for smartphones and tablets (there is a separate desktop site) so I don't think we can be expected to pass this validation. Plus the client wants fancy things so it's not just basic text.
Plus, as I mentioned, we're getting a good grade on W3C mobileOK Checker (between 80% and 88%). Could be improved, but not bad.
So I know what I've got to do, I will explain to the client that this validation is only useful if we're catering for the lowest denominator, which we are not.