For the last few weeks four programmers (myself, Erik Arvidsson, Dimitri
Glazkov and Olav Junker Kjær) have been building an IE implementation of
Web Forms 2.0 for Internet Explorer.
We now have a working version available for testing. Because we are
programmers we are rubbish at testing
Hello,
I have been reviewing the Web Forms 2.0 specification and really like
the many advancements it outlines.
There is, however, one area in which it appears to overlook: file upload
status.
As a web developer I believe it would be very helpful to have some way
to indicate the progress
On Sun, 14 Aug 2005, Dwight Brown wrote:
I have been reviewing the Web Forms 2.0 specification and really like
the many advancements it outlines.
Great!
There is, however, one area in which it appears to overlook: file upload
status.
As a web developer I believe it would be very
James Graham wrote:
The problem is if I state one thing explicitly, then people will want
something else stated (does it allow IDNs? does it allow UTF-8
characters? does it allow fragment identifiers?). Why should one
aspect of something be redundantly stated?
Because it's identified by
# url
#An IRI, as defined by [RFC3987] (the IRI token, defined in RFC 3987
#section 2.2). UAs could, for example, offer the user URIs from his
#bookmarks. (See below for notes on IDN.) The value is called url (as
#opposed to iri or uri) for consistency with CSS syntax and because
On Mon, 27 Jun 2005, fantasai wrote:
# url
#An IRI, as defined by [RFC3987] (the IRI token, defined in RFC 3987
#section 2.2). UAs could, for example, offer the user URIs from his
#bookmarks. (See below for notes on IDN.) The value is called url (as
#opposed to iri or uri)
Ian Hickson wrote:
On Mon, 27 Jun 2005, fantasai wrote:
# url
#An IRI, as defined by [RFC3987] (the IRI token, defined in RFC 3987
#section 2.2). UAs could, for example, offer the user URIs from his
#bookmarks. (See below for notes on IDN.) The value is called url (as
#opposed
Ian Hickson wrote:
On Mon, 27 Jun 2005, fantasai wrote:
Does this allow relative urls? Please specify explicitly.
It is specified very explicitly.
Sorry, how about stated very obviously? the IRI token does not
obviously exclude relative URLs unless one is in the habit of
On Tue, 28 Jun 2005, James Graham wrote:
The problem is if I state one thing explicitly, then people will want
something else stated (does it allow IDNs? does it allow UTF-8
characters? does it allow fragment identifiers?). Why should one
aspect of something be redundantly stated?
On Wed, 13 Apr 2005, Jim Ley wrote:
Then please publish a seperate requirements document that does list
[the use cases].
Ok. Could you provide us with a list of features you believe need use
cases listed? That would be really helpful in creating such a document.
Thanks!
--
Ian Hickson
Ian Hickson wrote:
Ok. Could you provide us with a list of features you believe need use
cases listed? That would be really helpful in creating such a document.
Some feature in WF2 for which the use cases are not immediately obvious:
- the output element and the readonly attribute. Its not
(I hope y'all don't mind me replying to all your e-mails out of order. I'm
basically going down the spec one element at a time and when I come across
one that someone has discussed in the past, I reply to those e-mails.)
On Fri, 7 Jan 2005, Matthew Thomas wrote:
On 7 Jan, 2005, at 5:58 AM,
Finally, just by looking at the markup of the calculator example, I
don't see WF2 being any less powerful or elegant
Yeah, I agree, and I didn't mean to slam WF2 which I think is a very
fine spec. I was just afraid that W3C would disregard the killer
features of WF2 which is
On Fri, 7 Jan 2005, Rimantas Liubertas wrote:
I cannot agree. We should not mix typographical presentation for
presentation sake and typographical presentation for semantic reason.
While it may be not a big deal in chemistry, it is not so in math.
This may be a good way of putting it in
On Fri, 7 Jan 2005, dolphinling wrote:
green is just as meaningful as subscript--they're both purely
presentational, and we as people have attached meanings to certain
presentations. The semantics of subscript are completely different
from the semantics of there are two of the (chemical)
On 13 Apr 2005, at 19:31, Ian Hickson wrote:
On Wed, 13 Apr 2005, Dean Jackson wrote:
Ok. Could you provide us with a list of features you believe need use
cases listed? That would be really helpful in creating such a
document.
All of them.
That's never going to happen, just like the XHTML working
Dean Jackson wrote:
On 13 Apr 2005, at 19:31, Ian Hickson wrote:
On Wed, 13 Apr 2005, Dean Jackson wrote:
Ok. Could you provide us with a list of features you believe need use
cases listed? That would be really helpful in creating such a
document.
All of them.
That's never going to happen, just
Generally, I think the short usage notes improves the spec a lot.
Suddely the javascript: date: and file: schemes make sense to me!
There's no use case for this. It just has to be defined so that we get
interoperable behaviour, otherwise every UA will end up doing
something different.
Yes, I
On Wed, 13 Apr 2005, Olav Junker Kjær wrote:
There's no use case for this. It just has to be defined so that we get
interoperable behaviour, otherwise every UA will end up doing
something different.
Yes, I understand your reluctance to have unspecified behavior. I think
it might be
*Ian Hickson [EMAIL PROTECTED]*:
abbrMsuplle/sup/abbr
varxsub2/sub/var
I'm not sure how to deal with the chemistry case. We don't really have an
element for anything like chemical formulas.
Stretching its semantics really far, one could use 'code' for formulas¹
and 'abbr' for isotopes etc.
¹
Ian Hickson wrote:
Another criteria is could the presentation be changed without losing its
meaning?. For example, with em clearly you can change the presentation
without losing the fact that it is emphasis: whether it is bigger or
italics doesn't make much difference. But with sub I don't
On Tue, 12 Apr 2005, Olav Junker Kjær wrote:
Ian Hickson wrote:
FYI, the W3C has just acknowledged receipt of the Web Forms 2.0 draft
that Mozilla and Opera submitted (on behalf of the WHATWG).
Is this good or bad news? The W3C does not seem very enthusiastic about
the submission. How
Also sprach Olav Junker Kjær:
It is the first step to working with the W3C to move the
development of the WHATWG specifications into the W3C fold, while keeping
the open nature of the WHATWG development process.
Thats cool, but isn't this going to delay the spec for years?
No.
Also sprach Anne van Kesteren:
FYI, the W3C has just acknowledged receipt of the Web Forms 2.0 draft that
Mozilla and Opera submitted (on behalf of the WHATWG).
Any reason Apple didn't participate?
We tried to submit WF2 in time to be announced at the W3C Plenary
meeting in Boston in
Also sprach Dean Jackson:
Overall it seems like a good thing though.
I think so. Like I said in the comment, the important point for us
is to build a single community for improving forms on the Web.
I agree with this; I think we have rough consensus in the web
community within reach.
FYI, the W3C has just acknowledged receipt of the Web Forms 2.0 draft that
Mozilla and Opera submitted (on behalf of the WHATWG).
Web Forms 2 draft
http://www.w3.org/Submission/web-forms2/
W3C Team Comment
http://www.w3.org/Submission/2005/02/Comment
We'll be publishing another
Ian Hickson wrote:
On Thu, 24 Mar 2005, Csaba Gabor wrote:
2. Repetition model.
The Draft has a huge amount of space devoted to this,
but I haven't been able to think of a single compelling
argument for it. Most of the control enhancements such
as validation are conveniences, after all, but what
On Tue, 5 Apr 2005, Dean Edwards wrote:
Yeah, several people have said that. We're thinking about removing it.
On the other hand, several people have said that it is a godsend and
that they are so happy it is there because they are fed up of rolling
their own. At the moment it's
On Apr 5, 2005 6:50 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Sat, 26 Mar 2005, Joe Gregorio wrote:
In the Web Forms 2.0 Working Draft dated 16 March 2005
5.6. Submitting the encoded form data set
If the specified method is not one of get, post,
put, or delete then it
29 matches
Mail list logo
