Slashdot Mirror

It is theoretically possible to ban the validator based on its user-agent string, which looks like this:

W3C_Validator/1.305.2.137 libwww-perl/5.79

However, when I tried slashdot, it seemed to feed through allright...

So it is you who apparently does not understand how the validator works.

erm ... this says the html is not valid 4.01. Also, the w3c css validator complains rather heavily on it. So much for standard support ^_^

I'm not going to try and reply in detail, but since I participate in the W3C XML Query Working Group and am also the w3C XML Activity Lead, a few comments may be useful.

The article seems to says "I don't like SQL and I don't like XML and I think XML Query is about mergin them although I don't understand it very well, so the people working on XML Query must be stupid, and in any case it's easier to attack people than understand a specification".

Perhaps that's unfair, but it's clear to me that the writer is a little fuzzy on the design goals of XML and also on the focus of SQL development over the past 10 or 15 years.

In both cases the story is about interoperability.

If you look at the XML Query Home Page you'll see approximately two dozen implementations of the XML Query draft, including a number of open source ones. If you look at the public mailing list for comments, you'll see we received over 1100 detailed technical comments at the last public review. So there's a lot of interest in this work.

Why is that? One reason is that, like Web services and SOAP, XML Query is able to replace a lot of proprietary and hard-to-maitain middleware. Another reason is that for the first time we'll have a standard way to search over multiple kinds of data source.

Don is the primary editor of the XQuery language, but the technical decisions reflected in the specification are a result of collaboration, and are agreed on by aconsensus process by a much larger number of particpants. The goal is to make a language that people agree to implement and to use. With support announced by Microsoft, Oracle, IBM, BEA and others (see Web page mentioned above) and judging by the public interest, I think it's fair to say that's going to happen.

It's pretty rare to see a large complex system that everyone is happy with. It's actually pretty rare to see a small system that everyone is happy with. There are people who are unhappy with some features in the Unix cat program, but it's better to have cat in every Unix system than to have millions of shell scripts break on systems where it's missing! The trick, then, is often to include features that will lead to massively wider adoption, even if some people would rather be without them.

Then we have (as part of W3C Process) a public call for implementations so that we can test to see how confident we are that all the major features can be implemented compatibly (i.e. interoperably) in multiple independent implementations.

Features that were not implemented get removed before the specifications are final.

Is XML Query a waste of time? Is XML evil? Is SQL evil? A lot of people think otherwise, and some of them are pretty smart, so if you are concerned, take the time to read the specs and decide for yourself. :-)

I'm not going to try and reply in detail, but since I participate in the W3C XML Query Working Group and am also the w3C XML Activity Lead, a few comments may be useful.

The article seems to says "I don't like SQL and I don't like XML and I think XML Query is about mergin them although I don't understand it very well, so the people working on XML Query must be stupid, and in any case it's easier to attack people than understand a specification".

Perhaps that's unfair, but it's clear to me that the writer is a little fuzzy on the design goals of XML and also on the focus of SQL development over the past 10 or 15 years.

In both cases the story is about interoperability.

If you look at the XML Query Home Page you'll see approximately two dozen implementations of the XML Query draft, including a number of open source ones. If you look at the public mailing list for comments, you'll see we received over 1100 detailed technical comments at the last public review. So there's a lot of interest in this work.

Why is that? One reason is that, like Web services and SOAP, XML Query is able to replace a lot of proprietary and hard-to-maitain middleware. Another reason is that for the first time we'll have a standard way to search over multiple kinds of data source.

Don is the primary editor of the XQuery language, but the technical decisions reflected in the specification are a result of collaboration, and are agreed on by aconsensus process by a much larger number of particpants. The goal is to make a language that people agree to implement and to use. With support announced by Microsoft, Oracle, IBM, BEA and others (see Web page mentioned above) and judging by the public interest, I think it's fair to say that's going to happen.

