On Sun, 18 Jan 2009, Garrett Smith wrote:
What do IE6, IE7 and IE8 do?
I only tested IE8 and IE8's IE7 compatibility mode, and I don't recall
exactly what the results were, but they were taken into account when
writing the spec here. (In particular, IE doesn't distinguish between the
form
On Sat, 17 Jan 2009, Mike Wilson wrote:
I'm impressed with the level of detail that you strive for in
documenting real-world HTML :-)
It more or less is forced upon us if we want the spec to fulfill the role
of a document that accurately depicts how to write a user agent (be it a
browser,
Ian Hickson wrote:
On Sat, 17 Jan 2009, Mike Wilson wrote:
So I wonder what is your process
for determining if a quirk should be included in HTML5 or not?
It basically boils down to did Web browser vendors find that if they
didn't implement it, enough people complained to justify
Mike Wilson wrote:
Ian Hickson wrote:
On Sat, 17 Jan 2009, Mike Wilson wrote:
So I wonder what is your process
for determining if a quirk should be included in HTML5 or not?
It basically boils down to did Web browser vendors find that if they
didn't implement it, enough people complained to
On Thu, Jan 15, 2009 at 11:40 AM, Ian Hickson i...@hixie.ch wrote:
On Thu, 15 Jan 2009, Garrett Smith wrote:
If I understand this correctly, given a FORM with an INPUT named 'b', if
I change the name of that INPUT to 'a', then form.b should return the
element with name=a.
That isn't how it
Lachlan Hunt wrote:
a lot of interesting stuff
Thanks for all the information, it sounds good and reasonable.
Well done!
The idea is to make it so that browsers don't feel forced to
add _any_ non-standard behavior (other than experimental
innovations using vendor-prefixed names and
Mike Wilson wrote:
Lachlan Hunt wrote:
There will not be, at least in Opera, Firefox or Safari, new
modes added beyond the existing no quirks, limited quirks and
quirks modes.
Do you reckon all, or only some of, these modes will implement the
HTML5 spec? (and differ only in css/rendering)
Boris Zbarsky wrote:
Note that since this isn't a core DOM behavior, but rather an artifact
of the JS-to-DOM glue, in this case the behavior will depend on whether
you've accessed the control by name on the form in the past; if the
first such access is after the name change in Gecko, the
Mike Wilson wrote:
Ian Hickson wrote:
On Thu, 15 Jan 2009, Garrett Smith wrote:
If I understand this correctly, given a FORM with an INPUT
named 'b', if I change the name of that INPUT to 'a', then
form.b should return the element with name=a.
snip
What is the reason for introducing the
On Sun, 18 Jan 2009, Mike Wilson wrote:
Now I am just being curious ;-) but how on earth do you find all quirks
(and if they have been specially dealt with) - is it up to reports on
the mailing list or are you reading source code? :-)
Lachlan answered most of your questions, but I just
Ian Hickson wrote:
On Thu, 15 Jan 2009, Garrett Smith wrote:
If I understand this correctly, given a FORM with an INPUT
named 'b', if I change the name of that INPUT to 'a', then
form.b should return the element with name=a.
snip
What is the reason for introducing the past names
On Sat, 17 Jan 2009 14:18:07 +0100, Mike Wilson mike...@hotmail.com
wrote:
Ian Hickson wrote:
The idea is to make it so that browsers don't feel forced to
add _any_ non-standard behavior (other than experimental
innovations using vendor-prefixed names and stuff).
That's a good thing. Still,
(back on list)
On Wed, Jan 14, 2009 at 2:04 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 13 Jan 2009, Garrett Smith wrote:
On Tue, Jan 13, 2009 at 6:41 PM, Ian Hickson i...@hixie.ch wrote:
There were a number of e-mails on this thread regarding how Collections
Which thread are referring
On Thu, 15 Jan 2009, Garrett Smith wrote:
If I understand this correctly, given a FORM with an INPUT named 'b', if
I change the name of that INPUT to 'a', then form.b should return the
element with name=a.
That isn't how it works in Firefox, Opera, or Safari. Here is an example
of
There were a number of e-mails on this thread regarding how Collections
and other interfaces worked with respect to properties being exposed. I
have now updated the HTML5 spec to take into account the new features in
WebIDL that expose these properties. Please let me know if I missed one.
On Mon, Nov 10, 2008 at 12:56 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Thu, 14 Aug 2008, Garrett Smith wrote:
There is no note in the WF 2.0 specification, nor the HTML 4.01, nor the
HTML DOM specifications that an element should not be named submit or
action to avoid such consequences.
On Tue, 29 Jul 2008, Garrett Smith wrote:
I took a brief look at the WF 2.0 document yesterday and found some
serious misconceptions and examples of programming by coincidence.
These reflect very poorly on html5.
The errors can be found on the link:
On Thu, 14 Aug 2008, Garrett Smith wrote:
There is no note in the WF 2.0 specification, nor the HTML 4.01, nor the
HTML DOM specifications that an element should not be named submit or
action to avoid such consequences. Was this considered?
I don't think we want to limit these names, since
On Thu, Aug 14, 2008 at 1:18 AM, timeless [EMAIL PROTECTED] wrote:
On Tue, Aug 12, 2008 at 12:53 AM, Kristof Zelechovski
[EMAIL PROTECTED] wrote:
I have considered inline response. I have two options: do it by hand (I am
rather busy) and do it for every reply (which makes business people
On Thu, Aug 14, 2008 at 6:15 PM, Garrett Smith [EMAIL PROTECTED] wrote:
On Wed, Aug 13, 2008 at 2:02 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Wed, 13 Aug 2008, Kristof Zelechovski wrote:
While we are at collections and arrays, it is worth noting that the
{coll.length} attribute is a
On Tue, Aug 12, 2008 at 12:53 AM, Kristof Zelechovski
[EMAIL PROTECTED] wrote:
I have considered inline response. I have two options: do it by hand (I am
rather busy) and do it for every reply (which makes business people angry).
err. i didn't realize you were using outlook.
On Wed, Aug 13, 2008 at 2:02 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Wed, 13 Aug 2008, Kristof Zelechovski wrote:
While we are at collections and arrays, it is worth noting that the
{coll.length} attribute is a misnomer. I would always ask for
{coll.count} when I was learning and
Of Garrett Smith
Sent: Monday, August 04, 2008 7:47 PM
To: [EMAIL PROTECTED]
Subject: Re: [whatwg] HTML 5 : Misconceptions Documented
I'm a little surprised at the lack of response here, so I'm replying
to myself here, just to keep this issue active.
I did a little more research and found
Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Wednesday, August 06, 2008 8:24 PM
To: Maciej Stachowiak
Cc: Cameron McCormack; [EMAIL PROTECTED]
Subject: Re: [whatwg] HTML 5 : Misconceptions Documented
Testcases to determine what implementations do
by a constructed shortcut
property and we get the same result.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Wednesday, August 06, 2008 8:49 AM
To: Thomas Broyer
Cc: [EMAIL PROTECTED]
Subject: Re: [whatwg] HTML 5 : Misconceptions
PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Saturday, August 09, 2008 2:06 AM
To: WHATWG List
Cc: Maciej Stachowiak
Subject: Re: [whatwg] HTML 5 : Misconceptions Documented
On Thu, Aug 7, 2008 at 4:37 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Aug 7, 2008, at 3:44 PM
Of Garrett Smith
Sent: Saturday, August 09, 2008 2:06 AM
To: WHATWG List
Cc: Maciej Stachowiak
Subject: Re: [whatwg] HTML 5 : Misconceptions Documented
On Thu, Aug 7, 2008 at 4:37 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Aug 7, 2008, at 3:44 PM, Garrett Smith wrote:
I'd
.
Chris
See also http://msdn.microsoft.com/en-us/library/ms536460(VS.85).aspx.
-Original Message-
From: Garrett Smith [mailto:[EMAIL PROTECTED]
Sent: Monday, August 11, 2008 10:37 PM
To: Kristof Zelechovski
Cc: WHATWG List; Maciej Stachowiak
Subject: Re: [whatwg] HTML 5 : Misconceptions
On Thu, Aug 7, 2008 at 4:37 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Aug 7, 2008, at 3:44 PM, Garrett Smith wrote:
I'd like to put this back on the list, and it doesn't contain anything
personal, so I'm taking the liberty here.
I'm not sure what you mean by in the binding.
I meant
On Wed, Aug 6, 2008 at 7:06 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Aug 6, 2008, at 7:17 AM, Thomas Broyer wrote:
On Wed, Aug 6, 2008 at 11:29 AM, Maciej Stachowiak wrote:
I think Web IDL should provide a formalism to cater to this, because
nearly
all bindings with special
On Aug 7, 2008, at 1:51 PM, Garrett Smith wrote:
On Wed, Aug 6, 2008 at 7:06 PM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
On Aug 6, 2008, at 7:17 AM, Thomas Broyer wrote:
On Wed, Aug 6, 2008 at 11:29 AM, Maciej Stachowiak wrote:
I think Web IDL should provide a formalism to cater
(put back on list, forgot to reply-all)
On Thu, Aug 7, 2008 at 2:16 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Aug 7, 2008, at 1:51 PM, Garrett Smith wrote:
On Wed, Aug 6, 2008 at 7:06 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Aug 6, 2008, at 7:17 AM, Thomas Broyer wrote:
On Tue, Aug 5, 2008 at 4:02 PM, Thomas Broyer [EMAIL PROTECTED] wrote:
On Tue, Aug 5, 2008 at 8:03 AM, Garrett Smith wrote:
On Mon, Aug 4, 2008 at 3:17 PM, Thomas Broyer wrote:
Actually, there is:
http://www.w3.org/TR/html5/dom.html#htmlcollection
and I believe the elements property of
Hi Garrett.
Garrett Smith:
In EcmaScript, the property access operators seem to look like a
getter to Cameron. What they really do is provide access to
properties added to the collection, or, in one case (on one
implementation), this seems implemented as a getter. A getter is a
method that
On Aug 6, 2008, at 12:27 AM, Cameron McCormack wrote:
Hi Garrett.
Garrett Smith:
In EcmaScript, the property access operators seem to look like a
getter to Cameron. What they really do is provide access to
properties added to the collection, or, in one case (on one
implementation), this
On Wed, Aug 6, 2008 at 11:29 AM, Maciej Stachowiak wrote:
I think Garret has a valid point (despite his needlessly rude tone) that the
way we describe magical dynamic properties in a way that makes clear they
are also visible to the in operator and to
Object.prototype.hasOwnProperty. Are
On Wed, Aug 6, 2008 at 2:29 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Aug 6, 2008, at 12:27 AM, Cameron McCormack wrote:
Hi Garrett.
Garrett Smith:
[snip]
Your tests do show that the HTML collections expose items through real
properties rather than fake ones returned through a
On Aug 6, 2008, at 11:23 AM, Garrett Smith wrote:
My apologies for being rude.
What would you suggest, Maciej?
I would suggest:
a) Point out mistakes courteously.
b) Preferably do so in the appropriate public forum where others can
see them (I don't see any mail from you on this topic
On Aug 6, 2008, at 7:17 AM, Thomas Broyer wrote:
On Wed, Aug 6, 2008 at 11:29 AM, Maciej Stachowiak wrote:
I think Garret has a valid point (despite his needlessly rude tone)
that the
way we describe magical dynamic properties in a way that makes
clear they
are also visible to the in
On Wed, Aug 6, 2008 at 7:03 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Aug 6, 2008, at 11:23 AM, Garrett Smith wrote:
My apologies for being rude.
What would you suggest, Maciej?
I would suggest:
a) Point out mistakes courteously.
Done.
b) Preferably do so in the appropriate
On Mon, Aug 4, 2008 at 3:17 PM, Thomas Broyer [EMAIL PROTECTED] wrote:
On Wed, Jul 30, 2008 at 8:33 AM, Garrett Smith wrote:
(3) There is no specification for a special [[Get]] for the elements
HTMLCollection as a shortcut to namedItem, either (though this would not
seem to be a problem,
On Tue, Aug 5, 2008 at 8:03 AM, Garrett Smith wrote:
On Mon, Aug 4, 2008 at 3:17 PM, Thomas Broyer wrote:
Actually, there is:
http://www.w3.org/TR/html5/dom.html#htmlcollection
and I believe the elements property of HTMLFormElement is actually
an HTMLFormControlsCollection:
I'm a little surprised at the lack of response here, so I'm replying
to myself here, just to keep this issue active.
I did a little more research and found that the misconception is more
common that I thought: DOM objects that have indexed properties are
often mistaken for arrays. This is the
On Wed, Jul 30, 2008 at 8:33 AM, Garrett Smith wrote:
(3) There is no specification for a special [[Get]] for the elements
HTMLCollection as a shortcut to namedItem, either (though this would not
seem to be a problem,
Actually, there is:
http://www.w3.org/TR/html5/dom.html#htmlcollection
and
I took a brief look at the WF 2.0 document yesterday and found some
serious misconceptions and examples of programming by coincidence.
These reflect very poorly on html5.
The errors can be found on the link:
http://www.whatwg.org/specs/web-forms/current-work/#select-check-default
Doc Bugs:
1)
] HTML 5 : Misconceptions Documented
I took a brief look at the WF 2.0 document yesterday and found some
serious misconceptions and examples of programming by coincidence.
These reflect very poorly on html5.
The errors can be found on the link:
http://www.whatwg.org/specs/web-forms/current-work/#select
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Wednesday, July 30, 2008 8:34 AM
To: [EMAIL PROTECTED]
Subject: [whatwg] HTML 5 : Misconceptions Documented
I took a brief look at the WF 2.0 document yesterday and found some
47 matches
Mail list logo
