×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

HTML V5 and XHTML V2

CmdrTaco posted more than 6 years ago | from the battle-of-the-markup dept.

The Internet 344

An anonymous reader writes "While the intention of both HTML V5 and XHTML V2 is to improve on the existing versions, the approaches chosen by the developers to make those improvements are very different. With differing philosophies come distinct results. For the first time in many years, the direction of upcoming browser versions is uncertain. This article uncovers the bigger picture behind the details of these two standards."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

344 comments

Where is Microsoft? (-1, Troll)

bogaboga (793279) | more than 6 years ago | (#21718104)

Is Microsoft involved in this at all? If it is, then I am worried. Other than that, I can only say..."bring it on." It will be a matter of some kind of plug-in to make all viable browsers feel at home in whatever environment they find themselves in.

Re:Where is Microsoft? (3, Informative)

morgan_greywolf (835522) | more than 6 years ago | (#21718134)

Both standards are being worked on the by the W3C standards group. Microsoft, along with all other major browser developers, is a member.

are html 5 and xhtml 2 worked on by W3C? (4, Informative)

falconwolf (725481) | more than 6 years ago | (#21718442)

Both standards are being worked on the by the W3C standards group.

According to the IBM paper html 5 is being done independently of the W3C. "In April 2007, the W3C voted on a proposal to adopt HTML V5 for review" is about as much as W3C has with html 5.

Falcon

Re:are html 5 and xhtml 2 worked on by W3C? (1)

gsnedders (928327) | more than 6 years ago | (#21718700)

There is an HTML WG at the W3C chartered [w3.org] to create a new version of HTML. A basis for review means, in W3C language, a starting document that will then be reviewed and changed as needed.

Re:are html 5 and xhtml 2 worked on by W3C? (1)

falconwolf (725481) | more than 6 years ago | (#21718824)

There is an HTML WG at the W3C chartered [w3.org] to create a new version of HTML. A basis for review means, in W3C language, a starting document that will then be reviewed and changed as needed.

However html 5 was started outside of the W3C by an independent group.

Falcon

Re:Where is Microsoft? (0)

Anonymous Coward | more than 6 years ago | (#21718166)

Why would microsoft be involved? They don't give a shit about web standards! Maybe it would be a good thing if they got involved - not to be confused with "in charge".

Re:Where is Microsoft? (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#21718292)

why should you care? you've probably never done a productive thing in your entire life. just keep on bitching about microsoft while you sit around and imagine yourself as being a geek.

Re:Where is Microsoft? (2, Insightful)

Anonymous Coward | more than 6 years ago | (#21718534)

you ever use anything with ajax? i.e. u like google maps? u can thank MS for bringing that out of javascript...

ms ain't the devil for development, sometimes they drive new features and functionality that would take forever to incorporate otherwise. do they always do it in the best of ways, no, but they do bring out good things from time to time...

Re:Where is Microsoft? (2, Insightful)

Bogtha (906264) | more than 6 years ago | (#21718874)

you ever use anything with ajax? i.e. u like google maps? u can thank MS for bringing that out of javascript...

Ajax-like techniques are possible without XMLHttpRequest and I don't believe Google Maps uses XMLHttpRequest anyway. If any organisation is responsible for the popularity of Ajax, it's Google, as it was when they started using it extensively that it really took off.

Re:Where is Microsoft? (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#21719248)

now hear this folks! it wasn't ford, dimler and benz that should be praised for the automobile. it's the people that use them.
 
what a crock. stop being such a google shill.

Re:Where is Microsoft? (1)

Bogtha (906264) | more than 6 years ago | (#21719470)

now hear this folks! it wasn't ford, dimler and benz that should be praised for the automobile. it's the people that use them.

One of my points was that XMLHttpRequest was never the only option for Ajax-like effects. It just happens to be the most convenient. Your analogy simply doesn't work.

stop being such a google shill.

If you had ever read my previous comments concerning Google you would know that I am in no way a shill for them; in fact I think the quality of their client-side code sucks and have said so many times.

Re:Where is Microsoft? (2, Insightful)

ShadowLeo (770494) | more than 6 years ago | (#21719408)

I believe what you are referring to is the "Hidden iframe" technique. Google [google.com] lists plenty of resources on using this technique.

Re:Where is Microsoft? (3, Informative)

Bogtha (906264) | more than 6 years ago | (#21719508)

That's one of them, yes. It really depends on what you want to do; for example you don't need anything other than typical mousedown event handlers for things like Google Maps, and you can use things like dynamically generated image URIs to send data back to the server asynchronously, which is compatible all the way back to Netscape 2. There are lots of options, the value in XMLHttpRequest is more convenience than functionality.

Re:Where is Microsoft? (3, Insightful)

Planesdragon (210349) | more than 6 years ago | (#21718860)

Is Microsoft involved in this at all? If it is, then I am worried.
If Microsoft isn't involved at all, then it will fail. That's what "monopoly" means.

i choose html v4.01 (-1, Troll)

Anonymous Coward | more than 6 years ago | (#21718140)

nobody cares about new web standards anymore.

Re:i choose html v4.01 (1)

Cyko_01 (1092499) | more than 6 years ago | (#21718186)

personally I like to use html 4.01 Transitional, professionally I use xhtml 1.0 strict whenever possible

Bet there still isn't a decent "Stop!" button (5, Interesting)

TheLink (130905) | more than 6 years ago | (#21718176)

You have to hand it to the W3C, they keep supplying web designers with rope.

I've been trying to get them (and browser people) to include a security oriented tag to disable unwanted features.

Why such tags are needed:

Say you run a site (webmail, myspace (remember the worm?), bbs etc) that is displaying content from 3rd parties (adverts, spammers, attackers) to unknown browsers (with different parsing bugs/behaviour).

With such tags you can give hints to the browsers to disable unwanted stuff between the tags, so that even if your site's filtering is insufficient (doesn't account for a problem in a new tag, or the browser interprets things differently/incorrectly), a browser that supports the tag will know that stuff is disabled, and thus the exploit fails.

I'm suggesting something like:

<restricton lock="Random_hard_to_guess_string" except="java,safe-html" />
browser ignores features except for java and safe-html.
unsafe content here, but rendered safely by browser
<restrictoff lock="wrong_string" />
more unsafe content here but still rendered safely by browser
<restrictoff lock="Random_hard_to_guess_string" />
all features re-enabled

safe-html = a subset of html that we can be confident that popular browsers can render without being exploited e.g. <em>, <p>).

It doesn't have to be exactly as I suggest - my main point is HTML needs more "stop/brake" tags, and not just "turn/go faster" tags.

Before anyone brings it up, YES we must still attempt to filter stuff out (use libraries etc), the proposed tags are to be a safety net. Defense in depth.

With this sort of tag a site can allow javascript etc for content directly produced by the site, whilst being more certain of disabling undesirable stuff on 3rd party content that's displayed together (webmail, comments, malware from exploited advert/partner sites).

Re:Bet there still isn't a decent "Stop!" button (3, Insightful)

LiquidCoooled (634315) | more than 6 years ago | (#21718230)

Why not just simplify your entire comment:

Content from a 3rd party runs in a more restrictive context than the primary site (this includes frames etc).
You are then not held at the whim of a web admin to ensure these tags are included.

Or you could just use the noscript addin right now and choose which sites you trust at your discretion.

Re:Bet there still isn't a decent "Stop!" button (2, Insightful)

TheLink (130905) | more than 6 years ago | (#21718364)

Can't do that. That's because often the website you visit is the one sending the 3rd party data.

Think webmail (yahoo, gmail etc), when you receive spam, your webmail provider is the one sending you the data.

Usually they will try to filter the content to make it safe. BUT as history shows it's not always 100%.

The W3C or browser maker might also make a new tag/feature that your filtering libraries aren't aware of (e.g. old sites with guestbooks that might not filter out the "latest and greatest stuff").

With my proposal, users can enable javascript+flash for stuff like youtube, and youtube can be more certain that the comments about the video will be treated as plain html by browsers that support the security tag. Stuff that slips through the filters would likely still be rendered inactive by those browsers.

Re:Bet there still isn't a decent "Stop!" button (0)

coryking (104614) | more than 6 years ago | (#21718254)

I like your idea for security tags, I could see your method still trashing the page with broken HTML. A quick idea might be to shove something in a stylesheet, a script, or the <head></head>. Whatever it would be, it would refer to the id of the block you want to set and out be out of the guts of your HTML. Dunno how my idea would work on a site like slashdot where you have 300 things you want to secure... yours would be more straightforward in that case. In the perfect world, you'd want to isolate out the untrusted data to another document that would get included.

$100 says we both are on the right track, but there is a good reason it wouldn't work.

Re:Bet there still isn't a decent "Stop!" button (2, Interesting)

wizardforce (1005805) | more than 6 years ago | (#21718316)

good idea, although in the case of myspace, it wasn't a technical problem that prevented them from keeping pages "safe" [eg. preventing the execution of malicious code] it had to do with the fact that myspace, by default allows everything *on purpose* they could have built the system such that certain tags would/could be disabled [slashdot is an example] and as big as myspace is, resources are not a problem- apathy and the need to incorporate everything user generated into pages [to hell with security! we want to build our pages any which way we like!] is.

Re:Bet there still isn't a decent "Stop!" button (3, Insightful)

throup (325558) | more than 6 years ago | (#21718352)

Could you not get around that by injecting code like:

</restriction> <!-- closes the existing restriction zone. Might not pass as valid XML, but HTML browsers work with tag soup. -->
Something evil!!!
<restriction lock="I don't really care here" except="everything"> <!-- This bit is purely optional -->

Obviously I need to work on something more destructive than "Something evil!!!" before I attempt to conquer the planet...

Re:Bet there still isn't a decent "Stop!" button (2, Insightful)

TheLink (130905) | more than 6 years ago | (#21718454)

No because the closing tag has to have a lock string that matches the lock on the opening tag.

My attempts to change the world (albeit by a little bit) aren't going very well either - it's been more than 5 years since I first proposed the tags, but so far the W3C and Mozilla bunch have preferred to make other "more fun" stuff instead...

Maybe Microsoft has subverted the W3C too :).

Re:Bet there still isn't a decent "Stop!" button (1)

coryking (104614) | more than 6 years ago | (#21719340)

I think it is still to easy to exploit is the problem. I'm sure if you thought hard, you could write some evil HTML to route around it and run your javascript. You'd just have to somehow get the big_key thing in your proposal.

The only real secure way is to isolate the untrusted bits into their own block.... like how you do multipart mime documents in email or something. You'd need a tag to reference the "external" untrusted bits and have the browser render them in a sandbox. Even in this case, you can exploit it by injecting your own stuff to trash where the boundary between the two documents are (like how you can exploit poorly implemented webforms that send email by injecting your own email headers :-).

I'm sure there are a wide range of technical reasons this would be hard to implement though. I'm already shooting holes in what I typed... even if you had the untrusted bits pulled down in a separate HTTP request there are problems like "it would be very slow" :-)

Re:Bet there still isn't a decent "Stop!" button (1)

throup (325558) | more than 6 years ago | (#21718482)

I see the error in my own logic: you are treating restriction as a empty element, so I can't inject a closing tag for it.

Now I have realised that, another (less critical) concern occurs to me: any user agent would have to treat your document as tag-soup instead of parsing a DOM-tree because that would be the only way to recognise the on and off states. Whether you see that as a problem or not depends on your attitude to the difference between HTML 4 and XHTML 1; an argument which is surely taking place elsewhere on this page so I won't go into it here :-).

Re:Bet there still isn't a decent "Stop!" button (4, Insightful)

Bogtha (906264) | more than 6 years ago | (#21718370)

even if your site's filtering is insufficient (doesn't account for a problem in a new tag

Why would your site let through new tags that it doesn't recognise? Use a whitelist.

the browser interprets things differently/incorrectly

This only usually occurs if you let through malformed HTML. Use tidy or similar to ensure you only emit valid HTML. Not to mention the fact that the whole problem is caused by lax parsing — something the W3C has been trying to get people to give up on with the parsing requirements for XML.

safe-html = a subset of html that we can be confident that popular browsers can render without being exploited e.g. <em> , <p> ).

You could define such a subset using the modularised XHTML 1.1 or your own DTD.

Before anyone brings it up, YES we must still attempt to filter stuff out (use libraries etc), the proposed tags are to be a safety net. Defense in depth.

Yes, but it won't be actually used that way. If browsers went to the trouble of actually implementing this extra layer of redundancy, all the people with lax security measures would simply use that as an alternative and all the people who take security seriously will use it, despite it not being necessary. I think the cumulative effect would be to make the web less secure.

Re:Bet there still isn't a decent "Stop!" button (1)

coryking (104614) | more than 6 years ago | (#21718444)

You could define such a subset using the modularised XHTML 1.1 or your own DTD.
Or monkeys could fly out of our asses :-)

The idea of modular XHTML is a nice one, but unless I'm missing something, this new XHTML modular thingy we are talking about would still need to be supported by the browser, right? In other words, it will not be supported and is a waste of time.

Modular XHTML is a nice idea in theory, but honestly... nobody will use a module unless it is implemented by Firefox and IE. Can you name any existing XHTML modules implemented by both browsers?

Er.. atom or rss?

Re:Bet there still isn't a decent "Stop!" button (1)

Bogtha (906264) | more than 6 years ago | (#21718572)

The idea of modular XHTML is a nice one

It's not an idea, it's been a published Recommendation [w3.org] for over six years.

this new XHTML modular thingy we are talking about would still need to be supported by the browser, right?

No. If the server validates the untrusted data, what's the point in the browser doing it too? Validation is deterministic, you don't get double the security by doing it twice.

Can you name any existing XHTML modules implemented by both browsers?

All of them. XHTML 1.1 is XHTML 1.0 Strict broken up into modules.

Er.. atom or rss?

Those are not XHTML.

Re:Bet there still isn't a decent "Stop!" button (1)

coryking (104614) | more than 6 years ago | (#21718660)

While it is true that the server should validate the inbound (and really outbound) HTML, you have to admit it isn't easy. In perl land, there are some CPAN modules to help, but none of them ever feel right. I'm not sure what the answer is really. But I think the OP's idea was for a couple extra "hey Mr. Browser, yeah, we suck about validation... please dont trust this crap here.. we tried our best on the server, but really, you shouldn't trust it either".

Those are not XHTML.
That was what I thought.. just guessing. MathML or whatever? I'm not sure, but does IE do that?

Re:Bet there still isn't a decent "Stop!" button (1)

Bogtha (906264) | more than 6 years ago | (#21718800)

While it is true that the server should validate the inbound (and really outbound) HTML, you have to admit it isn't easy.

On the contrary, it's very easy. There's plenty of tools out there to do this for you.

In perl land, there are some CPAN modules to help, but none of them ever feel right.

What do you mean by "feel right"?

I think the OP's idea was for a couple extra "hey Mr. Browser, yeah, we suck about validation... please dont trust this crap here.. we tried our best on the server, but really, you shouldn't trust it either".

What do you think the browser is going to do that you can't?

Those are not XHTML.

That was what I thought.. just guessing. MathML or whatever? I'm not sure, but does IE do that?

That's not XHTML either. Once more, XHTML 1.1 is XHTML 1.0 broken up into modules. The OP wanted to be able to specify permitted features of XHTML in a fine-grained manner. XHTML 1.1 defines modules you can use, or you can define your own DTD. Stop thinking about non-XHTML features like Atom and MathML! This is about normal XHTML like <script> , <table> , etc.

Re:Bet there still isn't a decent "Stop!" button (4, Insightful)

coryking (104614) | more than 6 years ago | (#21719136)

On the contrary, it's very easy. There's plenty of tools out there to do this for you.
Cow Crap!

You want easy? SQL injections are easy to handle. Just use a parameterized query so you don't have to mix tainted data with your trusted SQL.

Back in the stone age before php thought parameterized queries were more then enterprise fluffery, you were forced to mix your user data with your SQL. And oh were the results hilarious! It look three tries (and three fucking functions) for PHP/mysql to get their escape code right and I'm sure you can still inject SQL with "mysql_real_escape_string()" in some new unthought of way.

There is no "parameterized query" with HTML. You are *forced* to mix hostile user data with your trusted HTML. If it was that hard to sanitize an "easy" language like SQL, how hard is it to sanitize a very expressive language like HTML?

You are telling me all those CPAN modules handle the hundreds of ways you can inject HTML into the dozens of different browsers? How many ways can you make an angle bracket and have it interpreted as a legit browser tag? How many ways can you inject something to the end of a URL to close the double quote and inject your javascript? How many ways, including unicode, can you make a double quote? Dont forget, your implementation cannot strip out the Unicode like I've seen some filters do - I need the thing to handle every language! I would guess there are thousands of known ways to inject junk into your trusted HTML.

I promise you that even the best CPAN module is still exploitable in some way not considered by the author. And I'd be insane to roll my own, as I'm not as smart as she is.

Don't kid yourself and thinking filtering user generated content is easy. It is very, *very* hard.

Re:Bet there still isn't a decent "Stop!" button (1)

BlueParrot (965239) | more than 6 years ago | (#21719178)

What do you think the browser is going to do that you can't?


Your implication is basically that web-developers are more competent in terms of security than those who design the clients, and thus the client should just swallow the stuff without even bothering. In reality there are MANY people who make web pages who would probably trust the browser developers a lot more than they trust themselves not to make a mistake.

Also, you're not looking at this from the point of view of the user. I might want to tell my browser to trust John Smith not to put malicious stuff into his webpage, but that doesn't mean I trust him to be capable of finding all known and unknown exploits some of the third parties may have sent him. In this situation I would very much appreciate it if John Smith had marked the data on his webpage saying "this is from me" , "this is from somebody else".

Re:Bet there still isn't a decent "Stop!" button (2, Interesting)

BlueParrot (965239) | more than 6 years ago | (#21718378)

There is the object tag. It can be used as a client-side include. All it really needs is a "permissions" attribute or something like that:

<object permissions="untrusted" codetype="text/html" codebase="foo.html">
</object>

Re:Bet there still isn't a decent "Stop!" button (0)

Anonymous Coward | more than 6 years ago | (#21718634)

Yes that could work but it's a bit harder to do for people building websites - need a working link back to foo.html and something needs to handle the subsequent request for foo.html.

Re:Bet there still isn't a decent "Stop!" button (2, Insightful)

Ambush Commander (871525) | more than 6 years ago | (#21718456)

This is a novel technique (the unique, hard to guess string, which easily could be a hash of the document and a secret salt the website has) I have not seen before, but this merely punts the issue to the browsers. It cannot be solved there (as you mention); in fact, it does not even begin to solve it: think about the legacy browsers floating around the web. I don't even trust browser vendors to lock down all of this code: they also have their own security bugs.

There is also the minor point that your method is almost completely incompatible with DOM, but I'll overlook that for now. :-)

Re:Bet there still isn't a decent "Stop!" button (0)

mattwarden (699984) | more than 6 years ago | (#21719026)

But, in order to support "web 2.0" apps, browsers would need to allow this entity to be scriptable in the DOM (otherwise, I don't see how you could support restricting parts of dynamic content). And if that is the case, then a script could simply un-restrict any part of the page at will.

Do you have a solution to handle this without causing issues with dynamic content?

Where are we now? (1)

h4rm0ny (722443) | more than 6 years ago | (#21718192)


That's a very good article - as always IBM give a well-written introduction to the subject. But exactly what is the state of implementation of these? As far as I can gather, no browser maker has started to implement support for either. Is that correct? It would be useful to have some idea of the time scales we can expect on these both. Anyone know more about the state of play?

why is this tagged internet (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#21718198)

internet is so much more than HTML5/XHTML2

I bet my ass.. (0)

pkadd (1203286) | more than 6 years ago | (#21718204)

that Microsoft will not support it.. afterall they never fully supported HTML in the first place :P on a serious note, though.. i urge every web developer to stop treating MSIE as a special case, since it does not follow standards. Instead, code it according to the w3 standards, and if IE doesn't display it properly, add something that redirects users to an info-site about why they can't view the site, and recommend that they download a decent browser.

Re:I bet my ass.. (3, Insightful)

coryking (104614) | more than 6 years ago | (#21718294)

I urge every web developer to stop treating MSIE as a special case, since it does not follow standards
No offense to you, but I love how every single person who smugly suggests this usually has a link to a website that looks like shit when viewed on any browser.

This also seems to be the case when ever somebody bitches about web designers changing fonts, using javascript, or doing something to make their page look nice. You visit the websites created by the "changing the font at all, even in the stylesheet, is evil" or the classic "why are you trying to use two columns? two columns are evil" religious zealots and all their pages look really dull and boring. Long streams of times new roman. I guess this is our future, eh?

Re:I bet my ass.. (1)

pkadd (1203286) | more than 6 years ago | (#21718344)

read the faq, it's explained there. plus i am a web developer, not a designer, that's ahuge difference.

q: What is the definition of someone who codes php and html?
a: someone who hangs with programmers

Re:I bet my ass.. (1, Troll)

coryking (104614) | more than 6 years ago | (#21718410)

So if you are a developer and not a designer, why do you think you are qualified to even talk about how we should design our HTML or what browsers we should target?

Stop being so damn myopic and think like a designer or even *gasp* a business person. You are telling people that they should sign up to your religion, even if it means cutting off 70% of their market share. If you stood even an inch outside your "web developer" click and looked at the big picture, you'd see how insane you sound.

But yeah yeah yeah. IHBT and I'll HAND, thanks.

Re:I bet my ass.. (1, Insightful)

Bogtha (906264) | more than 6 years ago | (#21718422)

the classic "why are you trying to use two columns? two columns are evil" religious zealots

I don't think I've ever seen anybody say this. Example?

all their pages look really dull and boring.

In actual fact, their pages don't look boring at all. Your default browser setup looks boring.

Remember, a web design doesn't look like anything until it is realised with the combination of hardware, browser defaults and personal settings. If you think a site that uses your preferences looks boring, then your preferences are to blame.

Re:I bet my ass.. (1)

coryking (104614) | more than 6 years ago | (#21718620)

I don't think I've ever seen anybody say this. Example?
Exhibit A [slashdot.org] . Kinda Exhibit B [slashdot.org] .

Okay.. so I overstated myself a bit, sue me; this is slashdot after all, right? You know what I'm saying though, there are a lot of people who at least in this little corner of our interweb seem to think that unless we design explicity for an 80 column lynx terminal we are going to hell - I'm not talking degrade nicely for a lynx terminal, I'm talking "designed for lynx(tm)" and forging anything more advanced.

I bet you can dig up people in 1997 that were bitching on slashdot about people using images.. I mean IMAGES for christ sake! I'm sure those people are to this day reading slashdot with images disabled using their parents 9600 baud modem and a trumpet winsock slip connection.

By the way... this comment is borderline what I'm talking about [slashdot.org] and so is this one [slashdot.org] or this one [slashdot.org] .

Despite appearing like one, I'm not an insane pixel perfect guy either. I just think our standards really suck right now and don't actually meet the needs of either designers or developers. "Pixel Perfect" only exists because it is hard to make fluid layouts with our current bag of tricks. I enjoy bashing W3C zealots almost as much as bashing religious zealots. Both are too trapped in their dogma to see the real world.

Hopefully CmdrTaco will require you to use javascript or flash to post comments so we can finally weed those people out :-)

Re:I bet my ass.. (1)

BlueParrot (965239) | more than 6 years ago | (#21718532)

This also seems to be the case when ever somebody bitches about web designers changing fonts, using javascript, or doing something to make their page look nice.


Strawman. Nobody minds a page which uses these things properly ( i.e gracefully fall back when not supported , don't rely on them for navigation etc... ). Problem is, some people get it VERY wrong. There's a Swedish news site I like because they have good journalists, but their web developers deserve to be shot. They actually implemented a "marque-like" news scroller using javascript and DHTML, the thing is slow as hell and for some reason interferes with scrolling the page (i'm guessing the engine chokes when it tries to render an element which is moving vertically across the edge of the window while scrolling with "smooth"-scroll enabled ). So why don't I just disable javascript for that page? Well, the site's navigation relies on it...

Btw, if you actually need javascript to make your page "look nice" then I'd claim that you are actually doing something wrong. If you did it right it would look nice even when printed.

Re:I bet my ass.. (1)

coryking (104614) | more than 6 years ago | (#21718756)

Can you make meebo look nice or be as functional without javascript? What about gmail? What about a web application that wants to fill the browser window in a fluid way (i.e. 100% height). Try doing that without javascript.

Can you make a comment system that is easy to use without javascript? Sure, but you can make a much more enjoyable user friendly one once you limit your scope to javascript only.

Your example of site navigation with javascript? It is poor design not because it is using javascript. It is poor design because it isn't very user friendly. The OP troll dude has a really shitty navigation system, but I dont see any javascript. Testing the web page on users would have probably fixed both peoples design.

Maybe the best way to fix usability bugs is *using* javascript! Do you think Digg would have been at all as popular if it didn't use javascript for it's voting buttons? In that case, javascript significantly enhanced the user experiance. On slashdot, javascript comments significantly improve the ability to track threaded comments. What about all those neat overlays netflix uses? Those also improved the user experience significantly. Can you do that without javascript?

Shitty javascript site navigation is just a sign that the web designers and developers didn't know usability from a whole in the ground. Used by professionals who know what they are doing, javascript is a powerful tool to improve the user experience of any website.

In other words, javascript is a powerful tool. Use it wisely.

Re:I bet my ass.. (2, Insightful)

Bogtha (906264) | more than 6 years ago | (#21718914)

Please re-read the original comment. It was saying that you can use JavaScript without being backwards-incompatible. You seem to have confused this with avoiding JavaScript altogether. Every single point you make is good against an argument that JavaScript should be avoided, but completely irrelevant to somebody asking for it to degrade gracefully, which is the distinction BlueParrot was trying to explain to you.

Re:I bet my ass.. (2, Insightful)

coryking (104614) | more than 6 years ago | (#21719214)

Sweet.. So we agree and I owe you some kind of beer. Slashdot makes everybody a flamer :-)

There is a very strong business case for good degradation too... Last I checked, Google doesn't interpret your javascript. You want good SEO, you better make sure the content flows right in lynx (which is the best way to think about how google sees the page).

Sadly, screen readers are pretty much like google too, but I really think we aren't feeding screen readers enough information for them to properly read a page. I really dont know the answer to screen readers. I've never played much with it, but in the windows world, if you were doing a winforms app you can sprinkle your form with metadata to help screen readers. But again, even the winforms solution is a bit like an alt tag.

When I took a usability class, we watched some video I wish I could find of somebody using a screen reader. Talk about intense. Imagine reading a web page, or any document for that matter, while looking through a straw that is only one word wide. That is about what it is like. Now read it with the voice cranked to "hyper fast talk mode" and that is how the blind experience the web. Very interesting and eye opening.

Whatever the future holds (silverlight/flex), we need to make sure the standard has some good, juicy metadata to help out screen readers (and google, really).

Where was I now?

Re:I bet my ass.. (1)

stubear (130454) | more than 6 years ago | (#21718388)

I think you really need to change your domain name to vomit.com. It would be far more fitting given your web design skills.

Re:I bet my ass.. (3, Informative)

bcrowell (177657) | more than 6 years ago | (#21718642)

Anyone thinking of clicking on the parent's link (to vumit.com) should realize that it's a goatsex-style shocker page.

Web Applications? (0)

Anonymous Coward | more than 6 years ago | (#21718210)

All the talk about web applications these days, but a W3C-endorsed user interface markup language (like XUL/XAML) is nowhere to be seen.

A next-gen "HTML" should support common application widgets like panels, toolbars, menu's, tabs etc etc. Without it, it's not worth the effort IMO.

Linus is right (-1, Troll)

Anonymous Coward | more than 6 years ago | (#21718238)

I have to agree with Linus on this one.
His position on the matter is right on as always.

Both garbage (1, Informative)

Anonymous Coward | more than 6 years ago | (#21718240)

I'm sticking with XHTML1.0 strict. Perhaps I'll use XHTML1.1 with appropriate DTD if I ever need to support the canvas element, other than that... none of this stuff is what I want from a markup language.

Browser vendors choice (4, Insightful)

gsnedders (928327) | more than 6 years ago | (#21718278)

All the browser vendors have already said they will support HTML 5 (yes, that includes MS) and all but MS have said they won't support XHTML 2 (MS hasn't made much of an effort to suggest they will support it either).

As it stands, with both XHTML 5 and XHTML 2 using the same namespace, it is only possible to support one of the two.

Re:Browser vendors choice (1)

CastrTroy (595695) | more than 6 years ago | (#21718870)

MS was part of the W3C and at one time said they would support CSS. We all know where that has gotten us.

Re:Browser vendors choice (1)

mattwarden (699984) | more than 6 years ago | (#21719038)

Can you explain why identifying the markup version with a dtd would not allow them to support both?

Why not ditch HTML? (3, Interesting)

forgoil (104808) | more than 6 years ago | (#21718302)

Why not just go with XHTML all the way? I always though that the best way of "fixing" all the broken and horribly written HTML out there on the web would be to build a proxy that could translate from broken HTML to nicely formed XHTML and then send that to the browser, cleaning up this whole double rendering paths in the browsers (unless I missunderstood something) etc. XHTML really could be enough for everyone, and having two standards instead of one certainly isn't working in anyones favor.

Re:Why not ditch HTML? (1, Informative)

Anonymous Coward | more than 6 years ago | (#21718470)

The position taken is that XML is too hard and parse errors are scary or something. With XML, you need to make sure that your document contents are correctly encoded, use the DOM instead of document.write() and should be serving it with the correct MIME type (when appropriate). For some reason, it's deemed more important that cowboy web designers are permitted to continue ripping off their clients with inaccessible and invalid markup rather than advancing the web for the benefit of competent developers.

XHTML 1.0 strict is where it's at and there'll be no change with the release of HTML5 or XHTML 2.0 recommendations.

Re:Why not ditch HTML? (1)

irc.goatse.cx troll (593289) | more than 6 years ago | (#21719320)

You can only go so far to verify the content you serve is valid XML. The complexity of doing full DOM tree walking on every comment, embeded ad, RSS news feed, etc that will all be served into your page is just not worth it.

Re:Why not ditch HTML? (5, Interesting)

GrouchoMarx (153170) | more than 6 years ago | (#21718562)

As a professional web developer and standards nazi, I'd agree with you if it weren't for one thing: User-supplied content.

For content generated by the site author or a CMS, I would agree. Sending out code that is not XHTML compliant is unprofessional. Even if you don't want to make the additional coding changes to your site to make it true XHTML rather than XHTML-as-HTML, All of the XHTML strictness rules make your code better, where "better" means easier to maintain, faster, less prone to browser "interpretation", etc. Even just for your own sake you should be writing XHTML-as-HTML at the very least. (True XHTML requires changes to the mime type and to the way you reference stylesheets, and breaks some Javascript code like document.write(), which are properly left in the dust bin along with the font tag.)

But then along comes Web 2.0 and user-supplied content and all that jazz. If you allow someone to post a comment on a forum, like, say, Slashdot, and allow any HTML code whatsoever, you are guaranteed to have parse errors. Someone, somewhere, is going to (maliciously or not) forget a closing tag, make at typo, forget a quotation mark, overlap a b and an i tag, nest something improperly, forgets a / in a self-closing tag like hr or br, etc. According to strict XHTML parsing rules, that is, XML parsing rules, the browser is then supposed to gag and refuse to show the page at all. I don't think Slashdot breaking every time an AC forgets to close his i tag is a good thing. :-)

While one could write a tidy program (and people have) that tries to clean up badly formatted code, they are no more perfect than the "guess what you mean" algorithms in the browser itself. It just moves the "guess what the user means" algorithm to the server instead of the browser. That's not much of an improvement.

Until we can get away with checking user-submitted content on submission and rejecting it then, and telling the user "No, you can't post on Slashdot or on the Dell forum unless you validate your code", browsers will still have to have logic to handle user-supplied vomit. (And user, in this case, includes a non-programmer site admin.)

The only alternative I see is nesting "don't expect this to be valid" tags in a page, so the browser knows that the page should validate except for the contents of some specific div. I cannot imagine that making the browser engine any cleaner, though, and would probably make it even nastier. Unless you just used iframes for that, but that has a whole host of other problems such as uneven browser support, inability to size dynamically, a second round-trip to the server, forcing the server/CMS to generate two partial pages according to god knows what logic...

As long as non-programmers are able to write markup, some level of malformed-markup acceptance is necessary. Nowhere near the vomit that IE encourages, to be sure, but "validate or die" just won't cut it for most sites.

Re:Why not ditch HTML? (1)

falconwolf (725481) | more than 6 years ago | (#21718674)

I don't think Slashdot breaking every time an AC forgets to close his i tag is a good thing. :-)

That's one reason I always try to preview before I post, no actually I preview so I can edit before posting. However I still let some mistake slip by.

While one could write a tidy program (and people have) that tries to clean up badly formatted code, they are no more perfect than the "guess what you mean" algorithms in the browser itself. It just moves the "guess what the user means" algorithm to the server instead of the browser. That's not much of an improvement.

Though using one adds work, a validater helps here.

Falcon

Re:Why not ditch HTML? (3, Interesting)

hey! (33014) | more than 6 years ago | (#21719206)

Well, according to TFA, because XHTML, while terrific for certain kinds of applications, doesn't solve the most pressing problems of most of the people working in HTML today. It can do, of course, in the same way any Turing equivalent language is "enough" for any programmer, but that's not the same thing has being handy.

At first blush, the aims of XHTML 2.0 and HTML 5 ought to be orthogonal. Judging from the article, I'd suspect it is not the aims that are incompatible, but the kinds of people who are behind each effort. You either think that engineering things in the most elegant way will get things off your plate more quickly (sooner or later), or you think that concentrating on the things that are on your plate will lead you to the best engineered solution (eventually).

I'm guessing that the XHTML people might look at the things the HTML 5 folks want to do and figure that they don't really belong in HTML, but possibly in a new, different standard that could be bolted into XHTML using XML mechanics like name spaces and attributes. Maybe the result would look a lot like CSS, which has for the most part proven to be a success. Since this is obviously the most modular, generic and extensible way of getting the stuff the HTML 5 people worry about done, this looks like the perfect solution to somebody who likes XHTML.

However, it would be clear to the HTML 5 people that saying this is the best way to do it doesn't mean anything will ever get done. It takes these things out of an established standard that is universally recognized as critical to support (HTML) and puts them in a newer weaker standard that nobody would feel any pressure to adopt anytime soon. A single vendor with sufficient clout (we name no names) could kill the whole thing by dragging its feet. Everybody would be obliged to continue doing things the old, non-standard way and optionally provide the new, standardized way for no benefit at all. Even if this stuff ideally belongs in a different standard, it might not ever get standardized unless it's in HTML first.

Personally, I think it'd be nice to have both sets of viewpoints on a single road map, instead of in two competing standards. But I'm not holding my breath.

Re:Why not ditch HTML? (2, Insightful)

jonbryce (703250) | more than 6 years ago | (#21719306)

I think the problem is that (x)html is trying to be two very different things. It is trying to be a universal document format for presenting information. It is also trying to be a universal presentation manager for thin client applications. The technical requirements for these are very different, and it may well be that two different standards are appropriate.

reboot the web! (4, Insightful)

wwmedia (950346) | more than 6 years ago | (#21718318)

am I the only developer thats sick of this html / css / javascript mess??

people/companies are trying to develop rich applications using decade old markup language thats improperly supported by different browsers (even firefox doesn't fully support css yet) and is a very ugly mix right now, its like squeezing a rectangular plasticine object thru a round,triangular and starshaped holes at the same time



the web needs a reboot


we need a programming language that:
*works on the server and the client
*something that makes making UIs as easy as drag and drop
*something that does not forgive idiot html "programmers" who write bad code
*something that doesnt suffer from XSS
*something that can be extended easily
*something that can be "compiled" for faster execution
*something thats implemented same way in all browsers (or even better doesnt require a browsers and works on range of platforms)

Do you work for Adobe? (0)

Anonymous Coward | more than 6 years ago | (#21718348)

It sure sounds like you're suggesting Flash/Flex/Apollo with something like ColdFusion/Java on the backend.

Re:reboot the web! (0)

Anonymous Coward | more than 6 years ago | (#21718476)

"we need a programming language that: ..."

No doubt. But which proprietary solution should be adopted in an open forum that is the web? Because you can't even get Microsoft to support XHTML or ODF let alone some new web engine running on their products that isn't theirs. And if they do it will have to proprietary require a license causing a restriction who can play in the game before Microsoft will consider it.

   

Re:reboot the web! (2, Informative)

Anonymous Coward | more than 6 years ago | (#21718584)

There are a lot of people who think that web, Ajax and Flash applications are a very bad thing. Not just users, but also noted developers and usability experts.

More thoughts on why Ajax is bad for web applications [zdnet.com] : this is about how Ajax apps are often very fragile and usually don't work as expected.

Ephemeral Web-Based Applications [useit.com] : usability guru Jakob Nielsen writes this great article that goes into depth about how most web apps are complete failures when it comes to usability. Even something as basic as navigation quickly becomes unintuitive and difficult.

Why the .NET framework makes for bad web applications [beamartyr.net] : this explains why .NET apps using some of the latest technology around is often a bad idea.

You're not on a fucking plane (and if you are, it doesn't matter)! [37signals.com] : Ruby on Rails creator David Heinemeier Hansson talks about how we don't need web apps everywhere.

There are a lot of anti-web app articles here. Having done a lot of web apps for years now i think a lot of them are spot on although they are really against web apps when web apps probably are the best tool for the job:
Web apps: taking five years to get to where desktop apps were a decade earlier? [blogsavy.com]

A JavaScript tip built on years of experience: try to avoid JavaScript. [blogsavy.com]

Why is Web page layout still such a problem? [blogsavy.com]

Web 2.0: A serious case of diarRIA. [blogsavy.com]

AJAX: the "ricer" of the software development world? [blogsavy.com]

Keep the Web in the browser, please. [blogsavy.com]

The wasteful nature of pointless JavaScript effects. [blogsavy.com]

An example of the sorry state of JavaScript today. [blogsavy.com]

The Web is inherently an inadequate application development platform. [blogsavy.com]

Where is the developer productivity increase with JavaScript-based Web applications? [blogsavy.com]

A great Web developer is a waste of a really great application developer. [blogsavy.com]

Re:reboot the web! (1)

cyfer2000 (548592) | more than 6 years ago | (#21718656)

I've just got a message from God this morning, he is working on reinventing the whole universe to plug those black holes now, and the request of a better web will be saved in a bugzilla database and be fulfilled several billion years later.

Re:reboot the web! (1)

fulldecent (598482) | more than 6 years ago | (#21718754)

You can't WYSIWYG-author semantic content.

Re:reboot the web! (1)

coryking (104614) | more than 6 years ago | (#21718950)

Semantic is awesome for "make the navigation column have a the colour of Mt Everestt on a cool summer day". Semantic is awesome for "make all the links in my header have an icon in front of them". Semantic is great for "Make my pull quotes use comic sans and set them in a box with a drop shadow and a reflection under them" But you still need to address basic presentation!!! I still need to make the three column grid in a straightforward way!! Where is my grid tag? Where is my "flow content between these columns"? You know how sweet it would be if done right?

I'm a tech writer by training. I know all about semantic markup and it's niceness. But I'm also a usability person and I know how getting the *presentation* of the content right is just as important as the content itself. In a very real way, the presentation *is* the content just as much as the content is the presentation! Either one, poorly done, ruins the message.

You could have the worlds best linux documentation in the world, written so well grandma can recompile her kernel, but if it is presented poorly (like as in "info" document), you might as well just write "Fuck you asshole, docks are for pussies, read the source code" because nobody will understand your docs. If it is all done as a single column and it has some grainy goat face on the top left of the page, grandma will not even bother. She'll use BitchX and ask the IRC nerds instead. If the designer didn't use a readable screen font, or left it to the browser default of times new roman, she will not be able to read it. She doesn't know how to change the browser font yet either--how can she without reading the documentation?

Telling us we are evil for hacking around a shitty semantic markup language is a surefire way to get ignored. Fight presentational markup like the catholic church fights sex and you'll loose your following. Right now it is hard to give grandma a good looking website that makes a "I can trust this page" impression without resorting to hacked HTML. We need good layout so grandma trusts our linux documentation!

Ever hear of XAML? XAML is the sound of the future if the W3C doesn't deliver...

Re:reboot the web! (3, Interesting)

MyDixieWrecked (548719) | more than 6 years ago | (#21719442)

I agree with you about some things you're saying...

You need to realize that the markup language shouldn't be used for layout. Your comment about "making UIs as easy as drag and drop" can be done with a website development environment like Dreamweaver. You need a base language for that.

Personally, I think that XHTML/CSS is going the right way. It can be extended easily, it's simple enough that that basic sites can be created by new users relatively quickly, however complex layouts still require some experience (yeah, it's got a learning curve, but that's what Dreamweaver is for).

The whole point of XHTML/CSS is that it's not designed to be implemented the same way in all browsers. It's designed so that you can take the same "content" and render it for different devices/media (ie: home PC, cellphone, paper, ebook) simply by either supporting a different subset of the styling or different stylesheets altogether.

Have you ever tried to look at a table-based layout on a mobile device? have you ever tried to look at a table-based layout on a laptop with a tiny screen or a tiny window (think one monitor, webbrowser, terminal, and code editor on the same 15" laptop screen)? table-based layouts are hell in those scenarios. Properly coded XHTML/CSS pages are a godsend, especially when you can disable styles and still get a general feel for what the content on the page is.

I'm not sure if I 100% agree with this XHTMLv2 thing, but I think XHTMLv1 is doing great. I just really wish someone would make something that was pretty much exactly what CSS is, but make it a little more robust. Not with more types of styles, but with ways of positioning or sizing an element based on its parent element, better support for multiple classes, variables (for globally changing colors), and ways of adjusting colors relative to other colors. I'd love to be able to say "on hover, make the background 20% darker or 20% more red". I'd love to be able to change my color in one place instead of having to change the link color, the background color of my header and the underline of my h elements each time I want to tweak a color.

I'd also love if you could separate form validation from the page. doing validation with JS works, but it's not optimal. Having a validation language would be pretty awesome. Especially if you could implement it server-side. If the client could grab the validation code and validate the form before sending and handle errors (by displaying errors and highlighting fields) and then the server could also run that same code and handle errors (security... it would be easy to modify or disable anything on the clientside...) that would be great. All you'd really need is just a handful of cookiecutter directives (validate the length, format/regex, and also have some built-in types like phonenumbers and emails), that would be great, too.

I also think that it's about time for JS to get an upgrade. Merge Prototype.js into javascript. Add better support for AJAX and make it easier to create rich, interactive sites.

If we're not careful, Flash is going to become more and more prominent in casual websites. The only advantage the the current standards have is that they're free and don't require a commercial solution to produce.

XSS is a sideeffect of trusting the client too much and a side-effect that won't be solved by anything you've suggested.

And why does something need to be "compiled" to be faster? What needs to be faster? Rendering? Javascript? Or are you talking about server-side? Why don't we start writing all our websites in C? Let's just regress back to treating our desktop machines as thinclients. We'll access websites like applications over X11. It'll be great. ;)

Re:reboot the web! (1)

Blakey Rat (99501) | more than 6 years ago | (#21719486)

I'm not THAT upset with it. Javascript + DOM is a good tool, but I feel the real problem is that the designers of these technology don't listen to previous solutions to the problems encountered on the web.

Why did it take until CSS 3.0 to get easy-to-use columns? The New York Times has been using columns for 150+ years; why did the CSS implementers feel they should just dump all that publishing experience in the toilet and do things their own way?

Likewise, CSS which is supposed to free us from table-based layouts is really terrible at reproducing some effects which are trivial with tables. For example, centering content vertically on the page. (It can be done with CSS, but it's a hack.) If you're going to sell CSS as a replacement to table-based layouts, you need to first make sure that CSS is capable of doing all the things table-based layouts can do easily. (Columns, another great example; awkward in CSS, almost trivial with tables.)

Javascript + DOM has "getElementById", "getElementsByTagName", "getElementsByName"... but for some headache-inducing reason it doesn't have "getElementsByClassName". Why not? WHY NOT!? GAH!

Why doesn't the spec define one of the fundamental differences between Mozilla and IE in the DOM: should non-displaying text in the original HTML document appear as text nodes in the DOM? IE says no; Mozilla says yes; web developers say make up your damned mind, I keep having to write workarounds for this crap! (Personally I like IE's implementation better. If it doesn't display on screen, it doesn't need to be in the DOM.)

In short, I think there's far too much theory and not enough practice in these technologies. What we need is *practical* development. Which is why I'm all behind HTML 5, BTW, it focuses on the practical realities of the web and not some pie-in-the-sky idea you'll never get anybody to follow. Do you seriously think a webpage like, say, this: http://www2.jcpenney.com/jcp/ProductList.aspx?deptid=25439&pcatid=25864&catid=27010&cattyp=DEP&dep=Housewares&pcat=COOKWARE&cat=Stainless+Steel&refpagename=WindowSolutionHOM%252Easpx&refdeptid=25439&refcatid=25864&cmAMS_T=H9&cmAMS_C=C5&CmCatId=25439 [jcpenney.com] |25864 will ever meet the XHTML ideals?

Different directions -- Need Both (5, Insightful)

alexhmit01 (104757) | more than 6 years ago | (#21718334)

Most of the web is non well-formed, so it's variations of HTML 4 with non-standard components. An HTML 5, that remains a non-XML language, presents a reasonable way forward for "web sites." Without the need to be well-formed, the tools to create are easier and can be sloppy, particularly for moderately admined sites. Creating a new HTML 5 might succeed in migrating those sites. If you avoid most breaks with HTML 4, beyond the worst offenders, Browsers could target an HTML 5, and webmasters would only need to change 5%-10% of the content to keep up. That would mean a less degrading "legacy" mode than the HTML 4 renderers we have now.

So while the HTML 4 renderers floating around wouldn't be trashed, they could be ignored, left as is, and focus on an HTML 5 one. Migrating to XHTML is non-trivial for people with out-dated tools and lack of knowledge. You can't ignore those sites as a browser maker, but HTML 5 might give a reasonable path to modernizing the "non-professional" WWW.

XHTML has some great features, by being well-formed XML, you can use XML libraries for parsing the pages. This makes it much easier to "scrape" data off pages and handle inter-system communication, which HTML is not equipped for.

It's interesting in that HTML and XHTML look almost identical (for good reasons, XHTML was a port of HTML to XML) but are technically very different, HTML being an SGML language, and XHTML an XML language. Both programs have their uses, HTML is "easier" for people to hack together because if you do it wrong, the HTML renderer makes a best guess. XHTML is easier to use professionally, because if there is a problem, you can catch it as being an invalid XML document. Professionals worry about cross-browser issues, amateurs worry about getting it out there.

XHTML "failed" to replace HTML because it satisfies the needs of professionals to have a standardized approach to minimize cross-browser issues, but lacks the simplicity needed for amateurs and lousy professionals.

Rev'ing both specs would be a forward move that might simplify browser writing in the long term while giving a migration path. XHTML needs a less confusing and forward looking path, and HTML needs to be Rev'd after being left for dead to drop the really problematic entries and give people a path forward.

Re:Different directions -- Need Both (1)

Bogtha (906264) | more than 6 years ago | (#21718494)

HTML 5, that remains a non-XML language

HTML 5 has two serialisations, a quasi-HTML serialisation and an XML serialisation.

XHTML "failed" to replace HTML because it satisfies the needs of professionals to have a standardized approach to minimize cross-browser issues, but lacks the simplicity needed for amateurs and lousy professionals.

XHTML failed to replace HTML because a browser with a dominating market share doesn't support it and using it in a backwards-compatible way confers very few advantages over HTML and none whatsoever for typical developers.

Re:Different directions -- Need Both (1)

bcrowell (177657) | more than 6 years ago | (#21718602)

XHTML failed to replace HTML because a browser with a dominating market share doesn't support it [...]
Right.

[...] and using it in a backwards-compatible way confers very few advantages over HTML and none whatsoever for typical developers.
Wrong -- or at least it depends on what you mean by "typical." Technologies like SVG and MathML are XML-based, so there is a big advantage to having xhtml support in browsers: it lets you use inline SVG and MathML according to the w3c standards. Because MS doesn't support xhtml, SVG and MathML have basically been killed as practical browser technologies. Instead of SVG, we get Flash, which is proprietary (full of patent-encumbered and license-encumbered parts, controlled only by Adobe). Instead of MathML, we get horrible-looking bitmap renderings of mathematics on web pages.

Re:Different directions -- Need Both (1)

Bogtha (906264) | more than 6 years ago | (#21718682)

Technologies like SVG and MathML are XML-based, so there is a big advantage to having xhtml support in browsers

Yes, but the advantage is only there if you give up on Internet Explorer compatibility or put in a lot of extra work by coding an additional Internet Explorer version without SVG and MathML, i.e. the version you are supposedly skipping by using XHTML.

Because MS doesn't support xhtml, SVG and MathML have basically been killed as practical browser technologies.

Yes, so you can't really count them as advantages XHTML brings, can you?

I'm going to make my own browser standard... (1)

tjstork (137384) | more than 6 years ago | (#21718362)

Seriously, at this point, having a single standard for web pages is going to be passe. All it will take is a good open source implementation for the browser, critical mass, and eventually, the big players will follow.

No, the direction is not uncertain (0)

Anonymous Coward | more than 6 years ago | (#21718384)

If different browsers decide to adopt different standards, people (ie. web designers and developers) will fall back on whatever currently works for all browsers (ie. whatever we're using right now).

Direction not uncertain (0)

Anonymous Coward | more than 6 years ago | (#21718398)

Browser vendors have publicly stated they will not implement XHTML 2. That 'standard' is stillborn. (X)HTML 5 is the way forward.

Article sucks (1)

nonpareility (822891) | more than 6 years ago | (#21718440)

XHTML V2 and related modules are officially supported by the W3C, and the related modules are becoming key ingredients for other XML specifications that the W3C maintains. Unfortunately, official W3C approval is no guarantee of support by major Web browsers.

It wouldn't be the first time browser vendors were ahead of official recommendations.
Official W3C approval is pretty much dependent on support by major Web browsers. The W3C process says there should be two interoperable implementations of each feature [w3.org] before a proposed standard becomes a recommendation.

The FAQ doesn't even try to give a serious answer about the expected date of approval
Really? [whatwg.org]

Current browsers support both HTML V4 and XHTML V1.
Internet Explorer doesn't support XHTML V1. [msdn.com]

Similarly, future browsers might support both HTML V5 and XHTML V2.
Don't count on it. XHTML2 is pretty much dead.

beta vs vhs.... (1)

josepha48 (13953) | more than 6 years ago | (#21718556)

... all over again. It seems to me that at some point one will become more popular than the other. The question is which one. Then the other will go away. So far though I do not see anything being really improved upon. IMHO there should be certain built-ins to the browser to make it worth it.

Here is what I would suggest: 1 multi-column drop down, with sort capabilities. This is something that is available in desktop applications; 2) built-in browser menu; 3) better scripting modal window, I should have OK(alert), OK/Cancel(confirm), Yes/No, and Yes/No/cancel message boxes at least or a better way of specifying these.

Maybe some of this is improvements in JS/ECMA Script, but making more things 'built-in' to the browser, would make a more standard experience, assuming you could get everyone to upgrade to the browsers and people to develop to these standards.

After reading this article, it would be nice to have both these standards merged into one so I get xforms with HTML5 menu and toolbars.

What a mess... (1)

Enleth (947766) | more than 6 years ago | (#21718684)

If you're more interested in XHTML V1.1 than HTML V4, looking for an elegant approach to create documents accessible from multiple devices, you are likely to appreciate the advantages of XHTML V2. If you only use XHTML V1 because of its XML compliance but you prefer the new features in HTML V5, you might appreciate XHTML V5 (HTML V5 rewritten as an XML dialect).


And what if I'm interested in creating elegant, accessible documents incorporating the new features? I guess I'm screwed by the idiots at W3C, then?
That's not a matter of allowing those poor, repressed amateur web designers to express themselves. It's their problem that they cannot comprehend something as easy as XML and it's a pity that Web authoring tools don't work like a good, old hammer - if you don't know how to use it, you hit your fingers and know better next time to be careful because it hurts. 1997 is over, tag soup is becoming a horror of the past - what's up with those people trying to keep it?

No standard without reference implementation (4, Insightful)

ikekrull (59661) | more than 6 years ago | (#21718828)

The worst thing about W3C standards is the lack of a reference implementation. If you can't produce a computer program that implements 100% of the specification you are writing in a reasonable timeframe, your standard is too complex.

Is doesnt matter if the reference standard is slow-as-molasses or requires vast quantities of memory, at least you have proven the standard is actually realistically implementable. On the other hand if your reference implementation was easy to build and is really good, then that will foster code re-use and massively jump-start the availability of standardised implementations from multiple vendors. It might also show that you have a really good standard there.

If you don't do this, you get stuff like SVG - I don't think there is even one single 100% compliant SVG implementation anywhere, and there may never be.

There aren't any fully compliant CSS, or HTML implementations either, to my knowledge.

The same goes for XHTML and HTML5. If you, as a standards organisation, are not in a position to directly provide, or sponsor the development of an open reference implementation, then personally, I think you should be restricting your standard to a smaller chunk of functionality that you are actually able to do this with.

There is no reason a composite standard, with a bunch of smaller, well defined components, each with reference implementations, can't be used to specify 'umbrella' standards.

Now, i am also aware that building a reference application tends to make the standard as written overly influenced by shortcomings in the reference implementation, but i really can't believe this would be worse that the debacle surrounding WWW standards we've had for the last 10+ years. Without a conformant reference implementation, HTML support in browsers is dictated by the way Internet Explorer and Netscape did things anyway.

I'm also aware that smaller standards tends to promote a rather piecemeal evolution of those standards, when what is often desired is an 'across the board' update of technology.

But this 'lets define monster standards that will not be fully implemented for years, if at all, and hope for the best' approach seems to be obviously bad, allowing larger vendors to first play a large role in authoring a 'standard' that is practically impossible to fully implement, and then to push their own hopelessly deficient versions of these 'standards' on the world and sit back and laugh because there is no way to 'do better' by producing a 100% compliant version.

Re:No standard without reference implementation (1)

Bryan Ischo (893) | more than 6 years ago | (#21719126)

I agree with you completely. I think that *every* standard should come with a reference implementation. I can't even comprehend why standards bodies don't do this. It is the single most effective way to ensure that your standard is adopted. And it proves, as you said, that the standard is reasonably implementable - the code will demonstrate how easily implemented the standard is, and certainly the standard body would modify the standard where its egregiously difficult to implement instead of sinking lots of time into writing a difficult implementation, which is better for everyone as well - by providing a reference implementation, the standard body would be forced to "eat their own dog food", which would definitely encourage polishing up the rough parts before finalizing the standard. Once again, good for everybody.

Why Bother (0)

Anonymous Coward | more than 6 years ago | (#21718852)

Why bother with any kind of standard? IE will just display it fscked up anyway...

Support for multiple devices... (4, Interesting)

pikine (771084) | more than 6 years ago | (#21718968)

From the conclusion of TFA:

If you're more interested in XHTML V1.1 than HTML V4, looking for an elegant approach to create documents accessible from multiple devices, you are likely to appreciate the advantages of XHTML V2.

The author apparently has no experience with rendering XHTML on mobile devices. First of all, since the screen is smaller, it's not just about restyling things in a minimalist theme. It's about prioritizing information and remove the unnecessary one so more important information becomes more accessible in limited display real-estate.

For example, anyone who accessed Slashdot homepage on their mobile phone knows the pain of having the scroll down past the left and right columns before reaching the stories. You can simulate this experience by turning off page style and narrowing your browser window to 480 pixels wide. The story summaries are less accessible because they're further down a very long narrow page.

Another problem is the memory. Even if you style the unnecessary page elements to "no display", they're still downloaded and parsed by the mobile browser as part of the page. Mobile devices have limited memory, and I get "out of memory" error on some sites. For reading long articles on mobile devices, it is better to break content into more pages than you would on a desktop display, both for presentation and memory footprint reasons.

For these two reasons, a site designer generally has to design a new layout for each type of device. The dream of "one page (and several style sheets) to rule them all" is a fairytale.

yuo F0ail It (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#21719030)

completely before to foster a gay and posts. Therefore exemplified by CRISCO OR LUBE. to survive at aal fear the reaper

The current situation is awful. (4, Insightful)

Animats (122034) | more than 6 years ago | (#21719042)

The current situation is awful.

  • Major tools, like Dreamweaver, generate broken HTML/XHTML.. Try creating a page in Dreamweaver in XHTML or Strict HTML 4.1. It won't validate in Dreamweaver's own validator, let alone the W3C validator. The number of valid web pages out there is quite low. I'm not talking about subtle errors. There are major sites on the web which lack even proper HTML/HEAD/BODY tags.
  • The "div/float/clear" approach to layout was a terrible mistake. It's less powerful than tables, because it isn't a true 2D layout system. Absolute positioning made things even worse. And it got to be a religious issue. This dumb but heavily promoted article [hotdesign.com] was largely responsible for the problem.
  • CSS layout is incompatible with WYSIWYG tools The fundamental problem with CSS is that it's all about defining named things and then using them. That's a programmer's concept. It's antithetical to graphic design. Click and drag layout and CSS do not play well together. Attempts to bash the two together usually result in many CSS definitions with arbitrary names. Tables mapped well to WYSIWYG tools. CSS didn't. (Does anybody use Amaya? That was the W3C's attempt at a WYSIWYG editor for XHTML 1.0.)
  • The Linux/open source community gave up on web design tools. There used to be Netscape Composer and Nvu, but they're dead.

Re:The current situation is awful. (1)

The Master Control P (655590) | more than 6 years ago | (#21719432)

The sad thing about broken web code is that it's browsers that enable it.

If people know they can be lazy and write crap code that the browser will somehow manage to render anyway, they will since it's easier than writing correct code.

Re:The current situation is awful. (5, Insightful)

shutdown -p now (807394) | more than 6 years ago | (#21719484)

Drag'n'drop is simply not a working approach to design proper UI (i.e. the one that automatically scales and reflows to any DPI / window size / whatever).

As for "defining named things" - the concept of HTML is all about semantic markup. That's why using tables for layout is frowned upon, not because they are bad as such.

Re:The current situation is awful. (3, Insightful)

ceoyoyo (59147) | more than 6 years ago | (#21719498)

HTML isn't supposed to be WYSIWYG. If you want traditional graphic design, make a PDF.

HTML is supposed to be a document format that can be flexibly rendered. Pretty much the opposite of WYSIWYG actually.

Err What? (0)

Anonymous Coward | more than 6 years ago | (#21719344)

There is no contest, the browser vendors have made it very repeatedly clear on the WHATWG and HTML5 mailing lists that they do not intend to further support XHTML. They are going down the HTML5 dead-end, and s0d the rest of us.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...