It's pretty rare to see a large complex system that everyone is happy with. It's actually pretty rare to see a small system that everyone is happy with. There are people who are unhappy with some features in the Unix cat program, but it's better to have cat in every Unix system than to have millions of shell scripts break on systems where it's missing! The trick, then, is often to include features that will lead to massively wider adoption, even if some people would rather be without them.

Then we have (as part of W3C Process) a public call for implementations so that we can test to see how confident we are that all the major features can be implemented compatibly (i.e. interoperably) in multiple independent implementations.

Features that were not implemented get removed before the specifications are final.

Is XML Query a waste of time? Is XML evil? Is SQL evil? A lot of people think otherwise, and some of them are pretty smart, so if you are concerned, take the time to read the specs and decide for yourself. :-)

The biggest obstacle to using credit cards for micropayments is the cost of transaction processing

I wonder if the folks at Microsoft are considering Passport as a micropayment vehicle for subscription-based websites? Micropayments lower the threshold and do not require a big decision before users get their initial benefits: thus users will be encouraged to view more pages and spend more. Of course, there will almost certainly be discount schemes for frequent users of a site such that nobody would end up paying more than they would under a subscription plan.

Also, although a closed initative, the W3C Micropayments Working Group provides some interesting info.

RDF
Kowari

I've done several years of application programming using SQL

I've also implemented the (XQuery-derived) query processing module for a native XML database

In my former life as a application programmer, I really liked SQL. It allowed some pretty complicated computation to be done in the query, and very concisely in many cases compared to doing the same thing in, say, C++. For example, things like grouping are very nice for many application purposes.

In my current job, I'm hoping to create an XML query language that supports the same sort of capabilities as SQL. Our XML query language implementation has decent path/predicate, sorting, and output structuring capabilities, mostly derived from earlier drafts of XQuery.

My feeling about XQuery 1.0 is that it is extremely bloated. XML seems really simple; querying it shouldn't be all that complicated, should it? But the XQuery committee has created several hundred pages of specifications for the new language. This seems excessive, to say the least. We basically have implemented a subset of an earlier version (with paths, predicates, sorting, XML construction, a few dozen functions), and stopped tracking what they were doing. This is kind of unfortunate, but we really don't have the resources to support his behemoth in all its awesome grandeur.

We just want a language that lets programmers efficiently access our database. I think we're on the right track. I'm not at all sure that XQuery is going to wind up as a long-term success, partly because of its bloat factor.

My favorite illustration of the XQuery bloat is this: early versions (up to about April 2002) of the XQuery language description contained this sentence in the introduction:
It is designed to be a small, easily implementable language in which queries are concise and easily understood.

Starting in August 2002, this was changed to:
It is designed to be a language in which queries are concise and easily understood.

The "small, easily implementable" part got smothered up by the avalanche of features they were adding.

I've done several years of application programming using SQL

I've also implemented the (XQuery-derived) query processing module for a native XML database

In my former life as a application programmer, I really liked SQL. It allowed some pretty complicated computation to be done in the query, and very concisely in many cases compared to doing the same thing in, say, C++. For example, things like grouping are very nice for many application purposes.

In my current job, I'm hoping to create an XML query language that supports the same sort of capabilities as SQL. Our XML query language implementation has decent path/predicate, sorting, and output structuring capabilities, mostly derived from earlier drafts of XQuery.

My feeling about XQuery 1.0 is that it is extremely bloated. XML seems really simple; querying it shouldn't be all that complicated, should it? But the XQuery committee has created several hundred pages of specifications for the new language. This seems excessive, to say the least. We basically have implemented a subset of an earlier version (with paths, predicates, sorting, XML construction, a few dozen functions), and stopped tracking what they were doing. This is kind of unfortunate, but we really don't have the resources to support his behemoth in all its awesome grandeur.

We just want a language that lets programmers efficiently access our database. I think we're on the right track. I'm not at all sure that XQuery is going to wind up as a long-term success, partly because of its bloat factor.

