Slashdot Mirror

Firefox doesn't have proper support for it either, assuming you meant "application/xhtml+xml". I know, I've tried it.

If you don't believe me, try it for yourself: http://matrix.theblob.org/xhtml.html . That's a valid XHTML page served up with a MIME type of application/xhtml+xml.

* IE prompts you to download it.
* Firefox presents you with a XML tree.
* Safari renders it correctly.

I hate IE as much as you do, but Firefox has some way to go too.

I just can't imagine installing IE7 on my machine except if I REALLY have to to verify that my websites load and operate with it. And that would be really sad.

Check out http://www.browsercam.com/ if you need to know what your website(s) look like in other browsers. It's generally enough to make sure your (x)html folows W3 http://www.w3.org/ standards, but some browsers don't so Browsercam and other tools like it can be of value if you really want to know what your site will look like in other browsers. It's great for Windows users also since it can show Linux-browsers like Konqueror etc also.

Though it's feasible to do what you suggest, it goes against W3C Recommendations. Doing that is what caused the GWA problem in the first place, as prior to GWA the way things were being done weren't a problem. Just follow the W3C...

http://www.w3.org/2001/tag/doc/whenToUseGet.html

From the site...

1.3 Quick Checklist for Choosing HTTP GET or POST

        * Use GET if:
                    o The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup).
        * Use POST if:
                    o The interaction is more like an order, or
                    o The interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or
                    o The user be held accountable for the results of the interaction.

A lot of the middleware that converts data to HTML and back can go away when you use the right XML tools. XSLT does a good job of presenting static pages, and it can be fast if you cache the results as well.

But for dynamic pages (and forms) XML to XSLT to HTML leaves some big gaps:

1. The hierarchical XML data gets flattened out into name/value pairs in HTML form fields.
2. For the return trip HTML->?->XML, XSLT doesn't work; you can't run the transform backwards.
3. For dynamic pages, you're left with JavaScript or the dreaded "postback."

These are some of the reasons we updated the W3C HTML forms module to take account of XML data directly.

How does it fix the above problems?

1. The hierarchical XML data your PHP or other server-side code outputs is transmitted directly to the web browser, where it remains while the user futzes with only the nodes that the form specifies. The middleware that converts the XML data to web browser data is just printing the XML.
2. When the form results are submitted, they come back directly in XML, so there's no need to pick apart the name=value pairs and try to put them back into your data. The browser just posts the XML directly back as XML to your PHP or servlet.
3. For forms, as the data changes, the UI changes with it. If a node disappears, or appears, or if a value changes, entire sections of UI can appear and disapear just by listing a dependency on that data. And if you want dynamic pages, you can use the background submission feature to retrieve instance data asynchronously, and the presentation changes automatically.

Nice work if you can get it, you say? Well, as everyone knows Microsoft hasn't yet implemented XForms. (Heck, they haven't even implemented CSS, though we hear they do have it as a goal now.)

So what can you do today:

1. Use Mozilla or FireFox XForms 0.4. It's a one-click install download from the Mozilla website. Yes, it's beta. Yes it has bugs. Yes, IBM and others are fixing them. But it's open source.
2. Use FormFaces for most modern browsers (Firefox, IE, Safari, Opera) FormFaces is a cool JavaScript/AJAX application that you import into your web page with a one-line include, and it does everything described above. If you need cross-browser support right now, want dynamic AJAX forms, and want to interface to XML, this is your best bet, if you can tolerate a JavaScript program in your browser (i.e., it's done using AJAX). It's available under GPL and commercial licenses.
3. Use Chiba for backend processing Chiba is an open source Java-based back-end that converts your XHTML+XForms page into either an AJAX page or a static HTML page (good for Sec 503 compliance). Chiba is a great choice for applications that have a Java back end, as it puts less load on the browser than the large JavaScript engine of FormFaces, but I put it below FormFaces here because of the emphasis on PHP. (But, about half of Chiba is an XSLT transformation so a PHP port is possible.)
4. Use Formsplayer as an IE plugin FormsPlayer is a deluxe XForms processor plug-in for intranet applications using Internet Explorer, and has lots of other features as well, such as sidebar support.

Here's a quick example:

Let's suppose you have a book list you want to view, avaialble at http://example.com/books/list.

<books>
<book>
<title>No Nonsense XML Web Development with PHP</title>
<author>Thomas Myer</author>
<book>
...
<books>

If you want to display this data

width: 750px; position: fixed; margin-left: auto; margin-right: auto;

"If 'left' has the value 'auto' while 'direction' is 'ltr', replace 'auto' with the distance from the left edge of the containing block to the left margin edge of a hypothetical box that would have been the first box of the element if its 'position' property had been 'static'."

"(But rather than actually computing that box, user agents are free to make a guess at its probable position.)"

width: 750px; position: fixed; margin-left: auto; margin-right: auto;

"If 'left' has the value 'auto' while 'direction' is 'ltr', replace 'auto' with the distance from the left edge of the containing block to the left margin edge of a hypothetical box that would have been the first box of the element if its 'position' property had been 'static'."

"(But rather than actually computing that box, user agents are free to make a guess at its probable position.)"

My page does actually validate now. I put a shorter doctype in, one that doesn't look too hacky, and put the character encoding meta tag back in. I had taken that out because it seems so incredibly unnecessary, but once you're already looking at the validator page, and there's one more error left, it's hard to resist.

Have you checked joe-baldwin.net? He's fixed it. His attitude towards validation is similar to mine - once it's rendering right, it's not as important. Which is strange, because my site validates perfectly and I don't know if it renders ok in Internet Explorer yet.

It's funny how that works out. The most invalid site I visit works really well in most browsers. Its only real bug is in Konqueror, where the forum list turns to mush. All because the guy in charge of it uses Firefox, and so he has to put at least the minimum of effort into cross-browser compatibility. This is how I see the struggle for compatibility being won, because it's the way that 'appeals' to non-nerds (this isn't intended as a rebuttal to any of your points by the way).

> Actually, I'm pretty sure it's specified somewhere that invalid HTML should cause error messages and not render at all. No browser actually does this though, because too many people write crap code.

This is from the specification of HTML 4.01 at http://www.w3.org/TR/html4/appendix/notes.html#h-B .1:

B.1 Notes on invalid documents

This specification does not define how conforming user agents handle general error conditions, including how user agents behave when they encounter elements, attributes, attribute values, or entities not specified in this document.

However, to facilitate experimentation and interoperability between implementations of various versions of HTML, we recommend the following behavior:

• If a user agent encounters an element it does not recognize, it should try to render the element's content.
• If a user agent encounters an attribute it does not recognize, it should ignore the entire attribute specification (i.e., the attribute and its value).
• If a user agent encounters an attribute value it doesn't recognize, it should use the default attribute value.
• If it encounters an undeclared entity, the entity should be treated as character data.

We also recommend that user agents provide support for notifying the user of such errors.

Since user agents may vary in how they handle error conditions, authors and users must not rely on specific error recovery behavior.

Funny that, if you follow the VERY FIRST LINK on that page it does NOT validate!!

http://validator.w3.org/check?uri=www.microsoft.co m%2Fworldwide%2F

Just about the kind of tactics I expect from M$ crapware. Do just enough work to make things look like they are OK on the surface, then do a crap job on the underlying details... thank you for helping proove my point! ;)

http://validator.w3.org/check?uri=http%3A%2F%2Fwww .microsoft.com%2F

http://www.w3.org/TR/CSS21/syndata.html#parsing-er rors

Since a lot of people point to the fact that the Acid2 test contains invalid CSS I thought I'd point out that this was in fact intentional.

The reason why is described in the above link, CSS defines how a browser is supposed to behave when it finds invalid CSS.

Testing whether a piece of software behaves correctly when presented valid data is only half of bug-testing.

The other half is testing whether a piece of software behaves correctly when presented invalid data.

Acid2 covers both halves.

CSS is supposed to fail more gracefully than XML and XHTML and ignore only those parts that are incorrect.

> It has absolutely nothing to do with testing broken css rendering at all.

From the ACID2 site: "Note: some 827 people (rough estimate, contents may have settled during shipping) have written to point out that the CSS used in the test is invalid. This is deliberate, as a means of exposing the ability of user agents to handle invalid CSS properly."

Sorry, handling broken CSS properly is not using the stylesheet. Anything else is gravy.

Anyway, try the CSS validator yourself. ACID2 ain't valid CSS:

http://jigsaw.w3.org/css-validator/validator?uri=h ttp%3A%2F%2Fwww.webstandards.org%2Fact%2Facid2%2Ft est.html%23top&usermedium=all

Now check his site's validation. The 81 errors on the first page are "this tag shouldn't be here in this type of markup". Who even cares about doctypes anyway? As if browsers didn't decide for themselves how best to render the page anyway? At worst, it seems he should be labelling it as "html transitional" instead of "xhtml assrape-grade pedantic".

Now check his site's validation. The 81 errors on the first page are "this tag shouldn't be here in this type of markup". Who even cares about doctypes anyway? As if browsers didn't decide for themselves how best to render the page anyway? At worst, it seems he should be labelling it as "html transitional" instead of "xhtml assrape-grade pedantic".

If the most admired company in tech doesn't give a crap about valid HTML (and the second-most-reviled company in tech does*), what does that tell you?

* Microsoft's web site is only HTML 4.01 compliant. However, MSN Search is valid XHTML 1.0 Strict.

If the most admired company in tech doesn't give a crap about valid HTML (and the second-most-reviled company in tech does*), what does that tell you?

* Microsoft's web site is only HTML 4.01 compliant. However, MSN Search is valid XHTML 1.0 Strict.

If the most admired company in tech doesn't give a crap about valid HTML (and the second-most-reviled company in tech does*), what does that tell you?

* Microsoft's web site is only HTML 4.01 compliant. However, MSN Search is valid XHTML 1.0 Strict.

The W3C validator shows 80 errors on your webpage. http://validator.w3.org/

You could try fixing those first.

Well, my question is why the Acid 2 test doesn't pass CSS validation?

Sure the HTML is good, but how are you making a test with an invalid website?

I'm not sure whether yours or the reply consisting entirely of a link to the w3c validation check of his site accompanied by a snide remark is the most pathetic. Having been through so many webpage layouts, in both tables and in css, one thing is crystal clear: rendering bugs are rarely related to invalid markup. In my experience, most of the time they are down to the combined effect of a few peculiarities in a particular browser or browser group. This fact has been proved and re-proved to me so many times that I've stopped using the validation check completely. I've barely been making websites a year, and even I've learned that on the web, markup standards are only a guideline. What's your excuse?

Your remark about Opera's strict adherence to XHTML standards demonstrates your complete ignorance on the subject of browsers as software. More so than almost any other kind of software, browsers absolutely *must* be capable of dealing with nonstandard input, invalid crap, and all kinds of other bizarre shit that gets sent to them. If opera mis-renders this site, it's Opera's problem too.

However, my first piece of advice to the thread starter would be to sort out his invalid code, but mainly because it's the easiest factor to remove from the equation, not because God hates invalid markup.

I'm not sure whether yours or the reply consisting entirely of a link to the w3c validation check of his site accompanied by a snide remark is the most pathetic. Having been through so many webpage layouts, in both tables and in css, one thing is crystal clear: rendering bugs are rarely related to invalid markup. In my experience, most of the time they are down to the combined effect of a few peculiarities in a particular browser or browser group. This fact has been proved and re-proved to me so many times that I've stopped using the validation check completely. I've barely been making websites a year, and even I've learned that on the web, markup standards are only a guideline. What's your excuse?

Your remark about Opera's strict adherence to XHTML standards demonstrates your complete ignorance on the subject of browsers as software. More so than almost any other kind of software, browsers absolutely *must* be capable of dealing with nonstandard input, invalid crap, and all kinds of other bizarre shit that gets sent to them. If opera mis-renders this site, it's Opera's problem too.

However, my first piece of advice to the thread starter would be to sort out his invalid code, but mainly because it's the easiest factor to remove from the equation, not because God hates invalid markup.

First off, a lot of that code isn't broken. I just checked the errors and the first few are errors relating to the SCRIPT tag, which afaic shouldn't be errors at all. Then there's the lots of errors about "You can't have a DIV" there which are frankly bollocks; again, browsers render this just fine. A lot of it is due to WordPress's internal code, mind you; if you look at a page which isn't generated by WordPress, say this one from the same site, you get only the JavaScript errors (which are probably due to some case-sensitivity on the validators part) and some admittedly boneheaded mistakes which I think are part of me using id divs instead of class divs.

Aside from that, Opera still fails.

As Internet Explorer has shown, having a solid JS DOM...

DOM Level 1 Core states that "The DOM presents documents as a hierarchy of Node objects". As IE/Win is capable of creating a node with two parents and creating a node whose parent is the child of one of its siblings - that is, a non-hierarchical structure - it can hardly be claimed that it has anything to teach anybody in this area.

(I'm aware that these effects are caused by invalid markup, and that other browsers also have problems agreeing on what to do; but the simple fact is that the DOM is defined as a tree, and IE/Win internally uses a data structure which is not a tree. So it's difficult to see how its DOM implementation can ever work properly.)

http://validator.w3.org/check?uri=www.tubmonkey.co m

47 errors. You're using tag soup, not XHTML.

This is because web developers fail to use correct standards, and don't validate their web pages first.

Probably one of these...

Perhaps you should fix your coding errors first. http://validator.w3.org/check?uri=http%3A%2F%2Fjoe -baldwin.net%2F alone lists 94 errors, so don't blame Opera.

How I love thee, except for one small problem. My website. It doesn't render properly in Opera, on any platforms. Scrolling erases all the content, and I have no idea why. If anyone can work out why this happens, I'd love to know...

Ok, so this may be a rant / flame, but come on M$. Did you even try here?

You claim your page is XHTML1.0 Strict, but can't even get it to validate:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww .live.com%2F
250+ HTML errors on 100 lines of code? Is the OS the same way??? :eek:

Google on the other hand doesn't try to be anything. Just the simple little "search engine that could".
http://validator.w3.org/check?uri=http%3A%2F%2Fwww .google.com%2F&charset=(detect+automatically)&doct ype=Inline
(50 Errors)

You make it impossible to use without javascript where as Google is non-JS friendly

You make it without regard to US Section 508 / WAI standards (I guess you don't care if the Government uses it, you just hand over all your search records anyway). Not that this is really a #1 priority at google, but at least it's usable for non-JS users and is all text (html)

You offer an over-engineered design.

I don't see this taking off in the near future. Need many MANY improvements.

Ok, so this may be a rant / flame, but come on M$. Did you even try here?

You claim your page is XHTML1.0 Strict, but can't even get it to validate:
http://validator.w3.org/check?uri=http%3A%2F%2Fwww .live.com%2F
250+ HTML errors on 100 lines of code? Is the OS the same way??? :eek:

Google on the other hand doesn't try to be anything. Just the simple little "search engine that could".
http://validator.w3.org/check?uri=http%3A%2F%2Fwww .google.com%2F&charset=(detect+automatically)&doct ype=Inline
(50 Errors)

You make it impossible to use without javascript where as Google is non-JS friendly

You make it without regard to US Section 508 / WAI standards (I guess you don't care if the Government uses it, you just hand over all your search records anyway). Not that this is really a #1 priority at google, but at least it's usable for non-JS users and is all text (html)

You offer an over-engineered design.

I don't see this taking off in the near future. Need many MANY improvements.

OK, so it isn't working, which is about what I was expecting. But curiously enough for a front page whose developers were confident enough to call it XHTML strict, it has 265 errors.

Then again, if it actually was XHTML strict, using even the correct MIME type, Internet Explorer wouldn't attempt to render it.

Please be a bit more careful with your terminology. There's a big difference between an HTML attribute and a Javascript property, and a big difference between an HTML tag and an HTML element.

is there any good reason why Firefox can get and set the .src attribute of an imageButton (an image with a tagName of input)

I'm going to interpret that as "why Firefox can get and set the src property of an HTMLInputElement corresponding to an <input> element with a type attribute of image.

The reason that Firefox can do this is because DOM 2 HTML defines a src property for this interface, and the Gecko developers attempt to conform to this specification.

but can't read its .complete attribute?

I'm going to interpret that as "but can't read its complete property?". Firefox can't read that property because this is a proprietary Microsoft property, and the Gecko developers only reverse engineer and emulate proprietary Microsoft properties when there's significant compatibility advantages (i.e. when lots of sites use the proprietary property with degraded behaviour or errors when it isn't available).

I don't like the way it dumps CSS and program errors to the javascript console without separating them from the javascript errors.

Take the Firebug extension for a spin, you'll probably find it useful.

Now that's a little FUDdy; the IE7 development team is trying much harder than in the past to improve its HTML and CSS rendering, but a monstrosity such as IE must be quite difficult to get up to par with the year 1999 let alone 2006 and beyond (with all the modularisation parties going on at W3C).

It's

document.createElement("script")

There's no such method as

createNode

in DOM (which, contrary to what the reviewer says, stands for Document Object Model, not Dynamic Object Model).

If Javascript isn't executable code what is it?

Yes, and if web applications were made up of nothing but Javascript, then you might have a point. But they are not. Javascript is just one non-essential component.

I've seen exploits that use Javascript, but never one that uses Flash.

Flash vulnerabilities certainly exist.

It seems you've assumed that my problem with it being a chunk of executable code is one of security. This is not the case. Given executable code, you've really only got two options - run it or don't run it. Given a series of documents in a well-understood format, with a bit of executable code on top, you can do all sorts of things without having to execute the code.

Tim Berners-Lee described this as the Principle of Least Power, and he was spot on. When you decompose something into simpler pieces that can stand alone, you enable greater functionality. Separating the content from the presentation from the behaviour, like HTML, CSS and Javascript do, it means there's a very low barrier to entry for manipulating that content. When you bundle it all back up like Flash does, it means there's a much higher barrier to entry.

Almost all those features you list are things that could be broken in Ajax depending on how it's coded and could be allowed in Flash depending on how it's coded.

This is not true. All the things I list are browser features that work in Ajax web applications because they build on the browser's basic data formats. All the things I list break in Flash because Flash throws away the browser's basic data formats and uses its own.

You could replicate similar features in your Flash applications, and many people have made various attempts over the years, but they are always cheap knock-offs that never work quite right.

For example, when a link is clicked with the middle mouse button, what should your Flash emulation of my browser feature do? In Firefox on my workstation, that should open in a new window. In Safari on my laptop, that should open in a new tab. If I'm in Windows, it should switch on autoscrolling. What is your Flash application going to do? If it does anything, it's going to be wrong in two out of three cases, and if it does nothing, then it's going to be wrong in all cases. Meanwhile, an Ajax web application works perfectly because the link is a normal HTML link that the browser understands, rather than a viewport into an external application that it has no understanding of.

Yes, it's possible to break such things in Ajax web applications, but they work by default with no extra code. But it's impossible for Flash applications to work correctly in this way.

Someone could develop a Greasemonkey type tool for Flash

Yes, but my point is that Greasemonkey doesn't work. Greasemonkey works with Ajax applications because they are using the browser's native formats and objects, not ignoring them. And a thousand other extensions are exactly the same. And extensions that will be dreamt up next week and implemented a month from now will be the same. Are you going to anticipate all of these extensions and features and build them into your Flash application as well?

This isn't about one particular feature. This is about features in general being built to work with the web, and breaking because Flash ignores everything that has gone before it. It builds a slick little presentation layer into a viewport that is only accessible in a web browser because that's the most convenient way for Macromedia to deliver Flash applications to people.

Honestly,

Well there's a bad idea. If you want your code to be cross platform, always go to the source for your information. Otherwise you're guaranteed to get burned. It's bad enough that Internet Exploder refuses to support DOM Events. Throwing stuff that may be Mozilla specific into the fray is a sure-fire way to make it that much worse.

Which is the standards-compliant, non-crazy-scripty way of doing it.

Actually, that's not true. The load() method was part of early DOM3LS drafts, but was taken out before the specification reached Recommendation status. As far as I'm aware, there's no non-draft specification describing load(), nor plans to write one.

XMLHttpRequest, on the other hand, is part of the draft "HTML 5" specification published by the WHATWG, and I expect it will remain there permanently.

Which is the standards-compliant, non-crazy-scripty way of doing it.

Actually, that's not true. The load() method was part of early DOM3LS drafts, but was taken out before the specification reached Recommendation status. As far as I'm aware, there's no non-draft specification describing load(), nor plans to write one.

XMLHttpRequest, on the other hand, is part of the draft "HTML 5" specification published by the WHATWG, and I expect it will remain there permanently.

Their "Highly reliable" site is "highly ugly", awkward, irregular on my 1.5.0.1 Firefox and uses ugly 256 color animated GIF's. Will they sue me for my Firefox had cached their clutterish artwork on my hard disk as a proprietary GIF's?

Oh, and their site has a damn wrong HTML.

Nice student's work!

I'll certainly agree to all of those. Not that I'm a member but I've seen my younger siblings using it when I visited home last.

And another interesting tidbit, have you seen the damn thing on the w3 validation site?! This might be a little off-topic but its certainly a bit nerdy. http://validator.w3.org/check?uri=www.myspace.com

And for those of you who aren't going to check it for themselves, the mainpage has 49 errors and it looks like it was coded by a moron. I'm no expert by anymeans but even I can do better than that.

Not related to the topic, but when I tried to validate http://slashdot.org/ at W3C's validator (http://validator.w3.org/), the validator responded that slashdot.org returned "403 Forbidden" error. Can anyone answer why this is so?

Not related to the topic, but when I tried to validate http://slashdot.org/ at W3C's validator (http://validator.w3.org/), the validator responded that slashdot.org returned "403 Forbidden" error. Can anyone answer why this is so?

Not related to the topic, but when I tried to validate http://slashdot.org/ at W3C's validator (http://validator.w3.org/), the validator responded that slashdot.org returned "403 Forbidden" error. Can anyone answer why this is so?

You missed the most important one /.

News for Nerds
Slashdot.org - HTML 4.01 Strict DTD
Slashdot! How could you! You have a background color of PINK!!!

And guess who has just two errors:

msn.com

I've heard for at least a year that MS is going for 100% XHTML 1.0 strict compliance on their MSN sites. And the main site is also 100% 4.0 compliant. Not that it's particularly "Web 2.0".

And guess who has just two errors:

msn.com

I've heard for at least a year that MS is going for 100% XHTML 1.0 strict compliance on their MSN sites. And the main site is also 100% 4.0 compliant. Not that it's particularly "Web 2.0".

Ok, validation isn't everything, and passing the validator is not 100% confirmation that your page is valid, but just for kicks (and to see if the best of web 2.0 passes the basics of web 1.0), let's pass their list through the W3C's HTML Validator and see what we get (links go to the validator results

Ok, validation isn't everything, and passing the validator is not 100% confirmation that your page is valid, but just for kicks (and to see if the best of web 2.0 passes the basics of web 1.0), let's pass their list through the W3C's HTML Validator and see what we get (links go to the validator results

Ok, validation isn't everything, and passing the validator is not 100% confirmation that your page is valid, but just for kicks (and to see if the best of web 2.0 passes the basics of web 1.0), let's pass their list through the W3C's HTML Validator and see what we get (links go to the validator results

Ok, validation isn't everything, and passing the validator is not 100% confirmation that your page is valid, but just for kicks (and to see if the best of web 2.0 passes the basics of web 1.0), let's pass their list through the W3C's HTML Validator and see what we get (links go to the validator results