- From: Marcos Caceres <m.caceres@qut.edu.au>
- Date: Mon, 13 Nov 2006 13:21:08 +1000
- To: Gorm Haug Eriksen <gormer@opera.com>
- CC: Ed Voas <voas@yahoo-inc.com>, public-appformats@w3.org
Gorm Haug Eriksen wrote: > > On Fri, 10 Nov 2006 06:44:23 +0100, Marcos Caceres > <m.caceres@qut.edu.au> wrote: > >> I also agree with Ed in relation to the root node maybe being called >> something other than <widget> (for the sake of accommodating all >> vendors). Some alternative names off the top of my head: >> >> * <application>, or >> * <component>, or >> * <about>, or >> * <manifest>, or >> * <metadata>, or >> * <configuration> >> >> Anyone else got any suggestions? > > Yea, widget isn't a good name. Perhaps <config> since the file is > called config.xml? I also kinda like config; it's easy to remember... but we will continue to look at all possible name options for this element. >> Given that the Widgets 1.0 is based on Opera's config format for >> their widgets, I cannot comment as to why or how Opera uses <width> >> and <height>. > They are used for the initial width and height of the window. > Personally, I think we should have used CSS styling to determine > aspect. I agree with Ed that it shouldn't be part of the format. I also agree. But I would like to investigate this further, particularly with Opera's widgets. It would be interesting to see if the defined widths and heights of Opera widgets matches the widgets published on-line. I also wonder what happens if you give an incorrect size? does the widget get clipped? And what happens if the widget dynamically grows in size beyond the defined width and height? > Other comments: > > - <widgetname> should be renamed to <name> Agreed that it should be changed. Again, the more suggestions of what this element should be renamed to the better. > - should support multiple authors Agreed. I don't see any harm in supporting multiple authors, even, as Ed pointed out, if there are currently very few examples of widgets having more than one author. > - the security tag should be dropped or reviewed It will be extensively reviewed, but will probably not dropped. The WG is still gathering inputs for this section, so please send more comments. > - should not require that a widget is packaged at the root of the zip > file I think this is already flagged to change. As a separate note, HTML will not be the only UI language supported by the spec. We want the manifest to provide a mechanism to start the application, such as referencing an initial application file to run (which means that the main file does not need to be in the root of the package). This is obviously done to accommodate implementations, such as Yahoo!'s Widget Engine, that don't use HTML to declare the UI. > - The Widget Scripting Interfaces should be dropped or reviewed. In > particular, the geometry methods since this wouldn't make sense on > some widget runners They will be extensively reviewed, but probably not dropped at this point. Need further research into this issue. > - should mention a XML NS for the format If possible, I personally want to avoid namespaces... or at least make the namespaces as unobtrusive as possible. Authors don't like them, vendors don't seem to be using them for widgets, and they add undesirable level of complexity for everyone. Also, one of our design goals for this document is ease of use [1], so we want to make this spec as easy to use as possible (without compromising extensibility and flexibility too much). However, please provide more input as to why XML NS should be mentioned... I'll just say, if we can keep things at this level, I don't think anyone will have massive problems: <widget xmlns="http://www.w3.org/ns/widgets"> > - should mention a strategy for both embedding the config information > inside the widget and reference the config information from the widget Regarding your first point ("strategy for embedding the config information inside the widget"), good idea. Any suggestions? Regarding referencing the config information from inside the widget, the current (limited) defined strategy for referencing the config info is through the API (preferenceForKey, setPreferenceForKey). However, is currently underspecified and we need to develop it further. Marcos
Received on Monday, 13 November 2006 03:21:46 UTC