On Dec 9, 2005, at 3:42 PM, Ian Hickson wrote:
On Fri, 9 Dec 2005, Maciej Stachowiak wrote:
I think a lot of section 5.6 should be removed from the spec.
Most of section 5.6 consists of defining behaviour to ensure
interoperability between implementations, since if the spec doesn't
list
On Fri, 9 Dec 2005, Maciej Stachowiak wrote:
>
> I think a lot of section 5.6 should be removed from the spec.
Most of section 5.6 consists of defining behaviour to ensure
interoperability between implementations, since if the spec doesn't list
what happens then implementations either have to r
I think a lot of section 5.6 should be removed from the spec. In
general the reasons are as follows:
- functionality that isn't really needed or is redundant with
existing features
- features that are clearly insecure in web documents and may be a
risk even in local files in a browser (th
On Nov 21, 2005, at 4:13 PM, L. David Baron wrote:
In http://lists.w3.org/Archives/Public/public-webapi/2005Nov/0017 , I
wrote a comment on a WHATWG spec,
http://whatwg.org/specs/web-apps/current-work/#scs-session , which I
quote here:
On Monday 2005-11-21 07:44 -0800, Kenny wrote:
[...]
My
On Nov 30, 2005, at 2:12 AM, Jim Ley wrote:
On 11/30/05, Boris Zbarsky <[EMAIL PROTECTED]> wrote:
What should XMLHttpRequest.status return on connection timeout?
Ian and I were
talking about this, and it seems like "502" is a good response
code here...
See https://bugzilla.mozilla.org/sh
On Fri, 9 Dec 2005, Sander Tekelenburg wrote:
>
> How does all this menus stuff relate to the LINK element? I'm getting
> the feeling that this might kill the best of what the LINK element has
> to offer: ease of navigation through recognisability.
has had ten years to prove itself. It failed.
How does all this menus stuff relate to the LINK element? I'm getting the
feeling that this might kill the best of what the LINK element has to offer:
ease of navigation through recognisability.
Most websites use "menus" for navigation. Every website presents this
differently, even though often se
>> Can it be more explicitly said that the "form" content attribute
does not have a
>> DOM attribute equivalent.
>
> It does. In fact it has two (|form|, defined in DOM1 HTML, and |forms|,
> new in WF2).
I hope we'll get away with that change, but it may cause problems in
IE if authors use getAttr
