Hmm. Does this take us back to viewmodes [1]? For example you also have the
ability on Windows Phone to have the live tiles view, with primary and
secondary tiles, and both square and wide tiles...
Also it may be necessary to consider where apps are intended not to take over
the device, but as
On 1 Aug 2013, at 18:29, Kornel Lesiński wrote:
On 1 August 2013 12:44:19 Scott Wilson scott.bradley.wil...@gmail.com wrote:
Or you could perhaps use XML. A bit like, er, this:
http://www.w3.org/TR/widgets/
Hehe ;)
I'm trying to address two things:
1. it's been shown ever and over
Or you could perhaps use XML. A bit like, er, this:
http://www.w3.org/TR/widgets/
On 18 Jul 2013, at 14:57, Kornel Lesiński wrote:
I'd like to propose using HTML as basis of manifest format, similar in spirit
to Web Components imports, e.g.
link rel=manifest import
On 19 Jun 2013, at 07:59, Charles McCathie Nevile wrote:
On Wed, 19 Jun 2013 06:56:13 +0200, Anne van Kesteren ann...@annevk.nl
wrote:
On Tue, May 14, 2013 at 7:47 PM, Marcos Caceres mcace...@mozilla.com wrote:
The current proposal can be found here:
http://manifest.sysapps.org/
I
On 14 May 2013, at 15:00, Marcos Caceres wrote:
On Tuesday, 14 May 2013 at 14:32, Arthur Barstow wrote:
Scott indicated [1] Wookie implemented Widget Updates and Chaals
indicated [2] he would followup with Opera but I couldn't find a
response from them in the list archive.
Do we
On 20 Oct 2012, at 13:12, Arthur Barstow wrote:
For various reasons, a Candidate Recommendation of Widget Updates was never
published, although the CfC to do so passed and the ED is prepared as such
[widget-updates].
Since no one has raised this as an issue, I would like feedback on what
On 21 Aug 2012, at 13:20, Arthur Barstow wrote:
Marcos would like to publish a Proposed Edited Recommendation [PER] of the
Widget Packaging and XML Configuration spec [REC] to incorporate the spec's
errata and this is a Call for Consensus to do so.
The [Errata] has already been reflected
On 6 Jun 2012, at 01:10, Arthur Barstow wrote:
On 5/30/12 2:36 PM, ext Arthur Barstow wrote:
What are people's thoughts on whether or not the Quota Management API spec
is ready for First Public Working Draft (FPWD)?
(Ooops, cp error above: s/Quota Management/Webapp Manifest/)
A rule of
On 6 Jun 2012, at 16:10, Tobie Langel wrote:
On 6/6/12 5:02 PM, Marcos Caceres w...@marcosc.com wrote:
On Wednesday, June 6, 2012 at 2:58 PM, Tobie Langel wrote:
Absolutely, or:
html manifest=/path/to/config.webapp
and combine appcache and config into a single format. The AppCache
On 1 Jun 2012, at 12:15, Arthur Barstow wrote:
On 5/31/12 5:23 PM, ext Adam Barth wrote:
Is anyone besides Mozilla interested in implementing this specification?
I don't recall anyone else committing to an implementation (although it could
be a bit early).
I'd be interested in
On 27 May 2012, at 17:45, Anant Narayanan wrote:
On 05/27/2012 01:35 AM, Marcos Caceres wrote:
On 26 May 2012, at 18:32, Anant Narayananan...@mozilla.com wrote:
The intent for the screen_size parameters is not to let the developer
enforce a particular screen size or resolution, but rather
On 27 May 2012, at 17:49, Anant Narayanan wrote:
On 05/27/2012 05:11 AM, Marcos Caceres wrote:
On 27/05/2012 12:36, SULLIVAN, BRYAN L wrote:
Re At install time or when I am browsing apps, how does a server know
my screen resolution? Or is this restriction imposed on by the user
agent?: When
On 25 May 2012, at 17:25, Marcos Caceres wrote:
On Friday, May 25, 2012 at 4:34 PM, SULLIVAN, BRYAN L wrote:
Marcos,
Re I thought we had stopped the whole designing for particular screen
sizes, etc. a long time ago., that may be the still-closely-held goal, but
the reality is
On 14 May 2012, at 18:12, Anant Narayanan wrote:
Hi Scott,
Thanks for your comments, more inline.
On 5/13/12 12:06 PM, Scott Wilson wrote:
On 12 May 2012, at 19:02, Anant Narayanan wrote:
Q. Why not simply reuse the widgets spec [2]?
A. Aside from naming (we're talking about apps
On 12 May 2012, at 19:02, Anant Narayanan wrote:
Hi everyone,
I recently joined the webapps working group and I'd like to introduce myself!
I work at Mozilla and for the past year or so have been working on our Apps
initiative [1]. Our goal has been to make it very easy for developers to
On 9 Mar 2012, at 08:10, Stefan Hakansson LK wrote:
The webrtc WG has identified that the ability to notify, and possibly wake
up, a web application of incoming events is important. This to enable support
of use cases such as incoming calls. And in certain scenarios the resource
use (e.g.
On 8 Feb 2012, at 10:31, Bronislav Klučka wrote:
On 8.2.2012 1:06, Jean-Claude Dufourd wrote:
On 7/2/12 05:31 , Robin Berjon wrote:
The first problem is that of the security model. A lot of smart people have
tried to come up with a lot of different solutions here, often involving
On 1 Feb 2012, at 21:04, Tim Berners-Lee wrote:
On 2012-02 -01, at 15:23, Marcos Caceres wrote:
Hi Tim,
On Wednesday, 1 February 2012 at 16:42, Tim Berners-Lee wrote:
Note that when people talk about installation, they often immediately
discuss
packaging and manifest formats,
I'm not sure if the Widget Interface spec[1] and test cases[2] agree on the
semantics of clear() storage calls. The Web Storage spec[3] indicates that
for clear() all items should be removed from the storage array (i.e. deleted),
however some of the test cases assume that the values of the
On 16 Sep 2011, at 13:55, Dominique Hazael-Massieux wrote:
IMO, keeping them together will lead to confusion. The use cases are
different: a widget can embed content that uses ApplicationCache, as
well as load in proprietary APIs (e.g., WAC).
Surely a Web-applicationcached app could also
Hi,
In my attempt to get our conformance level from 97% to 100%, I've been trying
to implement the Storage Event requirement for widget.preferences in the Widget
API spec [1]. I'm using the following JS code injected into the widget page to
raise the event:
[89] var evt =
On 13 Jul 2011, at 16:41, Marcos Caceres wrote:
On 7/13/11 5:08 PM, Scott Wilson wrote:
Hi,
In my attempt to get our conformance level from 97% to 100%, I've been
trying to implement the Storage Event requirement for widget.preferences
in the Widget API spec [1]. I'm using the following
On 29 Jun 2011, at 12:34, Marcos Caceres wrote:
On Wed, Jun 29, 2011 at 12:08 PM, Charles McCathieNevile
cha...@opera.com wrote:
On Tue, 28 Jun 2011 20:17:38 +0200, Scott Wilson
scott.bradley.wil...@gmail.com wrote:
I think Bruce Lawson was dropping a big hint the other day to look again
On 30 Jun 2011, at 14:55, Arthur Barstow wrote:
Given the lack of support for stopping work on Web Storage [1], I'd let to
get consensus on the plan to move it to Last Call Working Draft.
Currently there are two open bugs:
1. Bug 12111: spec for Storage object getItem(key) method does
I think Bruce Lawson was dropping a big hint the other day to look again at the
questions Mike posed a long while ago! I know there was discussion at the time,
but I think both initiatives have moved on somewhat so its worth returning to.
On 20 Oct 2010, at 19:40, Mike Hanson wrote:
Note
On 24 Jun 2011, at 10:41, Marcos Caceres wrote:
On Fri, Jun 24, 2011 at 11:08 AM, Rich Tibbett ri...@opera.com wrote:
Marcos Caceres wrote:
On Fri, Jun 24, 2011 at 1:28 AM, Charles Pritchardch...@jumis.com
wrote:
One issue which comes up is that widget is also used in ARIA to describe
Part of the issue is that its a fairly generic technology that can be applied
to areas including:
- Browser extensions
- Installable web apps
- Desktop widgets
- Site gadgets
- TV/STB widgets
- Mobile webapps
I think the name widgets came from the heritage of Opera Widgets, Nokia
Widgets,
On 14 Jun 2011, at 06:28, Marcos Caceres wrote:
On Monday, June 13, 2011, Ian Hickson i...@hixie.ch wrote:
On Mon, 13 Jun 2011, Marcos Caceres wrote:
I thought maybe I could get away with:
When getting or setting the preferences attribute, if the origin of a
widget instance is mutable
I'm having a go at implementing the defaultlocale attribute, but have a problem
with the test cases - these all use defaultlocale=x-w3c-test.
The problem is that this is a private use code, and so converts to
und-x-w3c-test during processing. By default I don't even allow BCP
extensions in
On 13 May 2011, at 16:06, Marcos Caceres wrote:
Hi,
I changed dlocuse00 to use the language tag xx instead of en-gb...
http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/ta-defaultlocale-usage/000/ta-de-000.wgt
I've tried this one but don't really understand it. I thought that
On 24 May 2011, at 15:17, Marcos Caceres wrote:
On 5/23/11 10:18 AM, Scott Wilson wrote:
Within the education vertical, the IMS consortium created a basic launch
protocol for widget-like applications including user information and custom
parameters [1] and we created a shim for using
Within the education vertical, the IMS consortium created a basic launch
protocol for widget-like applications including user information and custom
parameters [1] and we created a shim for using it with Apache Wookie [2]. So
certainly a tractable area; If anything the IMS spec could work with
This test case states:
Tests that update-info element's version attribute should have a value higher
than current version for the widget to be updated. The widget is not updated or
replaced.
However, in the specification itself, there is no condition that the potential
update version has to
On 28 Apr 2011, at 12:19, Rich Tibbett wrote:
Scott Wilson wrote:
Right, I've done some basic work on the tests in Apache Wookie - most of
them seem to work OK so far; I need to do interactive testing next - I've
tested processing the update element in config.xml and acquiring
On 28 Apr 2011, at 14:11, Hari Kumar G wrote:
On Thu, 28 Apr 2011 14:57:20 +0200, Scott Wilson
scott.bradley.wil...@gmail.com wrote:
...
One more thing, the widget at:
http://people.opera.com/harig/wupdres/resources/pass.wgt
... isn't valid as its not well formed - there should
On 26 Apr 2011, at 16:59, Rich Tibbett wrote:
Hi Scott,
On 28.03.2011 at 15:59, Scott Wilson wrote:
Are there any tests available - even informal ones - for the Widget
Updates[1] spec?
We've just uploaded the Widget Updates test suite to the CVS repository.
The Widgets Updates
getting the UDD
Test ta-processing2-20
I get a content type of text/html when getting the UDD
S
On 26 Apr 2011, at 16:59, Rich Tibbett wrote:
Hi Scott,
On 28.03.2011 at 15:59, Scott Wilson wrote:
Are there any tests available - even informal ones - for the Widget
Updates[1] spec
On 8 Apr 2011, at 09:42, Charles McCathieNevile wrote:
Hi,
I just realised that I actually localise my own name in certain languages
(most particularly to ensure that I get my preferred transliterations when I
am publishing). But I cannot do that in config.xml. Likewise, I would like to
- this is fine as the browser treats no-direction as
LTR by default anyway.
Not a big problem to work around, but it did trip me up and does seem
inconsistent.
On 4 Apr 2011, at 10:57, Scott Wilson wrote:
I'm having problems passing test i18nlro06 for the Widget Interface test
suite [1].
The test
Hi everyone,
Are there any tests available - even informal ones - for the Widget Updates[1]
spec?
Cheers,
S
[1] http://www.w3.org/TR/widgets-updates/
Hi Dom,
This is really helpful - thanks for making this!
(I'm also working on some EU research projects, and I keep mentioning W3C specs
which no-one else has heard of, so this is a good resource to point researchers
and developers at.)
I think a 3-monthly update would also be worth doing
On 8 Feb 2011, at 18:48, Marcos Caceres wrote:
Hi Tim,
In [1], it sounds to me like you are after W3C Widgets [2]; we have almost
finished standardizing them so no need to wait.
You might also find this post useful:
I really like the Kill Switch/EOL idea and having a type attribute to specify
it, but I'm concerned that the Patch type could be a bit more problematic to
get consistently implemented.
On 6 Feb 2011, at 17:15, Marcos Caceres wrote:
Opera would like to discuss adding the following attribute to
On 7 Feb 2011, at 14:22, Marcos Caceres wrote:
On Mon, Feb 7, 2011 at 1:46 PM, Scott Wilson
scott.bradley.wil...@gmail.com wrote:
I really like the Kill Switch/EOL idea and having a type attribute to
specify it, but I'm concerned that the Patch type could be a bit more
problematic to get
On 19 Jan 2011, at 18:39, Marcos Caceres wrote:
On 1/17/11 1:56 PM, Robin Berjon wrote:
On Jan 11, 2011, at 08:24 , Marcos Caceres wrote:
On 1/10/11 4:28 PM, Robin Berjon wrote:
I would argue that it's not particularly complicated to implement,
and we are seeing it used in Opera extensions:
We've come across an issue with storage keys in Widget preferences; namely that
the Web Storage spec [1] states that:
Keys are strings. Any string (including the empty string) is a valid key.
Values can be any data type supported by the structured clone algorithm.
However, common guidance on
On 15 Dec 2010, at 15:50, Tab Atkins Jr. wrote:
On Wed, Dec 15, 2010 at 5:29 AM, Scott Wilson
scott.bradley.wil...@gmail.com wrote:
We've come across an issue with storage keys in Widget preferences; namely
that the Web Storage spec [1] states that:
Keys are strings. Any string (including
I've identified a few more possible test bugs. If there are no objections I'll
make the changes I've suggested below and commit them.
1. i18nrl20.wgt Tests that nested LRO and RTL directions apply correctly to the
name element. To pass, the displayed value of the name element must render as
# i18nlro30 (download, files)
Tests that LRO direction does not apply to the feature element's required
attribute. To pass, the value of the required attribute must be treated as
false.
The actual feature is:
feature name=feature:x-bugus-feature required=false dir=rtl/
So as the feature
See:
http://dev.w3.org/2006/waf/widgets/test-suite/test-cases/i18n-lro/001/i18nlro01.wgt
This is pretty obviously not what should be in here!
S
smime.p7s
Description: S/MIME cryptographic signature
On 3 Dec 2010, at 16:28, Marcos Caceres wrote:
On Fri, Dec 3, 2010 at 12:05 PM, Scott Wilson
scott.bradley.wil...@gmail.com wrote:
# i18nlro30 (download, files)
Tests that LRO direction does not apply to the feature element's required
attribute. To pass, the value of the required
On 3 Dec 2010, at 16:54, Marcos Caceres wrote:
On 12/3/10 5:38 PM, Scott Wilson wrote:
On 3 Dec 2010, at 16:28, Marcos Caceres wrote:
On Fri, Dec 3, 2010 at 12:05 PM, Scott Wilson
scott.bradley.wil...@gmail.com wrote:
# i18nlro30 (download, files)
Tests that LRO direction does
# dl (download, files) Expected: invalid
Test the ability of the UA to verify a zip archive. To pass, the user agent
must treat this as an invalid widget (archive is encrypted - password is test).
The download is just a regular zip archive and isn't encrypted.
smime.p7s
Description: S/MIME
Tests bd,be,bf for assertion ta-DwhJBIJRQN seem to have gone - have these been
removed from the test suite or been renamed?
smime.p7s
Description: S/MIME cryptographic signature
# bm (download, files)
Tests the UA's ability to deal with custom icon declaration in the config
document and matching default icons. To pass, the icons list must contain a
pointer to locales/en/icon.jpg, and icon.png, which is at the root of the
widget. The icons list can be in any order, so
# bn (download, files)
Tests the UA's ability to deal with custom icon declarations in the config
document and matching default icons. To pass, the icons list must contain a
pointer to icons/pass.png, and locales/en/icon.jpg (ordering of the items
in the list is irrelevant).
The actual icons
# viewh (download, files)
Test the UA's ability process a viewmodes attribute containing supported and
unsupported values. To pass, the viewmodes list should be windowed maximized
if the UA supports all of these.
The widget itself contains viewmodes=windowed not-supported floating - so a
# hg (download, files)
Tests that the UA processes an access element with a valid origin. To pass, the
access list must contain a single entry where the scheme is http, the host is
w3.org, the port is 80, and subdomains is false.
The origin contains a trailing slash, which is treated as path
(NB changed subject prefix to [Embedding] as per Art's suggestion)
On 26 Nov 2010, at 18:37, Peter Dekkers wrote:
First of all, thanks to everyone replying and providing useful background to
this first time poster. I did go through the provided links of the past
threads and the different
On 26 Nov 2010, at 07:34, Peter Dekkers wrote:
I've been developing a platform for running multiple types of widgets in
regular web pages and of course support for the W3C widgets should not be
missing. A very nice specification. I especially like the fact that the
deployment unit contains
Hi Bryan,
We've looked at this in Apache Wookie, which does use Widgets in a
browser/webserver context. The general approach we've been discussing is
similar to how Apache Shindig handles oAuth - to put the oAuth logic within the
framework itself rather than in the Widget. So these issues
I've just had a look at this:
https://apps.mozillalabs.com/
In some respects this is very much what we are aiming for (apps using
HTML+JS+CSS) however it proposes a new proprietary app manifest format for
Widgets that is almost identical to PC, plus an auto-update spec (that isn't
Widget
On 20 Oct 2010, at 19:40, Mike Hanson wrote:
Hi there -
I can speak for the technical aspects of the Apps project and relay feedback
as needed.
We had looked at the Widget Packaging spec earlier in the project and had
steered away from it because we were focused on the in-browser/live
Actually, just to totally contradict myself, we implemented the locale
attribute of the Widget interface and forget to take it out again when it was
removed from the spec :-)
On 30 Sep 2010, at 20:37, Scott Wilson wrote:
On 30 Sep 2010, at 16:51, Phillips, Addison wrote:
Hi Art,
No, I
On 30 Sep 2010, at 16:51, Phillips, Addison wrote:
Hi Art,
No, I don't think it does. While the means by which the (user/system default)
locale is determined may be implementation dependent, it is still necessary
that the runtime determine what it is. The Widget interface thus needs to
I've been having a go at implementing the various i18n test cases in Apache
Wookie. I'm planning on processing them in two ways:
1. For the parser, checking the correct values are being persisted for text
direction, both for the element's dir attributes where allowed, and also that
span
On 17 Sep 2010, at 01:30, Marcos Caceres wrote:
Hi Nathan,
There are many applications that are currently stuck using a server
because there is no clear path to deploying 100% client side
applications, examples include micro-blogging clients, note/task-pads,
image editors, contact
- even manually copying it into a HTML file with the div attribute in every
combination and opening in every browser I've got (including Opera ;-) has the
same result!
On 5 Sep 2010, at 23:24, Marcos Caceres wrote:
On 9/4/10 4:54 PM, Scott Wilson wrote:
I'm also getting a Zip file error
:25 PM, Scott Wilson wrote:
To be honest I've been having problems with the i18n test cases
generally. For example:
Tests that LRO direction applies to the name element. To pass, the
displayed value must render as םפללחק.
I can't get the text in that config.xml to show as anything other
I'm also getting a Zip file error on the i18n-039 040 sets (these are the
only ones I've implemented so far):
java.util.zip.ZipException: oversubscribed dynamic bit lengths tree
They seemed to work OK earlier on yesterday, but seem to have become recently
corrupted. (They won't unzip using
Test DR appears to be incorrect:
Test the UA's ability to handle a feature element without a name attribute. To
pass, the feature list must contain one feature named 'feature:a9bb79c1' whose
required value is false.
The test widget contains the following config.xml:
widget
On 16 Aug 2010, at 21:29, Bernard Traversat wrote:
On 8/16/10 2:34 AM, Rich Tibbett wrote:
On 14/08/2010 03:12, Bernard Traversat wrote:
Should we have a more explicit way to specify and notify users that some
updates may require data conversion and
user data will be converted after the
On 30 Jun 2010, at 14:30, Marcos Caceres wrote:
I've evaluated the discussions in this thread and am strongly leaning
towards proposing we drop openURL() from the specification on privacy
and security grounds.
Although I can think of cases where it might be useful to have a
widget
Hi Christoph,
On 17 Jun 2010, at 14:26, Christoph Storm wrote:
Hi,
I am currently very busy reading your papers about W3C Widgets because I am
writing my master thesis about Widgets. The title is Device interoperable
data visualization using standard W3C Widgets - the important word is
On 11 May 2010, at 15:58, Marcos Caceres wrote:
On Tue, May 11, 2010 at 3:55 PM, Scott Wilson
scott.bradley.wil...@gmail.com wrote:
Hi Marcos,
I'll make a start on tests for the assertions about correctly processing the
element (6-13).
I've checked in tests for ta-6 through ta-9.
I'm
On 5 May 2010, at 10:40, Robin Berjon wrote:
On May 4, 2010, at 19:29 , Scott Wilson wrote:
I've just been reading through the WARP spec again, and in particular this
stood out:
In the default policy, a user agent must deny access to network resources
external to the widget by default
I've just been reading through the WARP spec again, and in particular this
stood out:
In the default policy, a user agent must deny access to network resources
external to the widget by default, whether this access is requested through
APIs (e.g. XMLHttpRequest) or through markup (e.g. iframe,
On 2 Mar 2010, at 11:28, Marcos Caceres wrote:
On 1/03/10 11:47 PM, Phillips, Addison wrote:
Thanks Addison - and yes, I think this makes a lot of sense for a
content-style spec like HTML, however as the Widgets PC is a
configuration document most of which is IRIs, integers and so on
rather
Hi Marcos,
On 26 Feb 2010, at 17:44, Marcos Caceres wrote:
Hi i18n WG,
I've added the dir attribute and span elements to the Widgets PC
Specification, as well as a bunch of examples (which are wrong, so I
would really appreciate some help with these!).
The dir attribute is specified here:
-- Lab126
Internationalization is not a feature.
It is an architecture.
-Original Message-
From: public-i18n-core-requ...@w3.org [mailto:public-i18n-core-
requ...@w3.org] On Behalf Of Scott Wilson
Sent: Monday, March 01, 2010 9:44 AM
To: marc...@opera.com
Cc: public-webapps; public-i18n-c...@w3
On 22 Feb 2010, at 18:11, Marcos Caceres wrote:
Dear i18n core,
I'm writing on behalf of the Web Apps WG about the possibility of
conducting a joint teleconference to discuss some issues with the
ITS [1] features in the Widgets 1.0 Family of Specifications.
Basically, we would like to
On 18 Feb 2010, at 21:52, Arve Bersvendsen wrote:
On Thu, 18 Feb 2010 22:09:00 +0100, Scott Wilson scott.bradley.wil...@gmail.com
wrote:
Hi both,
Apache Wookie (incubating) currently implements the widget.openURL
method by directly calling the browser's window.open() function
Hi both,
Apache Wookie (incubating) currently implements the widget.openURL
method by directly calling the browser's window.open() function - in
this example is there anything particularly special about the fact its
being called by a widget? Should our implementation do anything extra,
On 17 Feb 2010, at 00:19, Harry Halpin wrote:
On 17 Feb 2010, at 00:19, Harry Halpin wrote:
Yes, we over in the Social Web XG would be happy to provide some space
where efforts like this one can be done, in particular a Social API
requirements telecon and e-mail discussion with WebApps would
.org/2009/dap/contacts/
Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
Scott Wilson wrote (on 2/12/10 5:39 PM):
Specifically I'm thinking of access to friends/friends-of lists from
author scripts in a Widget runtime. This is something of interest to
widget developers
for doing this in Webapps and work instead with the Social Web group
as you suggest.
Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
Scott Wilson wrote (on 2/13/10 5:21 AM):
Hi Doug,
I'm not adamant that these requirements are met specifically just for
Widgets, just
On 11 Feb 2010, at 01:10, Jonas Sicking wrote:
I don't disagree with you on the implementation side (and Im happy
to hear
that you think it can be implemented - I'll keep my fingers
crossed). On the
author side, I honestly don't know how much of a difference it will
make.
I'm sure someone
On 11 Feb 2010, at 13:08, Arthur Barstow wrote:
On Feb 11, 2010, at 5:32 AM, ext Robin Berjon wrote:
On Feb 11, 2010, at 05:40 , Doug Schepers wrote:
Scott Wilson wrote (on 2/9/10 10:32 AM):
There are a couple of additional areas it would be useful to
consider
for future work
On 9 Feb 2010, at 09:22, Marcos Caceres wrote:
On Tue, Feb 9, 2010 at 9:54 AM, Cyril Concolato cyril.concol...@enst.fr
wrote:
Le 08/02/2010 13:29, Robin Berjon a écrit :
On Feb 5, 2010, at 16:18 , Marcos Caceres wrote:
On Thu, Feb 4, 2010 at 6:41 PM, Cyril
On 9 Feb 2010, at 12:49, Robin Berjon wrote:
Hi Cyril,
On Feb 9, 2010, at 09:52 , Cyril Concolato wrote:
Le 08/02/2010 13:26, Robin Berjon a écrit :
I'm not sure what you mean? The preference storage should remain
available across instantiations of the widget. This could probably
be
/2010/webapps/charter/Overview.html
Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
/-/-/-/-/-/
Scott Wilson
Apache Wookie: http://incubator.apache.org/projects/wookie.html
scott.bradley.wil...@gmail.com
http://www.cetis.ac.uk/members/scott
smime.p7s
Description: S/MIME
Hi everyone,
Just a quick heads up that I've checked in some fixes to bugs in the
Widget Interface test cases in CVS.
I also noticed an issue with the WebIDL test case that I wasn't
willing to dive into as I believe it is auto-generated from the
documentation (?) - this is a
Hi Marcos,
I think this is a really good piece of work - I'll be pointing a few
people from other spec orgs at the draft as its addressing a common
requirement.
(As an implementer I found the approach - especially the
implementation reports - really useful and easy to follow in
Hi Marcos Dominique (and other widsters),
I've been implementing our semi-automated testing of Apache Wookie[1]
for TWI[2], and have spotted a few errors in the test cases[3] you may
want to fix:
za: URL of widget is incorrect; it should be
On 6 Jan 2010, at 08:56, Cyril Concolato wrote:
[snip] 1 fails because we don't implement SNIFF. I don't know if we
will. [snip]
Actually you don't need to implement SNIFF to pass that particular
test, as it only requires you do the extension-processing part of the
algorithm.
See,
On 6 Jan 2010, at 10:08, Cyril Concolato wrote:
I think you misunderstood me.
There is a difference between an 'unsupported'/'unavailable' feature
as 'foo:bar' in your example and an 'invalid feature name' as in the
test-suite example:
widget
named4/name
feature name=invalid feature IRI
On 6 Jan 2010, at 12:09, Cyril Concolato wrote:
Le 06/01/2010 11:22, Scott Wilson a écrit :
On 6 Jan 2010, at 08:56, Cyril Concolato wrote:
[snip] 1 fails because we don't implement SNIFF. I don't know if we
will. [snip]
Actually you don't need to implement SNIFF to pass that particular
Test cases e5, e6, z1 and z2 test the ability of a UA to use a widget-
specified charset (ISO 8859-1); however the PC specification states
that a UA only has to implement UTF-8, and support for additional
encodings is optional.
Do these test cases then really only require that a UA
I've finally narrowed it down to just one test case to pass PC
conformance!
Unfortunately it involves implementing SNIFF...
Does anyone know of an implementation already existing in Java?
S
/-/-/-/-/-/
Scott Wilson
Apache Wookie: http://incubator.apache.org/projects/wookie.html
On 9 Dec 2009, at 23:34, Marcos Caceres wrote:
On Wed, Dec 9, 2009 at 2:46 PM, Robin Berjon ro...@berjon.com wrote:
On Dec 9, 2009, at 14:31 , Cyril Concolato wrote:
Actually, I have a problem with the way the test suite result are
expressed. Since there is no normative algorithm for the
1 - 100 of 155 matches
Mail list logo
