[widgets] MWBP WG Comments of Widgets Reqs LC WD, was Re: Request for Comments on Widgets 1.0 Requirements Last Call WD
Hi Bryan, MWBP WG, On Fri, Aug 1, 2008 at 12:28 PM, Sullivan, Bryan [EMAIL PROTECTED] wrote: Hi Art, The MWBP WG consolidated comments are attached as a HTML document. General comments: Somewhere, perhaps in section 4.2, there should something about how resources (media etc) need to be compatible with the target device types, and that resource dependencies (screen, input device, network, processing, etc.) need to be spelled out. Widgets should be able to express these dependencies in a semantically useful way through a standardized schema and attribute ontologies/vocabularies such as W3C has been working on, e.g. the MWI DDWG's DDR Core Vocabulary, DDR Simple API, and the ongoing work of the UWA's Delivery Context Ontology. Although these are great technologies and I see the value that they could add to Widgets overall, the WebApps Working Group has yet to evaluate the suitability of these specification to Widgets. From our initial investigation, some of these technologies have the potential to significantly complicate widgets as a platform and I am personally concerned that they could become a barrier to the adoption of Widgets. Personally, I would like to see the progressive inclusion of the technologies you mention as they become more prevalent in the mobile space and as developers start asking for them. I am also of the opinion that our primary focus right now (version 1.0 of Widgets) should be on specifying packaging and the core APIs. The specific text below related to expression of user agent characteristics (via the User Agent, Accept, and Profile headers in HTTP requests) is important in the meantime as a standardized way to at least disclose web application (and host device) capabilities, but longer term a way of expressing dependencies is important also. I agree conceptually with what you are saying, though I have concerns about the Profile headers side of things. Re R16 Visual Rendering Dimensions: the text states that there must be a way of declaring initial dimensions in pixels, which is potentially at odds with the limited canvas available on many mobile devices. Resource/capability expression as described above would at least ensure the dimensions were defined in a standardized way. The requirement reads A conforming specification SHOULD specify a means for an author to declare the initial visual dimensions for an instantiated widget in a way that is device independent (e.g. via CSS pixels). The requirement does not actually state that it must be be pixels (CSS pixels are an example), just that some means SHOULD be provided to declare the dimensions. Other that described in R28. Network State Change Events, is there something specific that can be said re requirements supporting widgets that are intermittently connected? The rationale now reads: To allow authors to programmatically capture when the widget user agent has acquired or lost a network connection, particularly for cases when the device intermittently loses and regains the network connection. Suggestions for specific text: 1) As design goals, a new section 3.1 can specifically introduce the mobile web best practices that W3C has developed / is developing. Here is some proposed text: 3.1 W3C Mobile Web Best Practices Some typical use cases for widgets are similar to use cases for mobile Web browsing, and will benefit from consideration of objectives and constraints similar to the mobile environment, e.g. usability, interoperability, and resource efficiency. In particular, widgets that are used in mobile devices should behave well as mobile web applications, i.e. as web applications running in mobile devices. For widgets in mobile devices or similar contexts, widget specifications should take into consideration the W3C recommendations in the Mobile Web Best Practices 1.0 and Mobile Web Application Best Practices, and where possible provide enabling capabilities so that widgets can more consistently comply with the recommendations. I've added the above text to the Widgets 1.0 Landscape document [1], but not the the Requirement's document. To add this text would mean that I would need to add sections for relationship to internationalization and relationship to accessibility etc.. We also want to keep this document as small as possible, which is why we have put all definitions and detailed design justifications into the Landscape document. 2) Add the references: MWBP Mobile Web Best Practices 1.0. J. Rabin, C. McCathieNevile, W3C Recommendation, July 2008. Available at http://www.w3.org/TR/mobile-bp/ MWABP Mobile Web Application Best Practices. B. Sullivan. A. Connors, W3C Working Draft (Recommendation), July 2008. Available at http://www.w3.org/TR/mwabp/ I added the references, and the Current development practice or industry best-practices design goal now reads: A conforming specification needs to consider the development practices currently used by
Re: [WebIDL] ES3.1 'flexible' attribute and 'delete' semantics
On Wed, Aug 13, 2008 at 11:12 AM, Travis Leithead
[EMAIL PROTECTED] wrote:
I appreciate a little friendly competition and bantering,
Who are you competing with?
but I don't think it's appropriate or in the best interest of cooperation for
such personal feelings of animosity to be disclosed in such a public forum.
Having written that, I would like to clarify my poor choice of imprecise
language and restate my question:
It might be a consideration to call it 'poor word choice', but then:
Due to the mechanics of various implementations of the DOM, JavaScript
operators may or may not have the ECMAScript intended behavior when an host
object's 'own' property is changed (assuming the property is 'flexible').
ES3.1 isn't even done. There aren't any implementations of it. How
could a property be flexible ?
Ecma-262 does not have intended behavior for Host objects, does it?
These are strong indications that 'poor word choice' is not the issue
at hand, or at least not the only one. 'poor understanding of relevant
standards' is one explanation. 'Analytical mistakes' could be another.
Why do you want to know how 'delete' operator works with Host object?
It seems like a bad idea to attempt this.
The following code demonstrates the difference between implementations of the
latest WebKit and Opera9.5. Note this is for functions, as I am unsure if
data and/or accessor properties are supposed to be defined on prototypes
in the DOM (seems like they should be, but I can't remember if WebIDL allows
them there or not).
I'm going to explain what your code does with comments annotated (GS).
You haven't stated the expected result of calling test().
What did you think test should do? How does 'test' demonstrate a
problem or supports your argument? (what is your argument?)
You make some very poor assumptions in the code below.
function test()
{
// (GS) This will result in a ReferenceError if document is
// undefined, and an alert if document is false-ish. This branch
// of code will not be executed in any of IE, FF, Webkit, Op.
if (!Document)
{
alert(test cannot be performed on this implementation);
return;
}
// (GS) Should not make assumption that since Document
// exists, it will have a prototype property.
if (!Document.prototype.hasOwnProperty('getElementById'))
{
alert(property not defined at this level);
return;
}
// (GS) Defining a getElementById property of the Document
// object's prototype and assign function value.
// Overright is fictitious terminology, but apparently, to you,
// Overright means replace value.
// Overright the property:
Document.prototype.getElementById = function(x) { return test; };
// Call document.getElementById to see if the method on
// Document.prototype is called.
// Ensure the override was successful:
if (document.getElementById('foo') != test)
{
alert(override failed);
return;
}
// delete the property defined.
// Try to delete it
try { delete Document.prototype.getElementById; }
catch(e) { alert(delete operator failed); }
// Check to see if it was deleted...
if (Document.prototype.getElementById)
{
if (document.getElementById('foo') == test)
alert(delete failed to remove the override);
else
// (GS) getElementById is not a built-in method.
alert(delete failed to remove the built-in method);
}
else
// (GS) Wrong. EcmaScript does not define how delete
// works on a host object.
alert(property was deleted (per ECMAScript rules));
}
Since Firefox 3 implements getElementById on HTMLDocument (DOM L1/HTML)
instead of Document
(DOM L2/Core) you'll have to replace all instances of Document with
HTMLDocument to run the test on that browser.
As this code shows, delete works per ECMAScript in Opera, but not in Safari
or in FF3.
How do you arrive at the conclusion? You used the delete operator with
a Host object. Ecma-262 r3 doesn't define that.
Your code attempts to delete a property on Document.prototype. From
this, it seems you assume that if delete throws an error, it means the
property is non-deletable and if delete does not throw an error, the
property must be deleted.
Checking the return value of delete would probably be the first thing
to do, and would be one test in and of itself.
javascript:alert(delete Document.prototype.getElementById)
Webkit: false
This indicates that Document.prototype.getElementById exists and can't
be deleted. It probably has the [[DontDelete]] attribute and this
would be perfectly valid. It does not mean that the delete operator
doesn't work.
My question, once again, is whether WebIDL will define exactly how to
translate the behavior of operators like delete into the JavaScript language
binding for DOM objects.
That isn't a question. This is: Why does WebIDL need to define how
delete
Re: [WebIDL] ES3.1 'flexible' attribute and 'delete' semantics
Hi Garrett.
Travis Leithead:
My question, once again, is whether WebIDL will define exactly how
to translate the behavior of operators like delete into the
JavaScript language binding for DOM objects.
Garrett Smith:
That isn't a question. This is: Why does WebIDL need to define how
delete works on Document.prototype.getElementById? There is no
guarantee that Document will be an object, or that Document.prototype
will be the [[Prototype]] of document. Nor should there be.
Web IDL wouldn’t specifically say “delete works on
Document.prototype.getElementById”, but I think it should say how these
kinds of objects (Document, Document’s [[Prototype]]) behave, e.g.
“a property on an interface prototype object that corresponds to an IDL
operation has attributes { DontEnum }”. JS libraries do exploit the
prototype chain to add methods etc., so it would be good if they could
do this with the blessing of a spec, rather than de factor behaviour.
Given MS’s interest in following Web IDL, there’s a chance we could get
all four browsers doing the same thing, too.
--
Cameron McCormack ≝ http://mcc.id.au/
Re: [WebIDL] ES3.1 'flexible' attribute and 'delete' semantics
On Thu, Aug 14, 2008 at 6:39 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Aug 14, 2008, at 6:10 PM, Garrett Smith wrote: Document interface is an interface. An interface does not have defined implementation; it is merely a contract. IDL is for Interface Definition. The fact that some browsers expose Document as a global property does not need standardization. It would not be bad to have DOM readonly properties implemented with [[DontDelete]], [[ReadOnly]]. That could be one line in WebIDL, e.g. DOM readonly properties have [[DontDelete]] and [[ReadOnly]]. But it seems fairly obvious that this would have to be so, so it wouldn't seem critical to include that. All of the top four browser vendors would like to have these kinds of details clearly specified and to converge on interoperable behavior. I am not aware of any vendor that specifically wishes to diverge from interoperable behavior. As such, I hope the editor politely declines your requests to leave such things unspecified. what 'such things'? In general, leaving things unspecified does not prevent Web content from relying on them, People will do all sorts of things won't they? Regards, Maciej
Re: [widgets] MWBP WG Comments of Widgets Reqs LC WD, was Re: Request for Comments on Widgets 1.0 Requirements Last Call WD
Hi Bryan, MWBP WG, FYI, we discussed the MWBP input in last nights teleconf: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0417.html In summary, although I had included most of the requirements proposed by the MWBP WG in the Requirements document, the WebApps WG members overrode my decisions and chose not to include your recommended text into Requirements document. I have now removed the text I added earlier (below) from the Requirements document. The main reason for rejecting the feedback was that the proposed requirements were: (a) had limited impact on the actual specs (in normative terms), (b) were overly prescriptive and should really be left as an implementation detail on which implementations can compete, (c) added complexity on either the client side or the server side. If MWBP WG has concerns with the omission of any proposed requirement, we are happy to discuss anything further to reach consensus before we take the Requirements document to CR. Please note that WebApps is on an extremely tight schedule and we intend to move the Requirements to CR within three weeks; so if we don't hear back from MWBP we will assume that you are in agreement with WebApp's decisions. Having said that, I want to say that the feedback from the MWBP WG was extremely useful because it allowed the WebApps WG to more narrowly focus the architectural aspects of the Widgets 1.0 family of specifications. We want to continue coordinate with members of the MWBP WG on architectural decisions and guidance on best practices for widgets and mobile-based client side web applications. Kind regards, Marcos On Thu, Aug 14, 2008 at 7:45 PM, Marcos Caceres [EMAIL PROTECTED] wrote: Hi Bryan, MWBP WG, On Fri, Aug 1, 2008 at 12:28 PM, Sullivan, Bryan [EMAIL PROTECTED] wrote: Hi Art, The MWBP WG consolidated comments are attached as a HTML document. General comments: Somewhere, perhaps in section 4.2, there should something about how resources (media etc) need to be compatible with the target device types, and that resource dependencies (screen, input device, network, processing, etc.) need to be spelled out. Widgets should be able to express these dependencies in a semantically useful way through a standardized schema and attribute ontologies/vocabularies such as W3C has been working on, e.g. the MWI DDWG's DDR Core Vocabulary, DDR Simple API, and the ongoing work of the UWA's Delivery Context Ontology. Although these are great technologies and I see the value that they could add to Widgets overall, the WebApps Working Group has yet to evaluate the suitability of these specification to Widgets. From our initial investigation, some of these technologies have the potential to significantly complicate widgets as a platform and I am personally concerned that they could become a barrier to the adoption of Widgets. Personally, I would like to see the progressive inclusion of the technologies you mention as they become more prevalent in the mobile space and as developers start asking for them. I am also of the opinion that our primary focus right now (version 1.0 of Widgets) should be on specifying packaging and the core APIs. The specific text below related to expression of user agent characteristics (via the User Agent, Accept, and Profile headers in HTTP requests) is important in the meantime as a standardized way to at least disclose web application (and host device) capabilities, but longer term a way of expressing dependencies is important also. I agree conceptually with what you are saying, though I have concerns about the Profile headers side of things. Re R16 Visual Rendering Dimensions: the text states that there must be a way of declaring initial dimensions in pixels, which is potentially at odds with the limited canvas available on many mobile devices. Resource/capability expression as described above would at least ensure the dimensions were defined in a standardized way. The requirement reads A conforming specification SHOULD specify a means for an author to declare the initial visual dimensions for an instantiated widget in a way that is device independent (e.g. via CSS pixels). The requirement does not actually state that it must be be pixels (CSS pixels are an example), just that some means SHOULD be provided to declare the dimensions. Other that described in R28. Network State Change Events, is there something specific that can be said re requirements supporting widgets that are intermittently connected? The rationale now reads: To allow authors to programmatically capture when the widget user agent has acquired or lost a network connection, particularly for cases when the device intermittently loses and regains the network connection. Suggestions for specific text: 1) As design goals, a new section 3.1 can specifically introduce the mobile web best practices that W3C has developed / is developing. Here is some proposed text: 3.1