My favorite illustration of the XQuery bloat is this: early versions (up to about April 2002) of the XQuery language description contained this sentence in the introduction:
It is designed to be a small, easily implementable language in which queries are concise and easily understood.

Starting in August 2002, this was changed to:
It is designed to be a language in which queries are concise and easily understood.

The "small, easily implementable" part got smothered up by the avalanche of features they were adding.

At least some XML people recognize the same, thus the existence of RDF.
RDF is equivilent to a relational database. There is a working group right now looking into a query language for RDF.

That said, some RDF people here at the w3c don't care that much for serializing RDF as XML, prefering the much more readable n3

At least some XML people recognize the same, thus the existence of RDF.
RDF is equivilent to a relational database. There is a working group right now looking into a query language for RDF.

That said, some RDF people here at the w3c don't care that much for serializing RDF as XML, prefering the much more readable n3

I have never seen this and I use Firebird all the time and hit /. several times a day. I also would not call that "choking", the site still works and it is mostly due to bad HTML from /. Trying to validate slashdot.org against the W3C Validation service shows some errors on the part of /.

I have never seen this and I use Firebird all the time and hit /. several times a day. I also would not call that "choking", the site still works and it is mostly due to bad HTML from /. Trying to validate slashdot.org against the W3C Validation service shows some errors on the part of /.

One of the interesting features about HyperText Markup Language (some would say the defining feature) is that it supports hypertext. Did you know, for example, that with the addition of an <a /> tag you can provide a link that people can just click on, rather than having to copy a URL to the address bar.

A better solution is to make companies display a simplified licensing agreement (EULA), which non-lawyers can easily read and understand. Saying that all users should spend 10 minutes trying to reverse engineer the EULA is crazy! I want a EULA that my dead Grandma (RIP) can understand.

Perhaps we should require EULAs to conform to the same privacy policy summary guidelines as the W3C's Platform for Privacy Preferences (P3P). This would give users a fighting chance to understand what the software is doing under the surface. Granted, the P3P stuff could use some enhancements.

It's like those ads that drug companies run in magazines -- with a full page of fine print. Or like reading US tax forms. We need a Plain English (or language of your choice) summary of what the software claims to do.

I think some private companies tried to make a business out of summarizing overly-long EULAs -- but they probably went out of business (eg: Enonymous). Maybe a W3C P3P-type solution is the answer.

1. Dev Todo is a wonderful outliner and task manager. Today I ported it to win32 using mingw to use at work (it pisses me off that windows dropped ANSI color support in their crappy CMD! I knew it was bad, but I still use it more than msys or cygwin because it is quicker on my slow box). Dev Todo stores everything in beautiful XML. I intend to make a filter for XSLT for my biweekly progress reports. My boss wants me to list things I've gotten done & what I plan to do & this great app can store all of that.
2. Pine-I don't care if RMS doesn't consider it free. It is the best IMAP client. I do like Mulberry as well, though.
3. GNU Screen-I mostly just detach/reattach. I'd like to learn to use it more.
4. VIM-My editor. Again, need to learn it better.
5. Lynx on windows and ELinks on Linux for browsing.
6. I have aliased "fuck" to use cowsay to tell me to calm down. Great stress relief.
7. GPG
8. LaTeX. I hesitated to include this, but I use it on both linux and windows & it is technically interactive. I have started using it more than standard word processors (WordPerfect>OpenOffice>MS Word) and I want to use it instead of impress/powerpoint/whatever.
9. OpenSSH because my box is so much better than the one I use at work
10. NcFTP best ftp client I found, though I have been having much less need to use it.

OT: For all the "get a compliant browser" stuff at the bottom of that page, it doesn't validate. Just thought you ought to know.

1. Support for JPEG2000. This would allow better quality images with less bandwidth than the older JPEG standard.
2. Support for SVG (Scalable Vector Graphics). This would allow web applications to draw high quality graphics without consuming as many resources as Java applets.
3. Showing animated GIFs at the frame rate specified. IE6 still slows down GIF frames that should be shown for less than 1/20 of a second, limiting the quality of animation.

