Slashdot Mirror

The first thing they should consider is "where in the W3C specs is the behavior of this element specified"? If it ain't in any of 'em, it don't belong in the browser engine.

This is currently being debated for standardization by the Web Hypertext Application Technology Working Group, a consortium of developers and companies which formed in response to the perceived stagnation of the W3C. Many of its members are well-known developers and companies, and a number of them are or have been W3C members or parts of W3C working groups as well.

And, oddly enough, a recurring point in the mailing-list discussion of the "ping" attribute has been that it won't meet the needs of a lot of advertisers and tracking programs.

the developers need to make sure that users are made aware of all the URL's that are being pinged.

This is actually in the specification:

When the ping attribute is present, user agents should clearly indicate to the user that following the hyperlink will also cause secondary requests to be sent in the background, possibly including listing the actual target URIs.

The spec also indicates that users should be able to disable it:

Based on the user's preferences, UAs may either ignore the ping attribute altogether, or selectively ignore URIs in the list (e.g. ignoring any third-party URIs).

This is a first-pass implementation in a developer build, so they haven't implemented the UI to disable it (though you can get to it via about:config) and there's no mention of the notification yet, but I'd expect both to be in any released version of Firefox that includes this.

On the DDOS issue, I have to admit I'm surprised that the spec doesn't limit the number of URLs that can be pinged.

It's gone through the WHATWG, a group that's building new standards based on HTML instead of XHTML. They've got Opera, Mozilla, and KHTML/WebKit on board, and they do publis specs, so anyone else can build a compatible implementation without trying to reverse-engineer anything.

You probably haven't heard of them before because this is the first WHATWG extension that's generated this level of controversy. (The most well-known one is probably <canvas>, which is already in Safari and Firefox and will also be in Opera 9.)

IMHO this isn't a fault of WhatWG, but of the FF developers thinking they should run ahead and implement any draft before it has been considered carefully.

I'd say implementing something in a draft by the WHATWG is a far cry from making up their "own" standard.

One of the goals of the WHATWG is to refine proposals through feedback and submit them to the W3C.

http://whatwg.org/specs/web-apps/current-work/#pin g

The ping attribute allows Web pages to track which off-site links are most popular, as well as allowing advertisers to track click-through rates without obscuring the final target URI. It is possible to track users without this feature, but authors are encouraged to use the ping attribute so that the user agent can improve the user experience.

Encouraging good behaviour is great, but it doesn't fix the problem of bad guys obscuring the target URI. It will be up to the content publishers of the world to create ad policy that discourage bad behaviour...but that means they may have to turn away a few dollars here and there to be taken seriously and keep users safe.

For URIs that are HTTP URIs, the requests must be performed using the POST method (with an empty entity body in the request). User agents must ignore any entity bodies returned in the responses, but must honour the HTTP headers -- in particular, HTTP cookie headers.

We should try and do an experimental implementation of , to see if there are any unexpected real-world problems.

Yeah. These implementations speak:

XForms in Mozilla (with SVG integration)

WHATWG demos

And Jacques Surveyor speaks.

Not quite a standard yet, but on its way to being one: http://www.whatwg.org/specs/web-apps/current-work/ #scs-dynamic

Not in HTML4, nor in XHTML1.0 or 1.1

Canvas is a semi-proprietary element (originates from Apple, who first implemented it for Dashboard) that currently is in the under development HTML5/Web Applications 1.0 standard from WHATWG, but is (as far as I know) not part of the W3C's XHTML2 draft

Not in HTML4, nor in XHTML1.0 or 1.1

Canvas is a semi-proprietary element (originates from Apple, who first implemented it for Dashboard) that currently is in the under development HTML5/Web Applications 1.0 standard from WHATWG, but is (as far as I know) not part of the W3C's XHTML2 draft

Not in HTML4, nor in XHTML1.0 or 1.1

Canvas is a semi-proprietary element (originates from Apple, who first implemented it for Dashboard) that currently is in the under development HTML5/Web Applications 1.0 standard from WHATWG, but is (as far as I know) not part of the W3C's XHTML2 draft

