Our developers said they couldn't develop a version of XPath lean enough.
In fact, of the specs I listed, we've had to _drop_ support for some (XHTML and XML, namespaces and XML Events were dropped in the last mobile device release I was involved with; and parts of DOM2 and parts of CSS2 are frequently considered as optional for mobile releases).
Yeah, one thing that came out of the Web Applications workshop last week is that the term "Web Application" means different things to different people.
As I said in another post, I agree that on the long term we need a set of APIs on par with an OS, but designed so that they work cross-platform. That's what Microsoft are doing with Longhorn, except that that is Windows-only. The Gnome people will probably come up with stuff of their own, which would be more cross-platform. Indeed Sun did this years ago with Java.
The problem is that writing a spec for this stuff is insanely hard. To do this for a sophisticated application platform on par with, say, Longhorn, is simply unfeasible, IMHO. Notice how WINE has to reverse engineer Windows to determine how it should work -- the Win32 APIs aren't good enough to know exactly how to do it. Or how the various Java clones have to reverse engineer Sun's Java to get interoperability, the Java API documentation isn't good enough either. Heck DHTML is already complicated enough that we have to reverse engineer IE to work out how it should work, and that is orders of magnitude easier than an OS-level API set would be.
Then again, the W3C are likely to be working on such an API as a result of this workshop, and I'm sure Mozilla and Opera will be taking part in that work if it happens. That doesn't stop there being a need, in the meantime, for a solution for those people writing applications this year, in HTML.
(Slashdot itself is an example of such an application. Would you rather use a standalone Slashdot application instead of using a Web browser to read and post on Slashdot?)
But as it says in http://whatwg.org/: The term "Web Application" in this context refers to applications accessed over the World Wide Web by using a Web browser. This group is not attempting to describe APIs for writing high-end sophisticated programs such as office productivity suites, graphics manipulation packages, or 3D games.
(The first two should be green if it supports XHTML. The last one should be green if it doesn't try to sniff for it (which would be the only way to support it if the first two tests fail). In a compliant UA, all three would be green.)
Well, is Slashdot a Web site, or a Web application?
WHATWG is targetting Web applications like Slashdot, eBay, Amazon, Voidwars, etc. Not Web Applications like server-hosted versions of Word, Excel, Quake, etc. I'm sure we all agree that trying to do a real Excel clone in HTML is simply a non-starter.
Every time we've made the browser more invisible, we've been hit by security nightmares like phishing. I think it makes a lot of sense to clearly mark remote applications as remote and to show their URI and so forth.
We care if it's implementable in IE6 because authors don't seem to want to do anything if it doesn't work in IE6.
So instead of a "monolithic browser" you want a "monolithic runtime" that takes too long to update, lacks basic features, and leaves the rest of you at the mercy of a few companies who are more or less radical and "open", depending on the day of the week?
I really don't understand the difference between your VM idea and the browser of today, except that you would use XForms as the core instead of HTML. Different tags, same problems.
The more I read your VM proposal the less I understand it, unfortunately. I guess I need to see a more formal proposal to really understand what it means.
Yeah, I think it would be great to get Opera/Mozilla/Safari supporting SVG natively. Mozilla's already working on this, note (I heard they've got 20% of SVG1 done already).
I agree that on the long term we need a set of APIs on par with an OS, but designed so that they work cross-platform.
That's what Microsoft are doing with Longhorn, except that that is Windows-only. The Gnome people will probably come up with stuff of their own, which would be more cross-platform.
Sun did this years ago with Java. Why wasn't it successful?
The problem is that writing a spec for this stuff is insanely hard. To do this for a sophisticated application platform on par with, say, Longhorn, is simply unfeasible, IMHO. Notice how WINE has to reverse engineer Windows to determine how it should work -- the Win32 APIs aren't good enough to know exactly how to do it. Or how the various Java clones have to reverse engineer Sun's Java to get interoperability, the Java API documentation isn't good enough either. Heck DHTML is already complicated enough that we have to reverse engineer IE to work out how it should work, and that is orders of magnitude easier than an OS-level API set would be.
Then again, the W3C are likely to be working on such an API as a result of this workshop, and I'm sure Mozilla and Opera will be taking part in that work if it happens. That doesn't stop there being a need, in the meantime, for a solution for those people writing applications this year, in HTML.
(Slashdot itself is an example of such an application. Would you rather use a standalone Slashdot application instead of using a Web browser to read and post on Slashdot?)
Please do sit down and think about it. This is the kind of input we'd love to have.
What would be really helpful is having specific use cases in mind as well. For example, "Multiple document interfaces so that the user can be editing several meeting agendas at the same time with an Intranet calendar application".
Send your ideas to whatwg@whatwg.org (the WHATWG list).
Mozilla's implementation is over 150k. And that doesn't even do the XForms extensions to XPath. Not bloat? We're talking about devices where the entire product has to fit in less than 1000k here, and that has to include HTML4, XHTML, XML, namespaces, DOM0, DOM1, DOM2, CSS1, CSS2, XML Events, JavaScript, etc.
Mozilla, Safari, and Opera all support XHTML. Mozilla has supported since before it even had a namespace assigned. I don't see many people using it. There are a few blogs that use application/xhtml+xml but that's about it.
What matters to authors seems to be "does it work in IE6". Therefore that's what WHATWG is concerned about. The proposed extensions will all be implementable in IE6 using non-binary HTCs or a little JavaScript.
(In other words, it's not backwards compatible that is important, it's compatibility with the market leader. In this case, though, it's the same thing.)
The WHATWG mailing list is an open-subscription mailing list. Anyone can contribute. (Compared to W3C's $5000 membership fee, you could in fact say that it's rather more open.)
Microsoft have already ditched W3C. They have said they aren't implementing XHTML or SVG or CSS2.1 or CSS3 or DOM3 or XForms or MathML in the forseeable future. (As opposed to Mozilla, Opera, and Safari, who have all been actively adding support for many of these technologies over the last few years.)
Actually Microsoft was one of the few groups in favour of work like this at the recent workshop (they didn't want scripting involved, but apart from that were in favour with extending HTML rather than going down the XForms or other new language route).
No, it doesn't mean SVG won't be supported. SVG 1.0 is just the thing for vector graphics, and it fits right into the HTML world if you use XBL, for instance. (Although admittedly that won't be backwards compatible and won't work in IE!)
Mozilla already supports a bunch of SVG (a pretty useful 20%, last I heard -- and they're working on the ever popular Gradients as we speak). Safari and Opera don't do SVG yet, but at least at Opera it is something we are looking at doing. (It's very popular with mobile vendors, and, well, they are our main customers, so...)
How would goverments "force standards"? If I want to write a Web browser that doesn't support HTML, why shouldn't I? Are you saying goverments should make Flash illegal?
I agree that if IE doesn't implement new standards, then they will just be ignored. However, the WHATWG things are designed to be easily implemented using HTCs so in theory you can still use them with IE6 once we have some non-binary HTCs written to support them. How well that will go down with authors has yet to be seen.
Slashdot Mirror
WHATWG work will all be based on HTML. So yes, we are extending an existing spec, not making a new one.
Because the browsers _are_ runtimes. Heck in the case of Firefox the entire browser is just an XML file with JavaScript and CSS.
What exactly (and I mean _exactly_) do you see your "runtimes" supporting, that your browsers don't?
Our developers said they couldn't develop a version of XPath lean enough.
In fact, of the specs I listed, we've had to _drop_ support for some (XHTML and XML, namespaces and XML Events were dropped in the last mobile device release I was involved with; and parts of DOM2 and parts of CSS2 are frequently considered as optional for mobile releases).
HTML does have a element. You can have as many forms as you like.
Indeed. WHATWG won't be making a standard. We plan to write a spec that can then be submitted to a standards organisation, nothing more.
Hm, the Curl I looked at wasn't XML based at all. Might be something else.
So if HTML isn't for application stuff, what should Slashdot be written in? Flash?
Yeah, one thing that came out of the Web Applications workshop last week is that the term "Web Application" means different things to different people.
As I said in another post, I agree that on the long term we need a set of APIs on par with an OS, but designed so that they work cross-platform. That's what Microsoft are doing with Longhorn, except that that is Windows-only. The Gnome people will probably come up with stuff of their own, which would be more cross-platform. Indeed Sun did this years ago with Java.
The problem is that writing a spec for this stuff is insanely hard. To do this for a sophisticated application platform on par with, say, Longhorn, is simply unfeasible, IMHO. Notice how WINE has to reverse engineer Windows to determine how it should work -- the Win32 APIs aren't good enough to know exactly how to do it. Or how the various Java clones have to reverse engineer Sun's Java to get interoperability, the Java API documentation isn't good enough either. Heck DHTML is already complicated enough that we have to reverse engineer IE to work out how it should work, and that is orders of magnitude easier than an OS-level API set would be.
Then again, the W3C are likely to be working on such an API as a result of this workshop, and I'm sure Mozilla and Opera will be taking part in that work if it happens. That doesn't stop there being a need, in the meantime, for a solution for those people writing applications this year, in HTML.
(Slashdot itself is an example of such an application. Would you rather use a standalone Slashdot application instead of using a Web browser to read and post on Slashdot?)
But as it says in http://whatwg.org/: The term "Web Application" in this context refers to applications accessed over the World Wide Web by using a Web browser. This group is not attempting to describe APIs for writing high-end sophisticated programs such as office productivity suites, graphics manipulation packages, or 3D games.
This is incorrect. IE6 does not support XHTML. It only supports HTML. (I've had Microsoft employees explicitly confirm this to me, too.)
Testcases to demonstrate this:
Testcase to demonstrate that IE doesn't even try to sniff for XHTML:
(The first two should be green if it supports XHTML. The last one should be green if it doesn't try to sniff for it (which would be the only way to support it if the first two tests fail). In a compliant UA, all three would be green.)
Well, is Slashdot a Web site, or a Web application?
WHATWG is targetting Web applications like Slashdot, eBay, Amazon, Voidwars, etc. Not Web Applications like server-hosted versions of Word, Excel, Quake, etc. I'm sure we all agree that trying to do a real Excel clone in HTML is simply a non-starter.
Every time we've made the browser more invisible, we've been hit by security nightmares like phishing. I think it makes a lot of sense to clearly mark remote applications as remote and to show their URI and so forth.
We care if it's implementable in IE6 because authors don't seem to want to do anything if it doesn't work in IE6.
Exactly.
So we can expect people to start using XHTML any day now, right? (As opposed to claiming to use XHTML but sending it as text/html.)
So instead of a "monolithic browser" you want a "monolithic runtime" that takes too long to update, lacks basic features, and leaves the rest of you at the mercy of a few companies who are more or less radical and "open", depending on the day of the week?
I really don't understand the difference between your VM idea and the browser of today, except that you would use XForms as the core instead of HTML. Different tags, same problems.
The more I read your VM proposal the less I understand it, unfortunately. I guess I need to see a more formal proposal to really understand what it means.
Yeah, I think it would be great to get Opera/Mozilla/Safari supporting SVG natively. Mozilla's already working on this, note (I heard they've got 20% of SVG1 done already).
I agree that on the long term we need a set of APIs on par with an OS, but designed so that they work cross-platform.
That's what Microsoft are doing with Longhorn, except that that is Windows-only. The Gnome people will probably come up with stuff of their own, which would be more cross-platform.
Sun did this years ago with Java. Why wasn't it successful?
The problem is that writing a spec for this stuff is insanely hard. To do this for a sophisticated application platform on par with, say, Longhorn, is simply unfeasible, IMHO. Notice how WINE has to reverse engineer Windows to determine how it should work -- the Win32 APIs aren't good enough to know exactly how to do it. Or how the various Java clones have to reverse engineer Sun's Java to get interoperability, the Java API documentation isn't good enough either. Heck DHTML is already complicated enough that we have to reverse engineer IE to work out how it should work, and that is orders of magnitude easier than an OS-level API set would be.
Then again, the W3C are likely to be working on such an API as a result of this workshop, and I'm sure Mozilla and Opera will be taking part in that work if it happens. That doesn't stop there being a need, in the meantime, for a solution for those people writing applications this year, in HTML.
(Slashdot itself is an example of such an application. Would you rather use a standalone Slashdot application instead of using a Web browser to read and post on Slashdot?)
Please do sit down and think about it. This is the kind of input we'd love to have.
What would be really helpful is having specific use cases in mind as well. For example, "Multiple document interfaces so that the user can be editing several meeting agendas at the same time with an Intranet calendar application".
Send your ideas to whatwg@whatwg.org (the WHATWG list).
Mozilla's implementation is over 150k. And that doesn't even do the XForms extensions to XPath. Not bloat? We're talking about devices where the entire product has to fit in less than 1000k here, and that has to include HTML4, XHTML, XML, namespaces, DOM0, DOM1, DOM2, CSS1, CSS2, XML Events, JavaScript, etc.
Mozilla, Safari, and Opera all support XHTML. Mozilla has supported since before it even had a namespace assigned. I don't see many people using it. There are a few blogs that use application/xhtml+xml but that's about it.
What matters to authors seems to be "does it work in IE6". Therefore that's what WHATWG is concerned about. The proposed extensions will all be implementable in IE6 using non-binary HTCs or a little JavaScript.
(In other words, it's not backwards compatible that is important, it's compatibility with the market leader. In this case, though, it's the same thing.)
The WHATWG mailing list is an open-subscription mailing list. Anyone can contribute. (Compared to W3C's $5000 membership fee, you could in fact say that it's rather more open.)
Microsoft have already ditched W3C. They have said they aren't implementing XHTML or SVG or CSS2.1 or CSS3 or DOM3 or XForms or MathML in the forseeable future. (As opposed to Mozilla, Opera, and Safari, who have all been actively adding support for many of these technologies over the last few years.)
Actually Microsoft was one of the few groups in favour of work like this at the recent workshop (they didn't want scripting involved, but apart from that were in favour with extending HTML rather than going down the XForms or other new language route).
I've looked at curl. If I remember correctly, it was not compatible with HTML, and IMHO did not separate style and content cleanly enough.
No, it doesn't mean SVG won't be supported. SVG 1.0 is just the thing for vector graphics, and it fits right into the HTML world if you use XBL, for instance. (Although admittedly that won't be backwards compatible and won't work in IE!)
Mozilla already supports a bunch of SVG (a pretty useful 20%, last I heard -- and they're working on the ever popular Gradients as we speak). Safari and Opera don't do SVG yet, but at least at Opera it is something we are looking at doing. (It's very popular with mobile vendors, and, well, they are our main customers, so...)
How would goverments "force standards"? If I want to write a Web browser that doesn't support HTML, why shouldn't I? Are you saying goverments should make Flash illegal?
I agree that if IE doesn't implement new standards, then they will just be ignored. However, the WHATWG things are designed to be easily implemented using HTCs so in theory you can still use them with IE6 once we have some non-binary HTCs written to support them. How well that will go down with authors has yet to be seen.
Drag and drop is indeed one of the things that I think HTML should allow. We'll probably be extending HTML to allow for drag and drop in WHATWG.
:-)
Anything else?