(google: web standards)
The irony being that google doesn't use standards-compliant markup. Check for yourself. I do believe in web standards, but MS isn't the only problem. The truth is their browser renders broken html better than some alternatives (though you can fix moz or opera to do this using e.g. user style sheets). Perhaps the pages wouldn't be broken if authors used something other than IE to double-check, I don't know.

Standards are good, but there's little reason to be a standards-zealot. Google proved that perfectly useable and fast pages can bend the rules. IE should add support for useful standards, such as transparent PNGs, but there are many standards I care much less about--I'm not inclined to use them on my pages & I don't use IE for my browsing.

The standards are described here. How much more fucking specific can you get?

The problem with Flash is that you either spend loads of time on making your innovative idea usable or you end up with some flashy abomination. If such applications were all made open source, some extremely useful things could be made and perfected very quickly. The HTML/WWW approach is extremely old and not really as good today as it was a decade ago. Innovation is slow - if only we used open standards and open source more... we could have already had something like Semantic Web.

An MP3 player with a good button layout might be good, but you need one that doesn't really rely too much on being able to read the screen. An iPod might not be very good because that jog wheel might not be much use. I think the Neuros might be good option.

You can download a lot of talking books from the filesharing networks like eDonkey, and AFAIK it would be legal as long as you also bought the hardcopy. The RNIB site has links to some more legitimate suppliers.

BBC Radio 4 lets you listen online to most of their programmes from the last week, and they have a lot of dramas and book readings (and some great comedy). Unfortunately it's currently in RealMedia format, but that is due to change.