It's because Opers's implementation of is at very early stage (JS in Opera is very fast). Since Opera helps to standari[zs]e <canvas> you can expect that they will aim for a pretty decent implementation.

Someone wake me up when there's a cross-platform graceful-degrading _standard_ for javascripted web apps.

In the meantime I've got another buzzword for you: HTML5.

Opera 8 supports all of CSS2.1 with the exception of: The visibility: collapse and white-space: pre-line property values [1]

Opera's internal buils are very close to passing Acid2.

Opera 9, AKA Merlin, is adding XSLT, designMode, more CSS3 stuff and "HTML5".

but the markup is XHTML

the WHATWG's Web Applications 1.0 is not HTML 5.0

But it's a whole lot easier if you code XHTML now. There's no denying that.

but the markup is XHTML

the WHATWG's Web Applications 1.0 is not HTML 5.0

But it's a whole lot easier if you code XHTML now. There's no denying that.

I am saying that the XHTML branch is the only branch of HTML that's still being developed

That's not true.

These people are trying to throw out the br tag. Not deprecate it. Yank it.

Why not? If you need to separate content into individual lines, that's what the <l> element type is for.

Having desktop applications in web application versions working just as good and integrating into web sites (or leverages being a web application in some other way) would be cool. It's also not very likely to happen very soon - even the gathering of pretty small extensions to HTML to add stuff like slider controls, regular expression validation and basic javascript drawing to the boilerplate web browser features will take years. (See http://whatwg.org/. Also contemplate three things: the date of the CSS 2.0 spec (May 1998), the current date (August 2005), and the number of versions of 90%+-market-share-hawking brand browsers that support it (0). )

There will always be browser-specific features that can solve it. Safari (by means of WebKit) has recently gained the ActiveX-like ability to support its own form of browser plugins that's basically wrappers of Cocoa NSViews, complete with JavaScript functions built-in. You could implement your whole Cocoa app in a plugin. This isn't the hard part. The hard part is laying it all out and getting everyone to agree on it, convincing fogeys like me that it actually will be worth it, and finally spending several years to come to consensus, implement it and maintain it for several years until it becomes somewhat stable. And *then* one could start building apps with it.

Aside from the cool factor, where's the huge benefit that justifies this time of implementation and puts all of my worries to rest? I'm still waiting for this after having read the replies to my original comments, and most, like yours, only specify that "hey, it can be done, and here's some emerging technologies that may or may not make it", which is nice, and which I already knew (see the last paragraph), but wasn't what I was contesting.

http://whatwg.org/

Web Applications specification.

IIRC, Mozilla's XMLHttpRequest object was created to mimic the functionality of Microsoft's ActiveX version, and then Safari and Opera (to a certain extent) followed suit. However, the XMLHttpRequest has never been part of ECMAScript (the standard that Javascript is based on) nor the W3C DOM. It has always been an "extension" that Microsoft has foisted upon the world, much like the >marquee< tags and layers we love to hate. As such, it is inconsistently supported -- particularly in Opera and Safari 1.3/2.0. There are also minor differences (e.g. the number of arguments that the send method accepts) that arise due to the lack of a standard specification.

IIRC, Mozilla's XMLHttpRequest object was created to mimic the functionality of Microsoft's ActiveX version, and then Safari and Opera (to a certain extent) followed suit. However, the XMLHttpRequest has never been part of ECMAScript (the standard that Javascript is based on) nor the W3C DOM. It has always been an "extension" that Microsoft has foisted upon the world, much like the >marquee< tags and layers we love to hate. As such, it is inconsistently supported -- particularly in Opera and Safari 1.3/2.0. There are also minor differences (e.g. the number of arguments that the send method accepts) that arise due to the lack of a standard specification.

XmlHttpRequest is a non-standard technology at the moment.

Yeah, but it will become a standard soon: it's in the Web Applications 1.0 working draft from the Web Hypertext Application Technology Working Group.

