Widgets 1.0: Packaging and Configuration LCWD review
Dear Marcos and WG,
Here follows my set of remarks on Widgets 1.0: Packaging and Configuration
which I hope you'll find valuable during LC review. It's based on the 17th June
Editor's Draft.
http://www.w3.org/TR/2009/WD-widgets-??/
Error 404. TBD in place of IRI would be better.
Latest Editor's draft:
In other places the word draft is also capitalized.
Marcos Cáceres
This remark is positive: nice to see the name spelled correctly. (Some WGs and
the server at lists.w3.org have problems with mine.)
a class of software application
Was plural intended?
while processing the packaging format, configuration document, and other
relevant files
I can accept that the non-webby notion of files is used in the Zip spec and as
such adequate for what's contained in Zip archives. But, as we have already
discussed, for other uses please write resources.
Rich Web Clients Activity
This is not an issue of the document itself, but worth mentioning, especially
since it's your Activity. The W3C site uses inconsistent naming: sometimes it's
Clients and in other places Client. Be sure to pick the correct one.
1 Introduction
Is the text before 1.1 normative?
While a conforming user agent may support other legacy/proprietary widget
types in order to conform to this specification, a user agent must treat
widget packages as according to this specification.
I find this sentence unclear.
The magic numbers for a Zip archive is the byte sequence
Aren't those officially called octets?
other compression formats will cause the widget package to be treated as an
invalid Zip archive.
In the context of definitions present in the document this would effectively
render the OPTIONAL (so says 3.1) support for other compression formats
useless. As an authoring guideline, this text isn't normative, so if included
in the final spec, should be considered false. Of course false statements are
to be avoided.
If a CC encounters a compression method that is not one of the valid
compression methods,then the CC must inform the author that the Zip archive
is an invalid Zip archive.
This, on the other hand, is normative. So the problem is serious. I suggest
lowering this to a warning by CC that user agents will be allowed to treat the
Zip archive as invalid.
For the sake of comparison and matching, it is recommended that a user agent
internally treats all Zip-relative paths as [UTF-8].
What does internally treats mean? Is there a risk of violating Charmod, or
are Zip archive internals believed to be out of its scope?
cp437-chars
This nonterminal seems undefined.
If the widget package does not contain a start file, or the start file is not
one that is supported by a particular user agent, then the CC must inform the
author.
How can a CC have knowledge of all user agents? Or do you mean a CC is a user
agent (indeed, in general terminology, but this term has been narrowed for this
spec in 2)?
then Make sure that the widget is labeled
Typo.
Failure to correctly label a widget package will result in it being treated
as an invalid Zip archive.
Only if it's first considered to be a potential Zip archive. A generic user
agent may process other resources (e.g. image/svg+xml) and only defer to its
subcomponent that implements widget specs on encountering application/widget.
If it is anticipated that the widget will be distributed by non-HTTP means,
then include the widget file extension.
Replace non-HTTP means by means lacking MIME support.
Author Guidelines:
In other places it's
Authoring guideline:.
Example of recommended version tags:
They don't belong to the language generated by {rec-version-tag}.
A URI attribute that represents a link that is associated with the author
(e.g. the homepage of the author). It is optional for authors to use this
attribute.
This really should be specified as the URI of the author himself. Nowadays
still many authors will probably just point to their homepages, but
semantically mean themselves, which they'll be able to make explicit at the
time they decide they want to, using the techniques described in
http://www.w3.org/TR/cooluris/.
If the file pointed to by the src attribute is of a vector graphic format,
then this value must be used.
Why? Vector formats may include preferred sizes specified. Even if not, some
environments require specific sizes and it should be assumed that whatever else
is specified, will be scaled. In case of vector graphics without intrinsic
dimensions I believe it's the environment's responsibility to apply a
reasonable default.
The its:dir attribute and the its:span element may each be used as a child
What data model are you using to call attributes children?
such as en-us, en-gb, and so on
Canonical spelling is en-US, en-GB, and so on. Do you intend to require
deviating from it?
However, widget packages localized at any folder level (e.g. locales/zh/)
needs to be fully functional as a localized widget.
Handling too few arguments in method calls
From some very brief testing, it seems that Firefox and Opera tend
to throw an exception when calling a method with too few arguments,
while IE, Safari and Chrome will assume that the missing arguments were
the undefined value. Extra arguments tend to be ignored.
Does anyone have an opinion on which way this should be specified in Web
IDL? Assuming this interface:
interface A {
/* f1 */ void f(in DOMString a);
/* f2 */ void f(in DOMString a, in float b);
/* f3 */ void f(in DOMString a, in float b, in float c, in float d);
};
option 1 would be to have:
a.f() be like calling f1 with (undefined)
a.f('a') be like calling f1 with ('a')
a.f('a', 1) be like calling f2 with ('a', 1)
a.f('a', 2, 3) be like calling f3 with ('a', 2, 3, undefined)
a.f('a', 2, 3, 4, 5) be like calling f3 with ('a', 2, 3, 4)
and option 2 would be to have:
a.f() throw an exception
a.f('a') be like calling f1 with ('a')
a.f('a', 1) be like calling f2 with ('a', 1)
a.f('a', 2, 3) throw an exception
a.f('a', 2, 3, 4, 5) be like calling f3 with ('a', 2, 3, 4)
Web IDL currently says to throw on any incorrect number of arguments,
so it seems that it should change to be one of the above two options.
Thanks,
Cameron
--
Cameron McCormack ≝ http://mcc.id.au/
Re: [PrototypeRoot]
On Sat, Jun 20, 2009 at 12:43 AM, Ian Hicksoni...@hixie.ch wrote: On Sat, 20 Jun 2009, Garrett Smith wrote: I still want to know: Why would a program want to know the object's [[Class]]? It shouldn't, but [[Class]]es are exposed by ECMAScript objects in their toString() method and thus if we want to ensure universally consistent behaviour we have to define this. No, that is all untrue. The [[Class]] property is exposed in Object.prototype.toString. Ensuring universally consistent behavior would require that *all browsers* behave exactly the same. MSIE does not behave that way today and versions of other browsers may vary, too. To ensure safer, more reliable behavior, define the [[Class]] property as being a string value. That way, it would be guaranteed that Object.prototype.toString.call( any_object ); would result in string value being produced, and an error would not occur. The value of that string should be implementation-dependent. This makes the feature flexible, extensible, and provides the aforementioned benefits of interfaces over classes (e.g. mixin style behavior with implementation-specific host objects). Providing a suggestion to implementors as to what that value might be would be harmless. Mandating the *value* of that [[Class]] property creates a brittle, fragile API. Authors will utilize the specification to write code to that value to create code that is as brittle and fragile as the API it uses and works in fewer implementations, including browsers that are in widespread use today. Even if a program could know the [[Class]], what's to say it won't change in the future? The specs we write. No, the specifications do change. The introduction of HTMLFormControls collection, for example, was a new one. There is a possibility of a StaticNodeList or HTMLLinks collection in the future. The interfaces implemented by an object vary between implementations and evolve over time. Given a particular object, can that object's [[Class]] property change in the future? If it there is an object that exists, say, some sort of HTMLCollection, and it becomes desirable to make more specific behavior, say HTMLFormControlsCollection, what would the code that expects the object's class to be HTMLCollection need to do to continue working in multiple versions of multiple browsers? We would have to test to see if any pages rely on it; if they do, we'd have to make sure we don't change the [[Class]] somehow. That sounds like a brittle feature. An object's [[Class]] feature should ideally provide specific, detailed information, and should be used *only* in debugging. Never rely on it. Given all these reasons, it would still seem like a bad idea to program to an object's [[Class]]. Instead, the interface should be programmed tot using feature detection. Yup. OK. Strings are not a substitute for capability checks. The [[Class]] in particular has very little potential to return information about what an object can do. It would be a very risky design decision to make inferences solely on the [[Class]] value. We seem to be eye to eye on that much but I think the API design has gone too far. Defining the value of the [[Class]] encourages that value to be used in code. That is bad! Programmers who rely on that value will not rightly blame themselves for their design mistakes. Instead, they will look externally, read the standard, and blame the implementations that don't do what their perfectly standards-compliant program expects Garrett
Re: Input events, checkboxes and radio buttons
On Sun, 21 Jun 2009 03:40:10 +0200, Michael A. Puls II shadow2...@gmail.com wrote: On Sat, 20 Jun 2009 06:35:16 -0400, Anne van Kesteren ann...@opera.com wrote: The input event does not apply to radio/checkbox. (This is stated in the radio/checkbox sectons.) Are you sure? I'm sure about what the specification says there, yes. The table under http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#the-input-element (scroll down a bit) shows yes for the input event under the radio/checkbox column. Seems that table is buggy. (Or they do dispatch and then the normative part of the specification is buggy.) -- Anne van Kesteren http://annevankesteren.nl/
