Re: [selectors-api] Stringifying undefined (was: Call for Consensus - Selectors API to Candidate Rec)
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 binding in Gecko always
converts undefined in parameters to the string undefined.
I started (but did not finish yet) looking at all the uses of DOMString
in various web specs to see what the default behaviour should be for
both [Null] and [Undefined]. So far, it seems that stringifying
undefined to undefined is much more widely implemented:
http://mcc.id.au/2009/01/string-handling/string-handling
If that does end up being the more common behaviour, I’ll change the
default in Web IDL to be to stringify to undefined unless overridden,
and I would suggest Selectors API to use that behaviour, too.
The following are reasons we ended up with the spec defining to
stringify it to the empty string instead of undefined.
Initially, the spec didn't define any explicit behaviour, implicitly
relying on whatever the default was. When the first few implementations
were tested, there was a lack of interoperability between them. Each
implementation stringified null and undefined to a different
combintation of null, undefined or empty string. So it was decided
that this needed to be resolved by making the issue more explicit.
At the time, we also had the NSResolver in place, and there were use
cases that required return values of null, undefined and to all be
treated as the empty string, meaning no namespace. This was so that JS
authors didn't have to explicitly define the default namespace.
e.g.
function nsresolver(ns) {
uri = {xht: http://www.w3.org/1999/xhtml;,
svg: http://www.w3.org/2000/svg}
return uri[ns];
}
For resolving the default namespace, this would return undefined. And
there were similar cases where it made sense for null or to be
returned instead.
This meant that null and undefined had to be stringified to instead
of null and undefined, respectively.
In order to make the handling of null and undefined consistent
throughout the API, it was also decided that passing null and undefined
as the selector parameter should also stringify to the empty string.
This also has the nice authoring benefit of throwing an exception when
an author accidentally passes a undefined or null variable, which would
most likely be a mistake. Having the exception would help with
debugging the problem, whereas simply treating it as null or
undefined strings would just fail to match any elements (unless there
happened to be null and undefined elements in the document, which is
rare)
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.
There are 2 problems with changing the spec now to use the default
behaviour instead of defining the empty string:
1. We are getting ready to go to PR. It would be rather annoying to
have to hold up this for much longer. Although I generally don't
like letting bureaucratic issues like this get in the way of doing
things, if it can be avoided.
2. We already have 2 implementations, Opera and WebKit, that implement
the behaviour as defined, and Mozilla does it for null. IE8 still
stringifies to null and undefined, respectively.
3. If we do this for undefined, should we also do it for null?
(i.e. undefied - undefined, null - null instead of )
If we could do the change quickly and have all browsers commit to making
this change relatively quickly, preferably before shipping, and then
demonstrate interoperability, then it is theoretically possible. But I
don't know. I've CC'd Rune, one of our developers, who can comment on
whether or not we could or would make the change.
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [widgets] Comment on Widgets 1.0: Digital Signatures - the Usage property
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 a workable alternative and plain HTTP might be fine in other
circumstances. For what it's worth I think that the real security issue is
how the update is handled but this doesn't mean defining an update
signature is not useful.
I agree that an update signature would be useful, but would like to
see this just be solved with HTTP and HTTPS for v1. That should cover
most use cases.
Here is my current thinking. Widget version 1 is distributed and
signed. The config looks like this:
widget version=1.0
update href=https://some.com/update?version=1.0; /
/widget
Because the widget was signed, the update href can be considered
authoritative/trusted. That securely downloads the update description
document:
widgetupdate xmlns=http://www.w3.org/ns/widgets;
src=https://example.com/myWidget/v1.1b/awesome.wgt;
version=1.1
id=http://example.com/myWidget;
size=1024
notify=https://example.com/myWidget/updateManager.php?this-v=1.1amp;was-v={version};
details href=http://a.com/myWidget/1.1/whatsnew;
We fixed some bugs and improved performance!
/details
/widgetupdate
The src is downloaded and treated as a normal widget package. If it is
not signed, or the signature cannot be validated, then the usual
warnings are given. If it is signed, then it is processed as normal.
Is there much wrong with the current model?
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
Re: If not Multiple-Contents, how do we have Widgets with multiple modes?
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 is: - Would it be possible to have widgets that have multiple views? I dug into the widgets-api, and what it looks like is the fact that the only place where the widget should handle mode change is the call-back named onmodechange(). That's fine. But we are assuming that there is an initial mode chosen by the Developer and that the widget change it's shape based on the event onmodechange. - What if the Developer can't know in which mode the Widget will start? We could make it explicit that the widget user agent should attempt to start the widget in the mode the author declared (or in floating, as is the default). - What if the User-Agent running the Widget does not pass a onmodechange, because NO MODE WAS CHANGED: it was simply initialized with a mode different from the one chosen in the config.xml? We could specify that a user agent must fire a mode change event if it initializes the widget in a mode other than the default or the mode that the author specified. It's a bit tricky to explain, but I can give more details if needed. If the above would not help, then more details would be helpful to build a use case. One of the great thing of having widgets with multiple modes, is the fact that the same widget can run in different scenarios, based on the hosting platform screen resolution AND other requirements. The widget has to adapt itself at load time. Right. A widget that, for example, run in window mode and just after load has to change to docked, because that's the mode supported by the current User-Agent, will look clunky and not seamlessly integrated. What do you think? This may be true. Can you go into more details about how we might overcome this? is this an author's problem or a user agent problem? what more can we do on the user agent side to overcome this issue? Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging Configuration spec
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 installation (outside of the widget) is useful and should be supported. Could you please explain what the security implications of allowing a widget to have access to the signatures at runtime? (apologies if you have done this in another email, I might have missed it). Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Getting synch'ed up on Widgets Digital Signatures
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 responders (and CRLs) as part of certificate validation I'd argue that the latter is more important than the former. [mp] I agree latter is more important, but see below... Frederick Hirsch wrote: we need explicit schema support (in Signature 1.1) for explicit OCSP responses, for the latter a processing rule in widgets signature may be enough. Perhaps this does not need to be required must in the widgets spec, depends on requirements. Mark, I believe you mentioned you have additional thoughts on these requirements. [mp] The requirements state that it must be possible to include revocation information in the signature, and when present that the specification should say how to process this information [3]. On re-reading this requirement, I wonder whether we didn't fold two requirements into one and not get it quite right... In any case, looking at the requirement afresh, as Thomas and Frederick suggest, the ability to include OCSP responses in signatures should be addressed in XML Signature Syntax and Processing Version 1.1 [4]. Our requirement should probably be changed to be the ability to process revocation information contained in the signature, and should probably be a SHOULD. Ok, that makes sense. In regards to the processing of revocation information, orignally I was pushing for Widgets 1.0: Digital Signatures [1] to include an OCSP and CRL profile to try and help ensure interoperability between OCSP/CRL clients and responders/servers across organisations. My suggestion for an OCSP profile would have been to reference (or take inspiration from) the OMA Online Certificate Status Protocol Mobile Profile [2], however, I'm no longer sure that this is a good idea. This profile is obviously aimed at mobile devices and therefore may create inter-operability issues for non-mobile implementations (and mobile implementations that don't follow OMA). So more generally, I would propose that OCSP and CRL processing should be removed from [1]. The reasoning being that it is likely that other standards bodies, companies and organisations will want to specify this behaviour in order to work with their existing infrastructure. I am more and more of the opinion that [1] should simply provide the format and processing rules that enables the use of interoperable signatures across widget user agents. How these signatures are used should be covered elsewhere. Ok, that would make things a bit easier. -- Marcos Caceres http://datadriven.com.au
RE: [widgets] Comment on Widgets 1.0: Digital Signatures - the Usage property
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 family. If somebody wants to provide an unsigned update package via HTTP for a signed widget resource then this will not be prevented by a widget user agent. Best Regards, Rainer * T-Mobile International Terminal Technology Rainer Hillebrand Head of Terminal Security Landgrabenweg 151, D-53227 Bonn Germany +49 171 5211056 (My T-Mobile) +49 228 936 13916 (Tel.) +49 228 936 18406 (Fax) E-Mail: rainer.hillebr...@t-mobile.net http://www.t-mobile.net This e-mail and any attachment are confidential and may be privileged. If you are not the intended recipient, notify the sender immediately, destroy all copies from your system and do not disclose or use the information for any purpose. Diese E-Mail inklusive aller Anhänge ist vertraulich und könnte bevorrechtigtem Schutz unterliegen. Wenn Sie nicht der beabsichtigte Adressat sind, informieren Sie bitte den Absender unverzüglich, löschen Sie alle Kopien von Ihrem System und veröffentlichen Sie oder nutzen Sie die Information keinesfalls, gleich zu welchem Zweck. T-Mobile International AG Aufsichtsrat/ Supervisory Board: René Obermann (Vorsitzender/ Chairman) Vorstand/ Board of Management: Hamid Akhavan (Vorsitzender/ Chairman), Michael Günther, Lothar A. Harings, Katharina Hollender Handelsregister/Commercial Register Entry: Amtsgericht Bonn, HRB 12276 Steuer-Nr./Tax No.: 205 / 5777/ 0518 USt.-ID./VAT Reg.No.: DE189669124 Sitz der Gesellschaft/ Corporate Headquarters: Bonn
Re: Call for Consensus - Selectors API to Candidate Rec
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 to be rewritten to make it work. Just to update: The test suite now runs in IE 8. Demo: http://ejohn.org/apps/selectortest/ As of last night's nightly WebKit has the first 100% passing implementation. --John
Re: Call for Consensus - Selectors API to Candidate Rec
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 recommendation? I'm not sure what I think of this, if so, Perhaps the test should be testing that selectors API returns the same results as CSS selector matching instead of testing that particular selectors which might become valid CSS in the future are unsupported. That way, if at some point an extended :not syntax is in fact implemented we won't have browsers implementing it failing this test all of a sudden. -Boris
Re: [selectors-api] Stringifying undefined (was: Call for Consensus - Selectors API to Candidate Rec)
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 NSResolver (or something like it) is potential for v2, it might be best to keep the thinking that brought us here from it? There are 2 problems with changing the spec now to use the default behaviour instead of defining the empty string: 1. We are getting ready to go to PR. It would be rather annoying to have to hold up this for much longer. Although I generally don't like letting bureaucratic issues like this get in the way of doing things, if it can be avoided. I reckon that if it had to be done, given the size of the change you could get the major stake-holder to okay the change publicly and still go to PR claiming that LC was done through the commenting and that a zero-length CR is fine. Hey, it can feel wrong yet be sooo right. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
RE: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs Storage
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 to hold only the values.
This looks a bit incoeherent with the idea of having preferences
stored as key/value pairs. Doesn't it?
I would propose to introduce the same kind of methods available for
HTML5 LocalStorage. Not necessarelly the same signatures, but equivalent
methods.
This means to modify slightly the widget object introducing stuff
like:
class widget {
...
long preferencesCount();
string getPreferenceKey(long index) throws
DomException.INDEX_SIZE_ERR;
string getPreference(string key);
void setPreference(string key, string value) throws
DomException.QUOTA_EXCEEDED_ERR;
void removePreference(String key);
void preferencesClear();
...
}
This ensures enumeration and some utility methods that can become
handy (like a clear and a count).
What do you think?
Best Regards
---
Ivan De Marino
Orange Labs
Mobile and Web Software Engineer, RD UK
tel. +44 20 8849 5806
mob. +44 7515 955 861
mob. +44 7974 156 216
ivan.demar...@orange-ftgroup.com
This e-mail, and any files transmitted with it, is intended only for the
use of the person/s or entity to whom it is addressed. If you are not
the intended recipient (or authorised to receive information for the
intended recipient) you must not use, disclose, copy, print or rely on
this e-mail. If an addressing or transmission error has misdirected this
e-mail, please notify the author by replying to this e-mail and delete
all copies of this e-mail. Thank you.
France Telecom RD UK Ltd is a company registered in England and Wales
with company number 4193379. Our registered office is Minerva House,
Montague Close, London, SE1 9BB.
-Original Message-
From: public-webapps-requ...@w3.org
[mailto:public-webapps-requ...@w3.org] On Behalf Of Jonas Sicking
Sent: 12 February 2009 19:20
To: timel...@gmail.com
Cc: Scott Wilson; public-webapps@w3.org; Ian Hickson
Subject: Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs
Storage
timeless wrote:
I think the problem here is that there's too much syntactic sugar in
sessionStorage/localStorage (this is more feedback to HTML5 or WebIDL,
and maybe Hixie or others could help to address it).
I can easily replace the object (window.sessionStorage={})
The sessionStorage property is readonly so that won't work.
but I
can't be told when my sessionStorage is decorated by a new property,
because that's not something which is available to JS (gecko has
__noSuchMethod__, but there's no watch(sessionStorage, *, feedback).
If there was a way for js objects to be told about property writes
then for the most part, they could replace a host's
sessionStorage/localStorage with their own object and do what they
need.
Today, if the HTML5 sessionStorage/localStorage objects relied on
(sugar-free) methods only, they wouldn't have a problem. -- No, I'm
not advocating this.
Things like watch points aren't really defined if they should work when
it comes to host objects I think. And if we used an API like
setProperty/getProperty they certainly would not work.
So I don't think the problem here is with the specific API localStorage
uses either. But rather with the fact that Scott is trying to deploy a
widget implementation in an environment where he is restricted about
what the APIs he is implemented are called.
I think in this instance though the problem can be worked around by
adding event listeners to the Document listening for 'storage' events.
That can be used to then save the data server-side.
/ Jonas
Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs Storage
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 require a server
side implementation of the settings instead of a client side, especially if
you want to provide the same account on different platforms.
On Fri, Feb 13, 2009 at 6:37 PM, Scott Wilson
scott.bradley.wil...@gmail.com wrote:
Defining equivalent methods to HTML 5 Storage - rather than mandating the
same implementation - seems like a reasonable compromise.
It would enable us to provide a consistent model for developers, while at
the same time making it more obvious how to migrate widgets and authoring
tools based on existing widget APIs, i.e.:
http://www.w3.org/TR/widgets-land/#apis
S
On 13 Feb 2009, at 16:54, ivan.demar...@orange-ftgroup.com
ivan.demar...@orange-ftgroup.com wrote:
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 to hold only the values.
This looks a bit incoeherent with the idea of having preferences
stored as key/value pairs. Doesn't it?
I would propose to introduce the same kind of methods available for
HTML5 LocalStorage. Not necessarelly the same signatures, but equivalent
methods.
This means to modify slightly the widget object introducing stuff
like:
class widget {
...
long preferencesCount();
string getPreferenceKey(long index) throws
DomException.INDEX_SIZE_ERR;
string getPreference(string key);
void setPreference(string key, string value) throws
DomException.QUOTA_EXCEEDED_ERR;
void removePreference(String key);
void preferencesClear();
...
}
This ensures enumeration and some utility methods that can become
handy (like a clear and a count).
What do you think?
Best Regards
---
Ivan De Marino
Orange Labs
Mobile and Web Software Engineer, RD UK
tel. +44 20 8849 5806
mob. +44 7515 955 861
mob. +44 7974 156 216
ivan.demar...@orange-ftgroup.com
This e-mail, and any files transmitted with it, is intended only for the
use of the person/s or entity to whom it is addressed. If you are not
the intended recipient (or authorised to receive information for the
intended recipient) you must not use, disclose, copy, print or rely on
this e-mail. If an addressing or transmission error has misdirected this
e-mail, please notify the author by replying to this e-mail and delete
all copies of this e-mail. Thank you.
France Telecom RD UK Ltd is a company registered in England and Wales
with company number 4193379. Our registered office is Minerva House,
Montague Close, London, SE1 9BB.
-Original Message-
From: public-webapps-requ...@w3.org
[mailto:public-webapps-requ...@w3.org] On Behalf Of Jonas Sicking
Sent: 12 February 2009 19:20
To: timel...@gmail.com
Cc: Scott Wilson; public-webapps@w3.org; Ian Hickson
Subject: Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs
Storage
timeless wrote:
I think the problem here is that there's too much syntactic sugar in
sessionStorage/localStorage (this is more feedback to HTML5 or WebIDL,
and maybe Hixie or others could help to address it).
I can easily replace the object (window.sessionStorage={})
The sessionStorage property is readonly so that won't work.
but I
can't be told when my sessionStorage is decorated by a new property,
because that's not something which is available to JS (gecko has
__noSuchMethod__, but there's no watch(sessionStorage, *, feedback).
If there was a way for js objects to be told about property writes
then for the most part, they could replace a host's
sessionStorage/localStorage with their own object and do what they
need.
Today, if the HTML5 sessionStorage/localStorage objects relied on
(sugar-free) methods only, they wouldn't have a problem. -- No, I'm
not advocating this.
Things like watch points aren't really defined if they should work when
it comes to host objects I think. And if we used an API like
setProperty/getProperty they certainly would not work.
So I don't think the problem here is with the specific API localStorage
uses either. But rather with the fact that Scott is trying to deploy a
widget implementation in an environment where he is restricted about
what the APIs he is implemented are called.
I think in this instance though the problem can be worked around by
adding event listeners to the Document listening for 'storage' events.
That can be used to then save the data server-side.
/ Jonas
--
Get the ALL NEW Webwag Mobile - http://webwag.com/mobile
Thomas Landspurg - Webwag
Re: DOMTimeStamp binding
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 if WebIDL or Web DOM Core said what Date meant for non-JS languages. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
MIME types for packaged content (was re: tag: uri scheme)
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 today which allow files without extensions to be sniffed on the client. This would also allow the inclusion of charset parameters in text types, which, in general, cannot always be easily sniffed, even if they are well known in the context of the packager. While I'm dubious about the arguments on MIME type sniffing for browsers, I think it's completely unnecessary for packaged content, because of the explicit package step necessary to provide conformant content. (I changed the subject line because the topic isn't about the 'tag:' URI scheme.) Larry -Original Message- From: Marcos Caceres [mailto:marcosscace...@gmail.com] Sent: Friday, February 13, 2009 5:27 AM To: Larry Masinter Cc: Bjoern Hoehrmann; public-pkg-uri-scheme; WebApps WG Subject: Re: tag: uri scheme Hi Larry, 2009/1/22 Larry Masinter l...@acm.org: https://issues.apache.org/bugzilla/show_bug.cgi?id=13986 Astounding. Thanks for that pointer, hadn't seen that history. Still, communication of a package is different than communication of individual components, because there's an explicit processing step which is create the package. Even if there might be some reasons why Apache hasn't fixed their configuration files, is there any reason to believe that create a package software couldn't be configured to always use well-known file extensions or (if allowed) well-known content-types? Our current model in that we are thinking of putting into the widget packaging spec is: 1. match the file extension to a mime type using the extension to MIME type tables in the packaging spec. 2. if no match is made, then attempt to sniff the mime type. 3. if no match is made, label the file 'unknown/unknown'. What we could do is add a step 0, where authors could have an XML-based (or text based) format for declaring extension to MIME (e.g., php - text/html) or overriding default extensions to MIME mappings. For example, types xmlns=http://www.w3.org/ns/widgets; type ext=php mime=text/html/ type ext=jsp mime=text/html/ type ext=htm mime=application/xhtml+xml/ /types The above elements could either just be part of the configuration document, or could be in a separate file. I'll still claim that the closer you are to the origin of the data, the more likely you are going to be able to guess the context of the data. probably true. -- Marcos Caceres http://datadriven.com.au
Re: Widget API Set/GetPreferences vs. HTML5 Key/Value Pairs Storage
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 use the same signature . And mostly because of the same need: some architecture would require a server side implementation of the settings instead of a client side, especially if you want to provide the same account on different platforms. Hmm.. i'm a bit confused. My proposal was to use a server side backend for the .localStorage API. This would mean that there is no need to introduce a new API. From my understanding of the original issue that was brought up in this thread, using a separate API rather than .localStorage would only be a short term solution, until browsers start natively supporting the widget API. So that does not seem like a good solution. However it seems possible to use other solutions to implement a server side backend for localStorage by using the callbacks defined in the HTML5 spec. / Jonas