And this is a very good thing, because all the non-IE browsers will hopefully have a compatible implementation (today every browser is slightly different for anything that is not used by gmail :-().

XmlHttpRequest is a non-standard technology at the moment.

Yeah, but it will become a standard soon: it's in the Web Applications 1.0 working draft from the Web Hypertext Application Technology Working Group.

And this is a very good thing, because all the non-IE browsers will hopefully have a compatible implementation (today every browser is slightly different for anything that is not used by gmail :-().

The W3C has long given up on improving basic HTML standards where the rubber hits the road. Long wished for ideas like Web Forms 2.0 come from outside groups, and at least half of the HTML DOM has never been written down. Meanwhile the W3C masterbates with grotesque junk like XForms, breaking HTML compatibility with XHTML2. and trying to become a mini-CORBA with a raft of Web Services XML standards that nobody cares about.

I would say it goes back even further -- ever since the little pissy fight over HTML3 and CSS, the W3C has consistantly shown that they are not interested in helping the industry produce better HTML browsers. Browser vendors have little other choice but to route around the braindamage.

Anyway, Javascript needs a foreach operator. It is a good idea, so fuck you if you don't like it.

Is is basically a direct-mode graphics canvas, as specified by WhatWG canvas specification, which allows you to draw all kinds of graphic primitives using Javascript. This is based on Apple's implemented in Safari.

I would hope that some highly innovative graphics-applications can become possible using Javascript, when this goes mainstream.

It's mostly technical. Most of the people involved agree that the current forms situation is awful, but the w3c's solution (xforms) is too far away in the future, and something needs to be done now.

You can read the charter, and of course other people may have slightly different opinions or reasonings than me.

According to the WHATWG specification, their work isn't intendeded to replace XForms. So I think this entire ZDNet article is a troll.

A breakaway faction of the World Wide Web consortium (W3C) called WHAT-WG

According to the WHAT-WG page, "Many of the members of this working group are active supporters and members of the W3C..." So it seems they themselves do not see WHAT-WG as a "breakaway faction."

And if they actually rejected the W3C, why are they planning to submit their proposal through the standard W3C pipeline? Why not attempt to bypass or ignore it? If WHAT-WG are against the W3C, they would not be planning to cooperate with them.

It looks like this WHAT-WG is just another group submitting another proposal to the W3C. Yes, that proposal conflicts with an existing W3C one. But that doesn't indicate anything about turmoil in the W3C. It's just another potential standard that happens to have the same goal as another. Competition of standards in the W3C is nothing new.

Sound to me as if someone either missed the cluetrain, was having a slow news day and decided to invent a crisis, or swallowed some Microsoft FUD without checking his facts.

From the Web Forms 2.0 draft spec:

"This specification is in no way aimed at replacing XForms 1.0 [XForms], nor is it a subset of XForms 1.0.

XForms 1.0 is well suited for describing business logic and data constraints. Web Forms 2.0 aims to simplify the task of transforming XForms 1.0 systems into documents that can be rendered on HTML Web browsers that do not support XForms."

The Web Forms proposal is hugely important precisely because it can be implemented for IE using a "standard library" of client-side script. It won't be quite as nice as native implementations, but it'll work. It's the first evolutionary proposal I've seen that actually makes allowance for the festering carcass of IE holding everybody else back.

This is likely a reference to Safari's new canvas tag, mainly intended for dashboard. A version of it is being specified in the graphics part of the WAHT WG Web Applications 1.0 spec, so you're likely to see it in Mozilla sooner or later

This is likely a reference to Safari's new canvas tag, mainly intended for dashboard. A version of it is being specified in the graphics part of the WAHT WG Web Applications 1.0 spec, so you're likely to see it in Mozilla sooner or later

Take the XML and the XSL and transform it into 100% valid XHTML. HTML 4 is deprecated, the standard will not be updated.

As the poster said, they've tried HTML, and didn't like it. I very much doubt that the print quality of XHTML would be any better than HTML. (I don't quite understand either why you're including screen styles for a page that is intended only for printing.)

As for HTML 4 being a dead end, the WHAT WG, a collaboration among developers from most browsers, are defining a set of specifications intended to extend HTML4 in the short term, and serve as a base for a fifth version of HTML later.

or it could be a simple web app with some enhancements/extensions as envisioned by the whatwg, behaving as browser users expect it to behave, designed around internet response times, and thus providing response times that browser users are accustomed to.

currently i'm moving a client from a godforsaken ms-access app that i wrote many years ago to a web-based application that i intend to host on my own hosted virtual server. no more installation issues to deal with, no more relinking tables every time i ship a new version, no more ms-access-on-the-client requirement to deal with... when i have a new version ready i just upload it to the server and we're done.

i *am* looking forward to whatwg-like extensions, though, because the user interface is taking a step backward, from the user's perspective. whatwg should address some of those shortcomings.

The vendor will claim that it is due to either 1) client-side misconfigurations, or 2) unanticipated variations in the environment,

