Cameron McCormack wrote:
Boris Zbarsky:
On John Resig's tests in particular, every single failure in Gecko is
due to a violation of this part of the API:
Undefined=Empty
This is using a WebIDL syntax from a working draft that we don't
implement yet, and the current JavaScript DOM
2009/2/12 Priestley, Mark, VF-Group mark.priest...@vodafone.com:
[mp] As a general comment, I think this is a pretty difficult problem to
address in a secure manner. IMO the most reliable way of authorising an
update would be through the use of an update signature however, HTTPS
provides
Hi Ivan,
2009/2/9 ivan.demarino ivan.demar...@orange-ftgroup.com:
Hello.
I'm following the specs evolving for Window Modes
(http://dev.w3.org/2006/waf/widgets/#window-modes).
Given the fact that the content tag has an occurrence of 0 or 1, and the
fact that the mode is one, my question
Hi Mark,
2009/2/12 Priestley, Mark, VF-Group mark.priest...@vodafone.com:
[mp] To be clear I was suggesting that access to signatures was
restricted from the widget after installation. I was not suggesting that
they were not more generally available. As you say access to signatures
after
2009/2/12 Priestley, Mark, VF-Group mark.priest...@vodafone.com:
Thomas Roessler wrote:
Just for clarity, there are two possible requirements around OCSP and
CRLs:
- support embedding an OCSP response (or a CRL, or a link to a CRL)
in the mark-up of signatures
- support querying OCSP
Dear Marcos,
From my point of view the current model as described by you is ok. The author
of the update description document and the author of the widget resource that
shall be updated are able to control the security level shall be reached. This
is not mandated by the widget specifications
Firefox appears to have some issues that might related to the API, though I
haven't investigated the cause of those yet, so I don't know for sure.
Unfortunately, IE8 can't run John's tests because it relies on some DOM2
features that aren't yet supported, so the testing framework would need
John Resig wrote:
As of last night's nightly WebKit has the first 100% passing implementation.
Interesting. Did they do this by violating the If the user agent also
supports some level of CSS, the implementation SHOULD support the same
set of selectors in both these APIs and CSS
Hey Lachlan,
thanks for tracking this down.
On Feb 13, 2009, at 14:23 , Lachlan Hunt wrote:
But now that the NSResolver has been removed, the consistency
reasoning no longer really applies. The benefit to debugging still
sort-of does, but it is certainly debatable.
Given that adding
Hello.
I'm trying to stress a bit the current implementation of preferences
storage, comparing it to the LocalStorage.
I see that a preferences array was introduced, but this araise another
problem.
A Javascript Array it's NOT a map of key/value pairs. This means
that the preferences will have
Hello,
I am a little bit late in the debate, but I agree with scott proposal and
arguments. Ideally the widget itself shoud not be aware of HTML5 storage
implementation, even if the widget storage API use the same signature . And
mostly because of the same need: some architecture would
On Thu, 12 Feb 2009, Kartikaya Gupta wrote:
I also looked through the HTML5 draft and found the following properties
are of type DOMTimeStamp:
HTMLTimeElement.date
HTMLTimeElement.time
HTMLTimeElement.timezone
HTMLInputElement.valueAsDate
I've changed them to Date.
It would be nice
I think it would be much better to allow content types to be
derived by the packager and included in the package on
a file-by-file basis. This was the finding during the
development of MHTML many years ago, and the situation
isn't different here.
There are several operating systems in wide use
On Fri, Feb 13, 2009 at 9:47 AM, Thomas Landspurg
thomas.landsp...@gmail.com wrote:
Hello,
I am a little bit late in the debate, but I agree with scott proposal and
arguments. Ideally the widget itself shoud not be aware of HTML5 storage
implementation, even if the widget storage API
14 matches
Mail list logo
