On Sun, 2 Aug 2009, Aryeh Gregor wrote:
First, a general remark: what's the difference supposed to be between
PASS and BUG? Firefox and WebKit are listed as PASS and BUG in
these two cases respectively, for instance:
On Sun, 2 Aug 2009, Jeremy Orlow wrote:
On Sun, Aug 2, 2009 at 7:17 PM, 白石俊平 shumpei.shirai...@gmail.com wrote:
I'm implementing the HTML5 Web Storage using Gears
(http://code.google.com/p/gear5/), so I have several questions with
the spec.
-Storage.setItem(key, val)
--is key
On Tue, Aug 11, 2009 at 7:46 PM, Greg Wilkinsgr...@mortbay.com wrote:
Jonas Sicking wrote:
Can you suggest changes to the WS protocol that would make it a better
general-purpose protocol?
There were several threads on the IETF HYBI mailing list with some such
proposals:
On Mon, 3 Aug 2009, TAMURA, Kent wrote:
The `value' DOM attribute of HTMLOptionElement is incompatible with the
current major browsers.
The spec says:
http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#dom-option-value
Jonas Sicking wrote:
I agree we should use the experiences from HTTP. However it seems like
we have different experiences.
For example mime-types in HTTP have a very troubled record. Look at
Adam Barth's draft [1] for what browsers are forced to do to stay
compatible with the web.
Thanks, Ian.
--when value is null, should `setItem(key, null)` behave as like as
`removeItem(key)`? (localStorage.setItem(key, null);
alert(localStorage.length); -- what is value displayed?)
No, it's not the same as removeItem. It'll be set to 'null'.
This changed recently; it'll now
On Wed, 12 Aug 2009, �~Y��~_���~J平 wrote:
and, when passed value is undefined (e.g. `setItem(key)`), which
behavior will be correct?
On current implementation of browsers, I looked as follows.
- IE and Firefox raise error, (arguments number is incorrect)
- Webkit family persist it as string
I believe WebIDL says that a TypeError exception should be thrown, but it
was not immediately obvious to me how to derive this from the spec.
Ok, I understood what behavior is correct (and that current webkit's
behavior is a bit wrong).
very thanks.
On Wed, Aug 12, 2009 at 5:34 PM, Ian
On Wed, Aug 12, 2009 at 1:10 AM, Greg Wilkinsgr...@mortbay.com wrote:
Jonas Sicking wrote:
I agree we should use the experiences from HTTP. However it seems like
we have different experiences.
For example mime-types in HTTP have a very troubled record. Look at
Adam Barth's draft [1] for
Jonas Sicking wrote:
The only site where I can
remember seeing content negotiation actually used is on w3.org
fwiw, MXR (and even LXR) uses some content negotiation, and it
generally magically works. OTOH it's transparent, so you shouldn't
see it :).
But yes, I'd say that content negotiation
Missed a few parts to reply to:
On Wed, Aug 12, 2009 at 1:10 AM, Greg Wilkinsgr...@mortbay.com wrote:
Of course the 0x80 length framed binary data type could be
used to send mime encoded messages, but then there would need
to be other standards to work out what style of meta-data was
used -
Jonas Sicking wrote:
I'd rather not debate about which process should be used to get to a
good protocol. I'd rather debate concrete proposals.
Sure.
So I think I'll keep this response short and see if I can
come up with a BWTP mkII proposal that addresses
the feedback that I've received.
On Wed, 12 Aug 2009 12:52:38 +0200, Remco remc...@gmail.com wrote:
On Wed, Aug 12, 2009 at 10:57 AM, Philip Jägenstedtphil...@opera.com
wrote:
Before suggesting any changes to the source element, make sure you
have
read
The spec should explicitly specify which MouseEvent properties are
available during the various drag events to avoid assumptions.
The spec requires them to all be set on all drag events, currently.
I thought that this was clear too but apparently it's not clear that they
should be set to
On Wed, Aug 12, 2009 at 1:26 PM, Philip Jägenstedtphil...@opera.com wrote:
On Wed, 12 Aug 2009 12:52:38 +0200, Remco remc...@gmail.com wrote:
On Wed, Aug 12, 2009 at 10:57 AM, Philip Jägenstedtphil...@opera.com
wrote:
Before suggesting any changes to the source element, make sure you have
On Wed, 12 Aug 2009 14:45:36 +0200, Remco remc...@gmail.com wrote:
On Wed, Aug 12, 2009 at 1:26 PM, Philip Jägenstedtphil...@opera.com
wrote:
On Wed, 12 Aug 2009 12:52:38 +0200, Remco remc...@gmail.com wrote:
On Wed, Aug 12, 2009 at 10:57 AM, Philip Jägenstedtphil...@opera.com
wrote:
On Wed, Aug 12, 2009 at 3:52 PM, Philip Jägenstedtphil...@opera.com wrote:
The resource selection algorithm loops through the source elements and when
it reaches the last one just waits for another source element to be
inserted. It doesn't make any distinction between static markup and elements
On Wed, Aug 12, 2009 at 1:34 AM, Ian Hickson i...@hixie.ch wrote:
On Wed, 12 Aug 2009, į~Y―į~_ģäŋ~Jåđģ wrote:
and, when passed value is undefined (e.g. `setItem(key)`), which
behavior will be correct?
On current implementation of browsers, I looked as follows.
- IE and Firefox raise
Jeremy Orlow wrote:
and, when passed value is undefined (e.g. `setItem(key)`), which
behavior will be correct?
...
I believe this is the correct section of the spec to be looking
at: http://dev.w3.org/2006/webapi/WebIDL/#es-DOMString
If so, I think it's pretty clear that
On Mon, 3 Aug 2009, Erik Vorhes wrote:
On Mon, Aug 3, 2009 at 6:29 AM, Ian Hickson i...@hixie.ch wrote:
Not all titles are citations, actually. For example, I've heard of the
/Pirates of Penzance/, but I'm not citing it, just mentioning it in
passing.
No, that actually is a citation,
Boris Zbarsky:
Given the actual example code (and not its description, which
doesn't match the code), the relevant section is
http://dev.w3.org/2006/webapi/WebIDL/#es-operations steps 1 through
3 in the third bullet point.
It looks to me like per the current spec text that will throw a
On Mon, 3 Aug 2009, Daniel Gredler wrote:
On Sat, Aug 1, 2009 at 4:59 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 22 Jul 2009, Daniel Gredler wrote:
Second, why not walk the prototype chain? Similar rules regarding
host objects and regular objects could apply to prototypes. You
On Wed, Aug 12, 2009 at 4:26 PM, Cameron McCormack c...@mcc.id.au wrote:
Boris Zbarsky:
Given the actual example code (and not its description, which
doesn't match the code), the relevant section is
http://dev.w3.org/2006/webapi/WebIDL/#es-operations steps 1 through
3 in the third bullet
On Mon, 3 Aug 2009, Garrett Smith wrote:
Why did you want valueAsNumber in the first place?
Why do you need valueAsDate?
Both of these seem unnecessary, out of place and overcomplicate INPUT.
Both are included as convenience methods to allow authors to get the data
in a direct form
On Mon, 3 Aug 2009, Kartikaya Gupta wrote:
Also, editorial fix: in the same two paragraphs (On getting and
On setting for valueAsNumber), the link to valueAsDate is wrong;
it just links back to #dom-input-valueAsNumber instead of
#dom-input-valueAsDate.
It appears I already
On Wed, Aug 12, 2009 at 3:08 AM, Ian Hicksoni...@hixie.ch wrote:
In 4.2.4:
If the attribute is present, then the user agent must assume that the
resource is of the given type. If the attribute is omitted, but the
external resource link type has a default type defined, then the user
agent
On Wed, Aug 12, 2009 at 6:21 PM, Ian Hicksoni...@hixie.ch wrote:
On Mon, 3 Aug 2009, Erik Vorhes wrote:
On Mon, Aug 3, 2009 at 6:29 AM, Ian Hickson i...@hixie.ch wrote:
Not all titles are citations, actually. For example, I've heard of the
/Pirates of Penzance/, but I'm not citing it, just
27 matches
Mail list logo