Lastly, if any of your friends are web designers, encourage them to follow the WAI guidelines otherwise she might not be able to access their websites (not that she will neccessarily want to, but it's always good to get more people interested in accessibility).

PS. Tell her 'Hi' from Slashdot!

You won't see more of this type of thing in browsers...at least I hope not...that would mean that web designers are going to have to wrestle even more control back from know-it-all browsers like I.E. Hell, it took me forever to figure out why IE insisted on putting scroll-bars on my pages and making the text go off the edge of the screen, but only in certain cases (there's some stupid "compatibility mode" it kicks into when it gets scared that things aren't going to render right).

I got around the problem (have to add an xml declaration before the doctype), but then again, the only reason I *noticed* the problem is because of something that nobody much talks about...compatibility testing.

Making sure that your page looks right in IE, Mozilla, Netscape, Opera, Safari, Konqueror, etc is the job of the web designer. CSS and the w3c provide so many tools to accomplish this that a designer who pleads ignorance or insists on making everything a huge table layout full of rectangular chunks of a sliced-up picture doesn't deserve that title.

If you whine to me that my images don't scale on your monitor, and it's important enough to me, I'll make sure that I write code that takes screen resolution into account. The reason that I'm even able to is that I take the time to find out what the standard is, and a way to do it it spelled out pretty clearly.

You won't see more of this type of thing in browsers...at least I hope not...that would mean that web designers are going to have to wrestle even more control back from know-it-all browsers like I.E. Hell, it took me forever to figure out why IE insisted on putting scroll-bars on my pages and making the text go off the edge of the screen, but only in certain cases (there's some stupid "compatibility mode" it kicks into when it gets scared that things aren't going to render right).

I got around the problem (have to add an xml declaration before the doctype), but then again, the only reason I *noticed* the problem is because of something that nobody much talks about...compatibility testing.

Making sure that your page looks right in IE, Mozilla, Netscape, Opera, Safari, Konqueror, etc is the job of the web designer. CSS and the w3c provide so many tools to accomplish this that a designer who pleads ignorance or insists on making everything a huge table layout full of rectangular chunks of a sliced-up picture doesn't deserve that title.

If you whine to me that my images don't scale on your monitor, and it's important enough to me, I'll make sure that I write code that takes screen resolution into account. The reason that I'm even able to is that I take the time to find out what the standard is, and a way to do it it spelled out pretty clearly.

Having standardized sizes matters to develop a universally usable site. It's not just a marketing ploy; in many cases, it's a legal requirement. Before you complain about how little it matters and demand that people be flexible, consider the following:

First, a site must be attractive. You may be a purist who still thinks that pretty pictures and good design isn't necessary if you present enough information, but you'd be wrong. Unfortunately, people still judge things by their looks. Even if you've presented your information in such a way as to make it extraordinarily easy to use and navigate, many people will never know that. Often, they'll see that your site looks like crap and figure your business is run the same way. Imagine yourself in the lobby of a company you're considering doing business with. Sure, the walls are sound and the furniture doesn't have holes in it. But if everything is cheap white plastic and particleboard, you're going to wonder if this company isn't just some fly-by-night operation. Thus, having an attractive site is important.

Second, the World Wide Web Consortium has very specific requirements for a page to be "usable". What happens if you don't do it there way? Well, you can be sued, for one thing. Also, your company will not be allowed to do business with the government, as you are most likely not in compliance with section 508, the same series of regulations that require wheelchair access, braille, and other accessibility assists for those with disabilities.

Third, you've got to make your site usable. Usability is not the same as accessibility. A 100% accessible site can be 99% unusable if it isn't clear what a user should do, how they should navigate, etc. Just because you've got braille on all of your stairways doesn't mean your users will know what floor to hit if you don't have a building directory somewhere, easy to find and easy to read. As such, it's important to make sure any idiot can navigate your site with ease. Do user testing. Record the sessions. Don't focus so much on what your users say, so much as what they do. I once had a user try to click on something that wasn't a link (but that could have been), then tell me he "should've known better"... but he didn't. (Naturally, it was a link an hour later.) ;-)

Once you've established that your site has to be cleanly and professionally designed, accessible and usable, you now have to make sure none of these elements breaks as you move from machine to machine, browser to browser, and platform to platform. You'll quickly notice that suddenly, you can't make your site scale as much as you want. You see that smoothly-flowing text on a 800x600 screen looks hopelessly cluttered on a 640x480 screen and ridiculously wide, yet short on a 1024x768 screen. You begin to develop visual guides that will work with lower monitor resolutions, yet still look professional on the larger screens. Your designers produce a style guide that begins to define specific column widths and template sizes. And you notice... that the web really isn't as scalable as you thought it was.

What the standard is matters because, if you want to be taken seriously or treated professionally, you had damn well make sure that your site is attractive, accessible, and usable. If not, you'll watch all of your competition march on by, taking your audience with it, regardless of whether you're out to make money or not. If your audience sees that someone else offers the same thing you do, but it's nicer and easier to use, they're going to go see that someone else, and that will be that. You had better take into account what resolutions your users have at their disposal, or your sites will cease to exist.

Whatever happened to my decentralized net with no single point of failure?

Oddly enough I've just read the part of Weaving the Web that points out how, for all the Internet's and web's decentralised methods, they still used DNS which is essentially a heirarchy pointing to very few computers, which can cause problems later, being the Internet's Achille's Heel. It mentions the biggest fear not being technical failure but human maliciousness.

No, it's part of Slashdot's shitty web design. It's so embarrassing that they've apparently taken to forbidding the w3c validator from checking it.

If Slashdot had a modern XHTML + CSS layout, everything would resize correctly as you increased and decreased the font size.

In fact, a bunch of web designers even created a standards-compliant version of the Slashdot UI, but the editors are either too lazy to implement it or don't care about how ugly the site looks.

I haven't actually seen the Yahoo page, but this is more likely to be CSS than DHTML.

I have built *tons* of web pages for both IE and Mozilla. They render exactly the same in Opera, IE, KHTML, and Mozilla, they conform to the XHTML 1.1 spec, they are lightweight, and they look pretty good.

do you server your pages as application/xhtml? something you should when conforming to the xhtml1.1 specs. last time i checked msie couldn't handle that pretty well.(granted the same goes for khtml) http://www.w3.org/TR/xhtml-media-types/

Make sure you are using valid CSS and HTML. I've heard so many stories about cross-browser programming and back with IE4 and NS4, sure there was a problem...but as soon as I started using valid code, everything has shown up the same in IE and Firefox (with the exception of some paddings/margins).

Make sure you are using valid CSS and HTML. I've heard so many stories about cross-browser programming and back with IE4 and NS4, sure there was a problem...but as soon as I started using valid code, everything has shown up the same in IE and Firefox (with the exception of some paddings/margins).

Hey, I also thought we don't need no stinking proprietary operating systems. What the hell is a GNU anything doing on a Microsoft OS? Isn't that, like, illegal or against the GPL or something? What's the next GNU story, "Stallman buys SOAP"?

They are quoting what people say about them, not asserting what they are (though also not saying anything to dispell the misconception.)

It is a standards body.

From the front page:

No mention of standards.

And while membership is not restricted to vendors per se, vendor corporations are the major players.

IMO, a news aggregator which can't already provide the ability to extend its reach via XSL is a poor tool. A sane developer would take the path of least surprise, implementing multiple formats by transforming them all to a single format, so they don't have to fuck around with the multiple formats in the real code.

But if you're stuck with someone else's system which can't parse RSS 2.0, you can obviously cheat by using something like the W3C's online XSL transformer to convert the 2.0 feeds to a format which you can already understand.

You can probably find XSL files for converting between different RSS formats already.

Oh, yeah, lots of support for XHTML there.

hey Google, how about creating a website that is standards compliant, before worrying about RSS feeds and minor sundries, good to see the W3C reccomendations and all that hard work in creating standards in the web browser are not going to waste.

why bother ? its not like it matters right ?

This is probably a good choice. I mean, the W3C uses RSS to syndicate their page (see the bottom).
As the state, RSS is based on RDF, which is an approved standard.

Based on the coverage at ZDNet, it seems that Yahoo! also goes RSS...

Why would the two merge when so many major players are leaning towards RSS already?

This is probably a good choice. I mean, the W3C uses RSS to syndicate their page (see the bottom).
As the state, RSS is based on RDF, which is an approved standard.

Based on the coverage at ZDNet, it seems that Yahoo! also goes RSS...

Why would the two merge when so many major players are leaning towards RSS already?

I'm not positive, but I think that's required by the HTTP spec. If the page has expired from cache, then the browser is supposed to re-fetch from the server. However, if the request was a POST rather than a GET, the browser isn't supposed to re-submit because POSTs are permitted to change the state of a server. So, Mozilla reacts by confirming that you want to re-submit the form.

Corrections welcome.

the only way I can think of to do a image roll over with css would be using the background property, and I dont think that can be applied to a non-block tag.

The background property applies to all elements.

Even if it didn't, there's no restriction in CSS about whether properties can be applied to block or inline "tags" (you mean "element types", not "tags") - you are almost certainly thinking of whether the element is block or inline display - and you can change an element's display type with the CSS display property. So if you want block display links, you could use:

:link, :visited { display: block; }

I am no w3c expert by any means, but that's an interesting statement and strong point.

Too right it is. I don't recognise that characterisation of the W3C at all. True, they are concerned with the web as a whole, not just browsers, but it difficult to explain announcements like annotea moves to mozilla if the W3C is hostile to browsers.

Browser companies take part in W3C working groups, and provide valuable input. W3C even develops its own browser. And, a minor point I confess, W3C presentations normally use HTML in a browser.

What I see this group doing is providing the basis for W3C work. Working groups tend to be less successful if there isn't preceding work to serve as a basis. The W3C are attempting to remedy this (incubation groups iirc) but in the meantime I think this is interesting project.

I am no w3c expert by any means, but that's an interesting statement and strong point.

Too right it is. I don't recognise that characterisation of the W3C at all. True, they are concerned with the web as a whole, not just browsers, but it difficult to explain announcements like annotea moves to mozilla if the W3C is hostile to browsers.

Browser companies take part in W3C working groups, and provide valuable input. W3C even develops its own browser. And, a minor point I confess, W3C presentations normally use HTML in a browser.

What I see this group doing is providing the basis for W3C work. Working groups tend to be less successful if there isn't preceding work to serve as a basis. The W3C are attempting to remedy this (incubation groups iirc) but in the meantime I think this is interesting project.

> WHAT WG was created not because a specific developer wanted to do it's own thing,
> but because the majority of W3C members aren't browser developers. They're plug-in developers.
> Some people within the W3C have even stated that the browser is dead. This kind of
> environment is openly hostile to the further development of existing browser-based standards.

At the recent Web Applications workshop I did openly say that the "browser is dead". I am not, however "within the W3C", although I am an 'invited expert' on a couple of Working Groups. (And I don't recall anyone else using this phrase.)

My position is simply that to build powerful applications that take advantage of internet technologies - but don't require us to constantly 'drop-down' into C++ or Java - requires a programming environment more powerful than current browsers support. Sure, browsers are great places to save a list of favourites, and most do a pretty good job of rendering HTML, but if we have to wait a few years every time a new mark-up language is bought out - and confusion reigns in the meantime whilst we all try to second guess which browser company will implement what - then there has to be something wrong with the architecture.

So, my view is that the days of the 'monolithic browser' are numbered; it takes too long to update, lacks basic features that any application really should have, and leaves the rest of us at the mercy of a few companies who are more or less radical and 'open', depending on the day of the week.

Of course, it's none of my business whether browser vendors want to create new standards for HTML, but the companies I deal with don't need any more HTML - they've got plenty thanks. What they do need though, is higher-level languages that do more, make application-building easier and quicker, and still deploy as easily as HTML. And for the record, I've been arguing since before XForms became a Full Rec that XForms is an ideal foundation for this.

My proposal at the workshop was for an application environment that allowed these new types of apps to be built, in an open standards/open source way, by defining a 'virtual machine'.

And if we still need somewhere to save our favourites, we can easily use such a VM to build a 'traditional' web browser, but genuinely based on standards.

> WHAT WG was created not because a specific developer wanted to do it's own thing,
> but because the majority of W3C members aren't browser developers. They're plug-in developers.
> Some people within the W3C have even stated that the browser is dead. This kind of
> environment is openly hostile to the further development of existing browser-based standards.

At the recent Web Applications workshop I did openly say that the "browser is dead". I am not, however "within the W3C", although I am an 'invited expert' on a couple of Working Groups. (And I don't recall anyone else using this phrase.)

My position is simply that to build powerful applications that take advantage of internet technologies - but don't require us to constantly 'drop-down' into C++ or Java - requires a programming environment more powerful than current browsers support. Sure, browsers are great places to save a list of favourites, and most do a pretty good job of rendering HTML, but if we have to wait a few years every time a new mark-up language is bought out - and confusion reigns in the meantime whilst we all try to second guess which browser company will implement what - then there has to be something wrong with the architecture.

So, my view is that the days of the 'monolithic browser' are numbered; it takes too long to update, lacks basic features that any application really should have, and leaves the rest of us at the mercy of a few companies who are more or less radical and 'open', depending on the day of the week.

Of course, it's none of my business whether browser vendors want to create new standards for HTML, but the companies I deal with don't need any more HTML - they've got plenty thanks. What they do need though, is higher-level languages that do more, make application-building easier and quicker, and still deploy as easily as HTML. And for the record, I've been arguing since before XForms became a Full Rec that XForms is an ideal foundation for this.

My proposal at the workshop was for an application environment that allowed these new types of apps to be built, in an open standards/open source way, by defining a 'virtual machine'.

And if we still need somewhere to save our favourites, we can easily use such a VM to build a 'traditional' web browser, but genuinely based on standards.

> WHAT WG was created not because a specific developer wanted to do it's own thing,
> but because the majority of W3C members aren't browser developers. They're plug-in developers.
> Some people within the W3C have even stated that the browser is dead. This kind of
> environment is openly hostile to the further development of existing browser-based standards.

At the recent Web Applications workshop I did openly say that the "browser is dead". I am not, however "within the W3C", although I am an 'invited expert' on a couple of Working Groups. (And I don't recall anyone else using this phrase.)

My position is simply that to build powerful applications that take advantage of internet technologies - but don't require us to constantly 'drop-down' into C++ or Java - requires a programming environment more powerful than current browsers support. Sure, browsers are great places to save a list of favourites, and most do a pretty good job of rendering HTML, but if we have to wait a few years every time a new mark-up language is bought out - and confusion reigns in the meantime whilst we all try to second guess which browser company will implement what - then there has to be something wrong with the architecture.

So, my view is that the days of the 'monolithic browser' are numbered; it takes too long to update, lacks basic features that any application really should have, and leaves the rest of us at the mercy of a few companies who are more or less radical and 'open', depending on the day of the week.

Of course, it's none of my business whether browser vendors want to create new standards for HTML, but the companies I deal with don't need any more HTML - they've got plenty thanks. What they do need though, is higher-level languages that do more, make application-building easier and quicker, and still deploy as easily as HTML. And for the record, I've been arguing since before XForms became a Full Rec that XForms is an ideal foundation for this.

My proposal at the workshop was for an application environment that allowed these new types of apps to be built, in an open standards/open source way, by defining a 'virtual machine'.

And if we still need somewhere to save our favourites, we can easily use such a VM to build a 'traditional' web browser, but genuinely based on standards.

If this stuff was implemented in SVG it would be cool, but unfortunatly SVG has become too unweildy... The latest draft of the spec has support for SOCKETS?!??! WTF???!?!?! you don't need that! SVG should remain a presentational language. Stick to graphics and leave the rest to other protocols/components. There's a good post on this here (I think she's an Opera developer but I'm not sure)

Currently the SVG spec is 719 pages long... TWICE THAT OF CSS 2.1... and alot of browsers don't even have support for that yet. Not to mention that SVG doesn't even have decent support for more than one line of text even.

all I can say is K.I.S.S

Cam

A proxy based approach

> Now Opera has been known for ages for being pretty anti-XForms, mostly because integration
> of standards such as XForms/SVG would bloat the browser footprint to such an extent that a
> lot of mobile device manufacturers might start looking for a different browser ...

That's a good point, although it's interesting that at the recent Web Applications workshop the guys from Opera conceded that the only 'extra' piece you needed to add to a standards-based web browser, in order to implement XForms Basic, was XPath. And that can hardly be described as 'bloat'!

Certain parts of SVG - ie. all the cool vector graphics bits - will probably go into Mozilla once it's ready and if it doesn't impact the rest of Mozilla too much speedwise and footprintwise

Other parts of SVG will (probably/hopefully) never get into Mozilla. Like raw socket support: http://www.w3.org/TR/SVG12/#rawsocket

Ian Hickson mentions other crappy things about SVG in his blog (which I'll be nice and not link to from /. - learn to google)

The W3C has been working on this - the "creation of a new language designed specifically for Internet computing" - since their original darpa grant in in 1995. Tim-Berners Lee's web site says he still acts as an advisor to the company that's continuing that project.

This is being done outside of the W3C, with the hope of getting a viable alternative to Longhorn's XAML available soon

Okay, Microsoft are trying to develop some standards. If history says anything about how the web has evolved its that the users define the standard. If it works, we use it. XML works. Macromedias Flash app is a defacto standard, created outside the W3C. If it works, we use it. Suns Java is pretty popular too. A lot of stuff is created outside the W3C, it all works, if its good we install it. simple really.