Re: [whatwg] Comparison of XForms-Tiny and WF2

2007-01-18 Thread Dave Raggett

On Thu, 18 Jan 2007, Jon Ferraiolo wrote:

I have a very simple question from the land of Ajax (and OpenAjax 
Alliance). Can either XForms-Tiny or WF2 be implemented in 
JavaScript such they run on today's browsers, or do they both 
require new version of browsers (or plugins) to ship before the 
features can be used?


Jon


XForms-Tiny does indeed run on today's browsers, see

  http://www.w3.org/2006/11/XForms-Tiny/

Where you can try it out for yourself on your browser on a wide 
range of examples. This makes use of an open source cross browser 
script library that works on Internet Explorer 6 and 7, Firefox 1.5, 
Firefox 2, Opera 9, Konqueror 3.5, Safari, Opera Mobile 8.6 and 
NetFront 3.4. When delivered via HTTP as a compressed file, the 
download size is only 6 KBytes. The library will be updated to 
reflect changes to the specification, and a first Working Draft is 
expected in early 2007.


WF2 has been implemented as a script library for Internet Explorer 
and in principle a cross browser library could be developed. 
However, web page developers would still need to write additional 
page specific scripts to match the features that are built into 
XForms-Tiny. For a single page that might be okay but the costs soon 
add up when accumulated across applications. A declarative approach 
reduces the development cost and likelihood of errors. Another 
advantage is the means to automatically generate the server side 
validation from the markup rather than having to code it separately 
with the risk of mismatch between the client and server code.


p.s. I am looking into providing declarative support for using Ajax to 
support dynamic load and save operations without the need for any 
additional scripting other than loading the XForms-Tiny library.


 Dave Raggett [EMAIL PROTECTED] http://www.w3.org/People/Raggett



Jon Ferraiolo [EMAIL PROTECTED]
Web Architect, Emerging Technologies
IBM, Menlo Park, CA
Mobile: +1-650-926-5865


Re: [whatwg] Comparison of XForms-Tiny and WF2

2007-01-18 Thread Dave Raggett

On Thu, 18 Jan 2007, Jon Ferraiolo wrote:



Hi Dave,
Thanks for the update. Given that XF-T has already proven to run 
on today's browsers, no matter how the W3C ends up reconciling 
XF-T vs WF2, it seems to me that a MUST requirement is that the 
result of this XF-T vs WF2 reconciliation should be technology 
that can be implemented via a small JavaScript library such that 
it can run on top of today's browsers.


It would also be nice if:

1) There was a highly modular open source implementation of this 
new (XF-T vs WF2) technology which could be added as a module to 
the many fine Ajax libraries that exist in the world.
2) There was some attention to make sure that this new (XF-T vs 
WF2) technology were designed to integrate well with HTML/Ajax 
IDEs so that developers can create and debug their applications 
using modern software development approaches, such as WYSIWYG 
developer tools and integrated debuggers.


Jon


Both sound like excellent suggestions, and I would be interested in 
exploring them further, preferably in collaboration with people who 
know much more about Ajax IDEs than I do.


p.s. I think that it isn't a question of XF-T vs WF2, but rather a 
synthesis of the best of both proposals. I will be exploring this on 
the public wiki maintained by the W3C Forms working group over the 
next month or so.


 Dave Raggett [EMAIL PROTECTED] http://www.w3.org/People/Raggett


Re: [whatwg] Problems with the definition of cite

2007-01-18 Thread Benjamin Hawkes-Lewis
I wrote:

 That's not a fair summary: see the example I gave to Anne van Kesteren
 of getting back to a Hamlet scene text from citeHamlet, I.ii/cite
 with a mere Google query.

James Graham wrote:
 Using the cite attribute to link to a search page is at best almost-useless 
 and at worst damaging and confusing. 

Sorry, I didn't make myself clear. The cite in my example does /not/
link anywhere. My point was that even with the mere knowledge that the
contents of cite are a citation, agents can construct useful web
queries. Not as good as a cite with a URI, but not /useless/.

  It would be more accurate to see cite could
  be improved upon. IMHO it would be nicer to have real elements in HTML
  for detailed bibliographic elements, but that goes against the general
  consensus that we should shift detailed semantics into
  microformats/roles.
 
 So, if we accept that full bibliographic data will only be accepted as a 
 microformat, does cite have enough value to warrant keeping it? If the best 
 use case we can manage is it could link to a search for the source I would 
 say 
 the element is worthless.

My point was it could be used as the basis for a search by an automated
agent. This would be true of a microformat like hcite too, /if/ there
any guarantee that Web Applications 1.0 compatible user agents would
support such a microformat. (Of course, if there were such a guarantee,
one would have to ask why the microformat in question wasn't part of the
spec in the first place.) Guaranteed recognition of the cite element
is better than nothing.

 I suspect that browser makers would be unwilling to implement this change 
 since 
 there are probably a fair few sites that depend on cite being italic to 
 look 
 as the author intended and, as far as I know, major browsers have essentially 
 interoperable default style sheets so making this change would break sites 
 compared to the competition.

From the perspective of website visitors, I'm not such a change would be
remarkable. For example, in some bibliographic styles, book titles for
example are non-italic anyway. From the perspective of authors, a fix
preserving the faulty semantics is trivial (style cite italic) and a
revision of their site to use the correct semantics is desirable.

I asked:
 Deprecating cite wouldn't solve any problems, as far as I can see. How
  would you connect q or blockquote to a particular hCite block?

James Graham replied:
 Indeed in many cases where citations are important there is no 
 direct quote to match the citation (almost all scientific papers fit this 
 model). 

This might well be an argument for providing ways to explicitly connect
cite with elements other than q or blockquote (a global attribute
citeref could perhaps do that rather well). Given the existence of the
humanities (a literary form in which extended series of quotations are
decorated with footnotes and occasional commentary), I can't see how
it's in any way an argument against providing ways to explicitly connect
cite with q and blockquote.

James Graham continued:
 But, accepting that some people think this is very important, I don't 
 see how a cite element that is not part of the microformat helps here - 
 unless 
 sandwiching stuff in cite without the microformat filling can itself lead 
 to 
 the development of worthwhile UA features.

Well, the original idea was the cite could contain some sort of link,
and that this would be a way of associating a URI with a q or
blockquote. To this I made an additional point, that the mere act of
marking up a bit of content as a citation with cite makes it easier to
perform more sophisticated automated processing, such as retrieving a
best guess source.

How worthwhile such automated processing is depends partly on whether
the spec and tools make it easy to provide citations in URI form.

--
Benjamin Hawkes-Lewis



[whatwg] onchange events for input type=radio

2007-01-18 Thread Boris Zbarsky
There has recently been an interesting Mozilla bug report about onchange for 
radio inputs.  It seems that UAs interoperably implement something non-obvious; 
it may be a good idea to specify it:


https://bugzilla.mozilla.org/show_bug.cgi?id=363693

-Boris