I'm building a site right now, so far I've painfully forced everything to be compliant and it looks pretty much the same across browsers. However, I'm starting to implement some third party/free javascripts which do things like add attributes (eg. order=2). I could work around this but it's a pain, and I'm starting to lose my principals of making sure everything is valid. Really, is there any point to working around something like this? I got the HTMLValidator plugin for firefox, and looking at most major sites (including this one, google, etc.), they aren't valid XHTML or HTML.
相关问题
- Views base64 encoded blob in HTML with PHP
- Is there a way to play audio on a mobile browser w
- HTML form is not sending $_POST values
- implementing html5 drag and drop photos with knock
-
Why does the box-shadow property not apply to a
Sure, you could always just go ahead and write it in the way you want, making sure that at minimum it works. Of course, we've already suffered this mentality and have witnessed its output, Internet Explorer 6.
I am a big fan of the Mike Davidson approach to standards-oriented development.
A lot of people misunderstand this post to mean that we shouldn't code to standards. We should, obviously, but it's not something that should even really be thought about. The validation army will always decry those that do not validate, but validation means so much more than valid code.
So, don't lose your principles, but remember that if you follow the standards you're a lot less likely to end up in the deep-end of issues in the future. The content you're trying to provide is far more important than how it is displayed.
I try write compliant code most of the time weighing the time/cost vs the needs of the audience in all cases but one. Where you code needs to be 503 compliant, it is in your best interest and the interest of your audience to write compliant code. I've come across a bunch of screen readers that blow up when the code is even slightly off.
Like the majority of posters said, it's really all about what your audience needs.
I have yet to experience an instance where the addition of a non-standard attribute has caused a rendering issue in any browser.
Don't try to work around those non-standard attributes. Validators are handy as tools to double check your code for unintentional mistakes, but as we all know, even fully valid xhtml will not always render consistently across browsers. There are many times when design decisions require us to use browser specific (and non-standard) hacks to achieve an effect. This is the life of a web developer as evidenced by the number of technology driving sites (google, yahoo, etc.) that do not validate.
The validation is useful to determine when things are failing to meet standards you presumably agree with. If you are purposefully using a tool that specifically adds something not in the validation standards, obviously that does not break your personal standards agreement.
This discussion gets much more difficult if you have a boss or a client who believes everything should return the green light, as you'll have to explain the above to them and convince them it's not simply you being lazy.
That said, be sure it's not simply be a case of you being lazy. While the validators may annoyingly constantly bring up every instance of the third party attribute, that doesn't invalidate (ha) the other validation errors they're mentioning. It's often worth scanning through as a means of double-checking your work.
It's not pointless by any means, but there is plenty of justification for breaking it. During the initial stages of CSS development it's very useful for diagnosing browser issues if your markup is valid. Beyond that, if you want to do something and you feel the most appropriate method is to break the validation, that's usually ok.
An alternative to using custom attributes is to make use of the 'rel' attribute, for an example see Litebox (and its kin).
I think writing "valid code" is important, simply because you're setting an example by following the rules. If every developer had written code for Fx, Safari and Opera, I think IE had to "start following the rules" sooner than with version 8.