further argument for web applications. but again - must... improve... interface... !

both of which will be ironed out via a Professional Services contract accompanying the software "delivery". The end result will be the creation of numerous roles at the client's expense to "manage" and "coordinate" the software delivery, frustration at the end-user level, raises and kudos for the middle managers who jumped on the bandwagon, and fat wallets on the part of the shovelware designers.

unless a competitor comes along and says "why are you messing around with all that complicated proprietary not-thin-enough client technology for? here is my alternative, which is standards-compliant and requires only a web browser to use." (granted, perhaps a mozilla-based browser, but you'd just be doing them a favor anyway if they're not using one already).

go whatwg, go!

The Web Hypertext Application Working Group (what-wg) is actively working on improving HTML 4's forms, in a way that you can improve your existing HTML-based applications. They are also trying to address issues of IE compatibility.

XHTML 2 has a number of problems, from backwards-compatibility to human editability. A much better successor for HTML forms is Web Forms 2.0, which is also being worked on by Mozilla, as well as other major players in the industry. Obviously the real challenge is forcing Microsoft to support it.

That's what the WhatWG is all about.

Web apps might be a bit hackish, yes, but they're quite useful. Look, for example, at an airline booking site--that's a web app. So are eBay and Amazon. Can you think of any other reasonable way to allow everyone to book flights or buy stuff online? Web apps also drastically reduce the cost of developing and distributing the program in a corporate intranet.

Also, they're hackish because the languages used (namely HTML) weren't designed with web apps in mind and thus are missing a number of features that would be good for them. whatwg is trying to remedy that.

P.S. Not to be pedantic, but I will. :-) Did you know that the blockquote tag requires a block-level element inside of it?

No, I didn't. Thank you. :-)

And no, IE7 won't be a Transformer.

Microsoft does not sell IE. They gain no direct profit from people's use of it, so you have to wonder what their motive is here. Let's assume that "good" and "evil" are subjective and emotive words that have no relevance to this discussion, ok?

If you read Joel Spolsky's API war article, some perspective may be gained. Microsoft wishes only to discourage Web developers from moving away from the IE platform. If developers move away, Microsoft no longer has control over web development, and can no longer keep new technologies on the fringe.

This is bad news for a company with plans to move to network applications. If a platform for network applications exists outside of Microsoft's control, it will be much harder to profit from. Thus, Microsoft's interest is served here by retaining that 90%+ browser market share, to prevent the adoption of new technologies not under MS control.

It sounds like a nice idea but if MS chooses not to implement it or to do it badly (like say PNG support) then it is all for nothing UNLESS opera can use its dominance on the phones to some good. IF the phone is going to replace the PC (there are more mobile phones then PC's already) THEN people might be getting upset that their browser on their phones beats the pants of the browser on their PC.

Not likely but you never know. (to those who think people are going to switch because of IE security, HAHA, people still buy cars from companies whose cars KILLED PEOPLE, simple credit card fraud ain't gonna stop them)

Still they better fix that demo first this just looks stupid.

Good software requires alpha-blending? Right...

If Microsoft were to assign some engineers to IE, I'd take Web Forms 2.0 over graphics tricks. The web is pretty enough, make it more useful.