Only 4.13% of the Web Is Standards-Compliant 406
Death Metal writes "Browser maker Opera has published the early results of an ongoing study that aims to provide insight into the structure of Internet content. To conduct this research project, Opera created the Metadata Analysis and Mining Application (MAMA), a tool that crawls the web and indexes the markup and scripting data from approximately 3.5 million pages."
I wonder if (Score:3, Interesting)
I wonder if they're throwing away every page that doesn't fully comply or if they're actually including the pages that almost comply but have a typo or missing doctype or missing closing tag. I'm guessing the former by the numbers which seems a little unfair to me.
Re:How compliant? (Score:3, Interesting)
Also depends on how old the websites they searched are..
only recently added websites or also websites and old pages that exist longer than the standard they validated against exists ?
Re:Some standards are just too strict... (Score:3, Interesting)
The lack of a target attribute really bothered me when I first ran into it. Their argument was something like how websites shouldn't be controlling the browser, as in creating tabs/windows, etc. Of course you can hack it in with Javascript which is something I refused to do, what's the point of striving to be standards compliant when you break it a minute later with Javascript? Anyways, I thought about it and kind of agreed with the notion, so now I just externally link a lot less.
Re:It is not funny. (Score:3, Interesting)
Even if your app is 100% standard compliant, it may not be cross browser. Not even if you pull IE out of the equation. Not even if you ONLY TARGET FIREFOX (there are differences between FF2 and FF3. FF2 doesn't even fully implement CSS 2 itself...)
So by now, devs have reverted to another philosophy: make websites that are crossbrowser, and -mostly- standard compliants.
If you look at some of the most heavily cross browser web sites out there, especially the ones that are extremely backward compatible (down to Netscape 4), they are in HTML 4 quirk mode, and not standard at all. But they work better than most.
The standard also doesn't dictate defaults, which is quite the big hole. Being standard compliant doesn't help too much. Add that the standard evolves extremely slowly, and if you want to get the job done, you need to bypass it.
Thats why the W3C stuff is a standard proposition. No one "has" to adopt it. There are good standards out there, but as a general rule, anything coming out of the W3C is a joke of a swiss cheeze. Looked at the XQuery specs lately? My significant other works on a project to implement a full XQuery engine. A -lot- is left to interpretation, is loosely defined, etc. Same with XHTML and CSS. Even fully implemented, its vague, poorly designed (hellllooo.... versioning anyone? API 101?), and all around pathetic.
The faster we get rid of it, the better. Either by a proprietary spec (Flash may not be open source, but at least it freagin work, mostly cross platform if you don't care to use the latest version at all time...better than XHTML/CSS anyway...), either by a new standard body that doesn't suck at -everything- they do. XQuery, XHTML, CSS, SOAP, XSD, XML... can they do ANYTHING right?
Re:Sad. Even sadder is the yet-another-feature cre (Score:4, Interesting)
./ is mostly text, but how did you post this comment? Any Page refreshes?
Actually it uses some pretty sweet AJAX calls.
Progress usually comes from ignoring standards.
Slashdot (Score:2, Interesting)
http://validator.w3.org/check?uri=http%3A%2F%2Ftech.slashdot.org%2Farticle.pl%3Fsid%3D08%2F10%2F16%2F1325215&charset=(detect+automatically)&doctype=Inline&group=0 [w3.org]
If Slashdot shows up with 28 errors, would you really expect anything at all out of the non-technical media?
Re:Some standards are just too strict... (Score:5, Interesting)
XHTML-STRICT is not for everyone, it's intended for those (like me) who are more development oriented and wish to completely separate structure from presentation. A "target" attribute is clearly a presentation attribute since it defines how the linked reference is presented to the user and as the parent noted, it should be up to the user to make that choice.
When wanting to control presentation in XHTML STRICT, you should use DOM or CSS, that way, they structure (XHTML) is removed from the presentation (JS/CSS). I typically link all scripts and stylesheets. That way the XHTML is made portable in terms of data with the JS/CSS being limited to only effecting a web client. In the OPs case, a simple ID attribute for that particular anchor would work just fine, you could bind an event listener for a click event to that element and then execute your javascript popup code when that event is triggered, canceling the event so that the browser does execute the link on it's own. That way, your default browser clients could execute the JS instructions, while a 3rd party app (an AIR desktop or mobile device) could put their own custom behavior in if desired.
While that sort of practice may seem extreme to a designer, as a developer I can swear to it's scalability and transportability for supporting 3rd party access such as when developing a web UI that needs to support many types of clients via one codebase.
If none of those features make sense nor strike you as worthwhile, I suggest you stick to XHTML TRANSITIONAL, which is probably better suited to your needs.
Re:Sad. Even sadder is the yet-another-feature cre (Score:4, Interesting)
The best thing for you to do is to provide your own CSS file and tell firefox to use it rather than anything provided by the website you are visiting.
This will style all sites similarly, and will work great for sites that atleast have well-structured HTML. Sites that at least have properly structured HTML are much more common than sites which are standards compliant.
Re:It is not funny. (Score:3, Interesting)
You can make a site that works fine in every browser that's XHTML 1.0 Strict. Chances are that you'll have to use some non-standard (and probably invalid) CSS in a conditional stylesheet, but that a) doesn't count in terms of X/HTML validation and b) is only linked from the inside of a comment read only by IE, so even if CSS validity was part of being valid X/HTML it wouldn't be checked by the validator.
Granted, you may need to add in some extraneous tags in order to implement the proper CSS hacks, but that makes them extraneous not invalid. But that's just as true for implementing rounded corners, which is in CSS3 (and accessible in Safari and Firefox by using the -webkit-border-radius and -moz-border-radius properties respectively) but is an unnecessarily large pain in the ass to implement on any element that isn't of a fixed width and height.
You're absolutely correct that IE6 is a huge PITA to code for (as is IE7, but less so), but if you start with valid code that displays identically in Opera/Webkit/Gecko engines, you usually end up with something that doesn't take _too_ much hacking unless you have a really weird layout. My biggest problems, aside from those random 3px gaps that seem to occur mostly with floated elements, is font color inheritance on links and the various pseudo-classes, :hover in particular.
For plenty of the projects I've been working on recently, I can safely ignore IE6 entirely (making a conditional stylesheet wouldn't be TOO hard, but I can't be bothered right now) and IE7 doesn't usually have too many issues. It's certainly a nice change. Combined with fully cross-browser JS libraries like jQuery, my life as a web developer is a whole hell of a lot easier than it once was.
Re:How compliant? (Score:1, Interesting)
Re:Sad. Even sadder is the yet-another-feature cre (Score:3, Interesting)
So override with a stylesheet that looks roughly like:
* {
color: #0F0 !important;
background-color: #000 !important;
}
div {
display: block !important;
float: none !important;
}
and you'll be all set. The rest of us tend to like looking at something that doesn't resemble a terminal window all day long. There's a reason that browsers provide the ability to override stylesheets and disable javascript. CSS, JS, and all of that other stuff don't take the presentation layer away from you (in fact, they make it a hundred times easier to override rather than the inline styles of old), they just provide defaults.
How to do your bit for standards compliance (Score:3, Interesting)
Nowadays making sure your site is valid HTML is easy. Just install the excellent HTML validator plugin [skynet.be] for Firefox. It gives you a tick or cross icon on each page; double-click the cross to view the page source with a list of errors. It does the validation locally on your machine, not sending the content off to some server, so it's fast.
If you're writing dynamically generated pages it is a great way to find bugs in your code, and it's unobtrusive enough to leave it turned on all the time.
Don't BLINK or you'll miss it. (Score:3, Interesting)
BLINK will validate. To my eternal shame I've used it on my Home site's humour page [smivsonline.co.uk] and it passes w3c validation (just checked it to make sure). P.S. please don't slashdot me!
Re:Well, that depends.... (Score:2, Interesting)
In a program using [insert favorite (real)language here], when you have a syntax error it dies a horrible death. In testing, that's fine. You can fix it. Fixing things keeps them tidy and requires it to fit certain rules.
If your compiler saw ints=5; instead of int s = 5; and decided that ints should be a string, would you be happy? Then, when you wanted to do s = s + 6; and got 6 (because s hasn't been declared and your compiler decided that was ok, too) would you be happy? Would that suck to try and debug?
That's HTML.
Re:It is not funny. (Score:3, Interesting)
Only because we're brainwashed in seeing the web as incredibly limited. The "standard" allows for a lot of things that even FF2 doesn't support (only FF3). Display:inline-block anyone? Oh, there are ways around it, either through hacks, or through workarounds... but when I was is a (&@&)(&#)(#@ block that is...I don't know...inline... it would make sense if I could use inline-block. But nope, not if I want to support FF2. Sure the subset you can use without IE is much larger, but you still need to test cross-browser, heavily, no matter what, which was my point. That your page validates is almost irrelevent.
The standard moves slowly as hell. The W3C is a huge entity made of various special interest groups. That cannot go fast no matter what, AND its disconnected from reality (thus slowing down adoption). Even an -open source browser with Google as a sugar daddy pumping MILLIONS into it takes half a decade to get anywhere-. Same with everything the W3C piss out. It takes years to resolve real problems, because they're too busy with edge cases (XML namespaces mess!) to pump out specs that are useful.
During that time something like Silverlight gets implemented by Miguel's team in a fraction of the time, and thats a freagin Microsoft product thats supposed to be crappily documented. If you ask the people who designed the specs, they'll tell you it was MADE to be easy to implement (thus its limitations, such as absolute positioning against the closest relative parent, or lack of vertical control aside with the table-* category of displays), but if you ask anyone who actually implements it, they have a different story.
Ivory Tower, meet real world.
Ironically, the only reason the standard picked up in the first place was that IE had the best support for it for the longest time :) A lot of the stuff in the specs made it in IE first, too, albeit differently (opacity, ajax, etc)
The part in parenthesis was only about CSS. The part before applied to both XHTML and CSS. CSS versioning is so bad, that when its features get implemented (like by IE8), the community cries foul and say that in -THIS- case, IE8 should break the standard because its stupid. XHTML versionning -is- stupid too though. Its possible to get an XHTML 1.1 page that fully validates, yet its not even XHTML 1.1 (which is very different from 1.0)
XQuery has NOTHING to do with browsers. Its an XML API like DOM and XSLT :) Think SQL for XML. The specs are awful, and because of that, even though its much smaller to implement than XHTML/CSS, no one actually has a full implementation. Everyone is guessing. You'll see implementations on the market that claim being full, but if you talk with their developer, yes, its a perfect implementation of what was clear, with perfect guesses on the rest. I don't have a clue why you're comparing XQuery with JQuery though.
Finally, its easy to make a site thats standard compliant if the person making the design is the same as the person coding it. Then you can stick to the subset of what XHTML/CSS is good for. The CSS Zen Garden is an example of that. They start from the structure, and then do the best layout they can from that. If they start from a photoshop made by a designer, then try to apply it, its going to be another story.
There's a reason there's now a group for HTML 5.0... because even the experts thought the W3C's current specs are disconnected from reality.