[whatwg] A Quick Greeting and Some Comments

On Tue, 8 Jun 2004, Kurt Cagle wrote:
>
> I have a few general comments, and will have more as I get a chance to
> review the draft specifications.

Please do send your comments! All comments are very welcome, at any time.


> 1) My gut reaction when I hear people talking about using IE6 as a
> baseline model for development is to cringe. IE6 represents an endpoint
> technology, reflecting standards that are now a couple of years out of
> date, and employing specific capabilities that raise some serious
> security concerns. There are a number of VERY good ideas to be taken
> from IE6, but frankly I think that the innovation that I'm seeing now in
> both the Mozilla and Opera sides makes me feel that it should only be
> used as one reference point among many.

IE6 is only being used as a baseline in that anything WHATWG specifies has
to be implementable in IE6 using scripting, CSS or HTCs, or, at the very
least, has to gracefully degrade in IE6.

The reason for this is simple: technologies that aren't compatible with
the market leader are rarely successful, especially in this market.

Don't worry though, this does not really limit the features that can be
added. IE6 is surprisingly extensible.


> 2) XForms is a cool technology, even with its wrinkles, but its also far
> too complex for the average web developer. Having said that, I think the
> underlying MVC architecture has a lot to recommend it.

Indeed. XForms, in itself, is a very good design. The main problem is with
its lack of compatibility with IE6 and lack of graceful degradation in any
browser, not with its features.


> XForms does the following that I feel is noteworthy to draw back into
> other models -
> 	a) Makes XML, not delimited query string text or form content, the
> preferred mechanism for communicating with the server. This is a huge win,
> all things considered, because it makes it possible to pass contextual or
> relational information from the client rather than force the server to map
> a dictionary into a complex data structure.

It would be nice to be able to make Web Forms 2 send back XForms instance
data (or similar). I'm not sure how to do it. The way XForms does it
(making the relevant attributes schyophrenic, sometimes containing XPath
expressions and sometimes containing tag names, depending on whether the
XPath expression matches something or not) is way too strange, IMHO.


> 	b) Creates an abstract model for defining controls, which, while complex,
> are also both very portable and easily extensible. What XForms doesn't
> provide, and what WHAT is potentially useful for doing, is providing a
> consistent bridge layer between the abstraction layer and the final
> presentation layer.

HTML controls are just as generic, portable, and easily extensible as
XForms controls.


> 	c) XForms can readily be accomplished both directly on the client and via
> server technology; having built systems capable of doing both, I find that
> there are advantages in having each technology.

When it is done on the server, it's down-converted to HTML4, right? You
can do that with Web Forms 2 pages even more easily than XForms pages,
given that Web Forms 2 is basically just a few declarative extensions to
HTML4 that can be implemented in script. :-)


> 	d) XForms is predominantly declarative. There are at least eight subtly
> different versions of Javascript out there, not to mention four or five
> distinct DOMs which add considerably to the complexity of programming
> imperatively in a web environment.

That's a misleading statement. XPath is easily as complex if not more
complex than ECMAScript, and has many variants too. And there is a
standard ECMAScript and a standard DOM that makes the use of those
languages simple.


> Declarative architectures are more robust in the face of such
> differences than imperative ones are, especially if you create a set of
> standardized imperative component libraries.

Declarative architectures are good for common tasks, but for complex tasks
they rapidly become significantly more complex than imperative models.

Web Forms 2 attempts to strike a balance with the really common stuff
being declarative and the more complex stuff being script-based.


> 	e) Given all that, walking away completely from XForms is probably not
> the most effective way of working, especially as it does have a couple
> years headstart over WHAT.

More to the point: walking away completely from HTML4 Forms is probably
not the most effective way of working, especially as it does have half a
decade headstart over XForms. WHAT's Web Forms 2 proposal is an extension
of a technology that predated XForms and is more widely implemented, used
and understood.

(If we had not ignored XForms in this work, we would have justed used
XForms. The problem is that it does not address the backwards
compatibility concerns that our charter says we must address.)


