Re: Call for Consensus - Selectors API to Candidate Rec
On Thu, 05 Feb 2009 01:21:09 +0100, Charles McCathieNevile cha...@opera.com wrote: Hi folks, this is a call for consensus to move the Selectors API [1] to Candidate Recommendation, Opera supports publishing this spec as a CR - and if we can get a test suite and interop report in time, in going for a PR straight away. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
RE: Reminder: January 31 comment deadline for LCWD of Widgets 1.0: Packaging Configuration spec
Hi Marcos, Many thanks for the thorough feedback - I'm glad the comments were useful. Some quick responses below for the editorial comments (marked [mp]). I will address your other comments in the next couple of days. Thanks again, Mark --- 6 Widget Resources First 5 bullets should say and/or rather than or ? Zero and/or more sounds weird to me (i.e., Zero and more). If you feel strongly about this, I will change it; otherwise, I would prefer to leave it as is. [mp] Sorry my comment wasn't clear - I meant the second or in the sentence ;) For example: One or more start files, located at the root of the widget insertand//insert or in localized folders. Not a big thing so I'll leave it to your discretion. --- 6.5 Content Localization The container for localized content is a folder at the root of the widget whose the first five characters of the folder-name case insensitively match the string 'locales/'. Why the first five characters only? That was a mistake, the sentence now reads: The container for localized content is a folder at the root of the widget whose folder-name case insensitively match the string 'locales/'. A container for localized content may contain zero or more localized folders. Also sentence has an extra the in the middle, i.e. whose *the* first fixed. [mp] Great - thanks --- 6.6 Start file and Default Start Files Sentence For consistency with other sections I suggest to add: A default start file is a start file whose file-name case insensitively matches a file-name given in the first column of the default start files below and whose MIME type matches the MIME type given in the second column of the table. before the sentence starting: A default start file is a start file that a widget user agent... Ok, I think there was a more significant problem: I've defined custom start files and default start files. As a result, I changed that whole section. And then to combine the last two sentences before the default start files table to: A widget user agent will attempt to locate a file entry whose file-name case insensitively matches one of the default start files based on the order they appear in the table below (from top to bottom). Can you please check that section again and let me know if the rewrite is ok? [mp] Looks good to me - thanks --- 7.1 Namespace It seems a bit tough that an invalid configuration document results in a invalid widget as the configuration document is optional. Also, if the configuration document in the localised folder is invalid, it could be the case that there is a valid configuration document at the root of the widget. I don't have a strong opinion on this and have no objection to leaving the text as it is, I just wondered if there was a reason why this approach had been taken? Although I agree that it's a bit cruel on developers, we made this decision to make the behaviour of configuration documents predictable. I feel pretty strongly that we should leave it as is. [mp] Fine for me --- 7.2 Proprietary Extensions Should the may be a should? Otherwise, it could be interpreted as suggesting that vendors may equally use other approaches? Right, fixed. This should, in fact, be a must (i.e., if you want to extend, then you must use your own namespace). [mp] Agree and thanks --- 7.9 The icon Element (disclaimer - I may well be talking rubbish here as the following comments are based on a _very_ basic understanding of graphics formats) The text says that if the icon is vector format then the height and width attributes will be used, however, isn't one the point of using vector graphics that they could be re-sized to fit the available space. Yes and no. Beyond certain sizes (e.g., too little, too big), the rendering engine may have undesirable effects on a design (think, for example, of a really tiny font having anti-alias applied to it: because of sub-pixel interpolation, it becomes too blurry to read. The same can happen with graphics, very thin lines can vanish or become blurry, which can make a design look crappy). In such cases, it may be desirable to use a bitmap. [mp] OK, I understand this point but... see next response Therefore shouldn't there be a statement saying that the widget user agent MAY ignore these values? No, the width and height attributes represent the _minimum_ size at which an image may be used. Then, the vector graphic can behave in the manner you describe (i.e., can be used to fill a rendering context larger than the width and height). [mp] Hmm, in this case shouldn't the spec explicitly state that these are minimum height and widths for vector graphics and that the widget user
Re: Required support for SVG in widgets
On Feb 4, 2009, at 20:05 , Marcos Caceres wrote: Yep. But like Charles said, it should be the other way around: Bondi specs should be brought to the W3C for standardization once they are ready. If the specs are done, implemented, and have an associated test-suite, then standardization through the W3C should be a breeze, right? The W3C doesn't do rubber-stamping. If OMTP wants to have their specs be Recs they will need to have them go through the process, and that means that changes to them are possible. Given that, if they really want W3C to integrate their APIs they should submit earlier than when they're ready. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: Call for Consensus - Selectors API to Candidate Rec
On Thu, 05 Feb 2009 01:21:09 +0100, Charles McCathieNevile cha...@opera.com wrote: Hi folks, this is a call for consensus to move the Selectors API [1] to Candidate Recommendation, following the end of the last call. [1] http://dev.w3.org/2006/webapi/selectors-api/ One minor fix: s/and to be/to be/. Otherwise, looks good. kats
Re: Required support for SVG in widgets
Apologies for entering thread late. To clarify: BONDI work would have been introduced to W3C activity earlier in the process, however, we have been fighting the internal (and cross organisational) processes surrounding IPR regimes. This is now fully clarified - and formal inputs will be made imminently, with the necessary RF commitments. From BONDI side - there is no expectation of rubber stamping within W3C - and full expectation that we adhere to due process and consensus building. We will of course give all the collective support we can towards the process - after all the market is moving very rapidly ahead, and fragmentation risk increasing by the day. Nick Allott Chief Technology Officer OMTP - BONDI On Feb 4, 2009, at 20:05 , Marcos Caceres wrote: Yep. But like Charles said, it should be the other way around: Bondi specs should be brought to the W3C for standardization once they are ready. If the specs are done, implemented, and have an associated test-suite, then standardization through the W3C should be a breeze, right? The W3C doesn't do rubber-stamping. If OMTP wants to have their specs be Recs they will need to have them go through the process, and that means that changes to them are possible. Given that, if they really want W3C to integrate their APIs they should submit earlier than when they're ready. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/
Re: Required support for SVG in widgets
On Thu, Feb 5, 2009 at 3:03 PM, Robin Berjon ro...@berjon.com wrote: On Feb 4, 2009, at 20:05 , Marcos Caceres wrote: Yep. But like Charles said, it should be the other way around: Bondi specs should be brought to the W3C for standardization once they are ready. If the specs are done, implemented, and have an associated test-suite, then standardization through the W3C should be a breeze, right? The W3C doesn't do rubber-stamping. If OMTP wants to have their specs be Recs they will need to have them go through the process, and that means that changes to them are possible. Given that, if they really want W3C to integrate their APIs they should submit earlier than when they're ready. Sorry, I didn't mean to imply any rubber-stamping on the part of the W3C. In fact, I was being little sarcastic :) Anyway, we are getting off topic. -- Marcos Caceres http://datadriven.com.au
Fwd: Security for Access to Device APIs from the Web: Workshop Report Published
Begin forwarded message: From: ext Ian Jacobs i...@w3.org Date: February 5, 2009 3:05:02 PM EST To: public-device-a...@w3.org public-device-a...@w3.org Subject: Security for Access to Device APIs from the Web: Workshop Report Published Archived-At: http://www.w3.org/mid/7ED788B1-500D-4875-BFDB- b542f8ada...@w3.org Hello, The report from the recent W3C Workshop Security for Access to Device APIs from the Web [1] is now available: http://www.w3.org/2008/security-ws/report Participants identified the following areas of possible work as high priorities for the W3C: - Declaration of APIs - Policy Description for device APIs - API patterns and standardization of concrete APIs While some of this work likely fits into the charters of existing Working Groups, the policy description item would likely require a new work effort. We have set up the public-device-a...@w3.org mailing list (archive [2]) for follow-up discussion. You may also wish to consult the position papers received: http://www.w3.org/2008/security-ws/papers/ If you have any questions, please contact Thomas Roessler t...@w3.org. Thank you, Ian Jacobs, Head of W3C Communications [1] http://www.w3.org/2008/security-ws/ [2] http://lists.w3.org/Archives/Public/public-device-apis/ -- Ian Jacobs (i...@w3.org)http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447
Re: CfC to publish Errata for Element Traversal Recommendation; deadline February 2
On Mon, 26 Jan 2009 10:07:08 -0500, Arthur Barstow art.bars...@nokia.com wrote: WebApps WG Members - this is a Call for Consensus (CfC) to publish the Element Traversal errata as proposed by Cameron: http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/ 0168.html As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. The deadline for comments is Feb 2. -Regards, Art Barstow I just noticed that the java binding file has a link to ww.w3.org instead of www.w3.org. Cheers, kats
Re: CfC to publish Errata for Element Traversal Recommendation; deadline February 2
Hi Kartikaya. Kartikaya Gupta: I just noticed that the java binding file has a link to ww.w3.org instead of www.w3.org. Well spotted! I committed an updated ElementTraversal-java-binding.zip file. Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Re: Call for Consensus - Selectors API to Candidate Rec
So do I, and most likely the rest of mozilla. / Jonas On Thu, Feb 5, 2009 at 4:55 AM, Charles McCathieNevile cha...@opera.com wrote: On Thu, 05 Feb 2009 01:21:09 +0100, Charles McCathieNevile cha...@opera.com wrote: Hi folks, this is a call for consensus to move the Selectors API [1] to Candidate Recommendation, Opera supports publishing this spec as a CR - and if we can get a test suite and interop report in time, in going for a PR straight away. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Call for Consensus - Selectors API to Candidate Rec
Charles McCathieNevile: this is a call for consensus to move the Selectors API [1] to Candidate Recommendation, following the end of the last call. +1 -- Cameron McCormack ≝ http://mcc.id.au/