> 3) I wrote an XQuery book three years ago, as part of a Wrox team. I wrote
> an XQuery book last year as part of a SAMS team. Between the two, I've
> sold 30 copies. I'm convinced that XQuery, which represents the collective
> work of the largest database manufacturers (and is one of the few W3C
> specs actively supported by Microsoft) will be stillborn. Why? Because it
> confuses a very real need (the need to extract XML content from a data
> store in a consistent manner) with a perceived marketing need (the need to
> create a "better" SQL). I raise this point as a cautionary one; does WHAT
> provide enough of a benefit that browser vendors, web developers and the
> public will all see it as satisfying a real need?

It's a good question, one that I think every feature proposed should be
carefully examined against. At the moment, I think most of the proposals
do satisfy a need, although the rest are marginal (is the repeating
sections stuff addressing a real need?). If you think any of the proposals
don't, please identify them for discussion. We certainly don't want to be
doing stuff that isn't needed.


> 4) Another cautionary tale. The wireless phone industry all lauded WAP/WML
> when it first came out, saying that it would revolutionize the way that
> content was handled on the handheld web. Yet today, WAP/WML is largely an
> irrelevancy in the face of chips that have become powerful enough to
> handle more traditional HTML views.

Indeed. They should have simply used the existing technologies -- HTML,
CSS, DOM -- the way that they are doing now, and the way that WHATWG
intends to do, instead of inventing new technologies (like XHTML2, XForms,
XPath...).


> Transitional technologies require the same amount of time and energy to
> implement as new technologies do, the same amount of programming to
> implement into the firmware of cards, the same adoption curve that
> "bleeding edge" tech has.

Indeed. The roaring "success" of XHTML1 is a good example! :-)


> As I see it WHAT is fairly conservative in that it recommends
> incremental changes into the browser environments rather than wholesale
> ripping out of core pieces of functionality. Yet if the same problems
> persist with the newer model as does with the older one, have you
> necessary made the problem any easier, or have you simply created more
> incompatibilities between systems?

Obviously, the intention is to not persist the problems, but to solve
them. However, if you have any specific concerns where you think the
current proposals are indeed creating more incompatibilities, please bring
them up, so we can solve them.


> 5) I have written behaviors for Microsoft itself; it was cool technology
> back in 1999. Today, I typically implement those behaviors using
> external namespaces and the intelligent use of XSLT. This takes a little
> more work, but the code is generally much cleaner in its implementation.
> This is a case of different strokes for different folks, though I think
> there are some things that can and should be taken from this. [...]

The behaviours stuff is being handled by the W3C and is out of scope for
WHAT. The correct forums for behaviours/bindings are the www-svg at w3.org
and www-style at w3.org mailing lists. The technology is being developed
under the name XBL at this time.


> 6) Bundled behaviors of this form also bypass the CSS mechanism that I
> find so cumbersome when dealing with behaviors in IE. I've written
> several books on CSS; it is an antiquated technology that is difficult
> to extend into XML without a huge amount of work, and it is rapidly
> being deprecated in most new web browser technologies in favor of some
> form of NON-STANDARD styling mechanism.

I would be interested in discussing the demise of CSS some more, but this
is not the appropriate mailing list. Could you raise this subject in
www-style at w3.org?


> 7) Don't discount SVG.

Indeed. SVG is the vector graphics language that should be used with HTML,
much like PNG is the non-lossy raster graphics language. WHAT does not
intend to either discourage the use of SVG or cripple SVG in any way.


> 9) Perhaps a continuation of #5. The goal with any such system is to push
> declarative rather than imperative solutions whenever possible, and to
> push generalized DOM solutions over application specific ones when you
> can't. My own estimation of DOM has changed considerably over the years.
> At first, I saw it as a transitional technology, but increasingly I'm
> coming to see DOM as being a a generalized interface language that
> eliminates much of the complexity of OOP framework systems. Again SVG is a
> good model for this - rather than creating a complex set of customized
> components (a rect object, an oval object, whatever), each with its own
> access methods and procedures, you create a generalized DOM for working
> with the object in an abstract fashion, setting the position by changing
> the value of an attribute, adding or removing objects into the model
> through straightforward DOM insertions/deletions, and so forth.

I'm not sure what point you are making here.


Thanks for your comments. I look forward to more specific points that we
can discuss in more detail.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 8 June 2004 02:54:33 UTC