Re: Web Notifications, do we need a new spec?
Jeremy Orlow wrote: On Fri, Jul 31, 2009 at 1:52 AM, Marcos Caceres marc...@opera.com mailto:marc...@opera.com wrote: Keeping in line with the design goals to enable Widget-related technologies to be used on the Web, I'm wondering if we should spawn a separate specification for notifications? We could use the current text in the AE [1] as the basis, which is based heavily on what was originally in HTML5 (or just take the old HTML5 text, create the new spec, add the hooks for Widgets). Although notifications have been taken out of HTML5, rumblings that they may need reviving occurred recently on the WHAT-WG list: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/019113.html There was a lot of talk about notifications in this more recent thread as well: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-July/thread.html#21421 (The thread is long and talks about a lot of things besides notifications, but I think there are some key insights in that thread about the requirements for notifications.) I'll take a look and see what I can extract from the discussion. As a followup to the above, the following code was submitted by Google to WebKit to support notifications: https://bugs.webkit.org/show_bug.cgi?id=25463 So, the question is: do we need a new/separate spec? One that covers both Web and Widgets? I think we do need to start thinking about specing this out. Off the top of my head, it seems like the requirements for the web and widgets will be pretty similar. I agree. Lets take notifications out of Widgets API. I think the next action should be to formally start capturing these requirements. If you have time to list some requirements you guys have, that would be great. Kind regards, Marcos
Re: [PC] utf8-char in Zip-rel-path
On Tue, Jul 28, 2009 at 12:04 PM, Marcin Hanclikmarcin.hanc...@access-company.com wrote: Hi Marcos, Unless it's broken (?), I would prefer to leave it as is. I think that PC should either change the grammar (as suggested in my email) or specify that the zip-rel-path operates on characters. The first would be well adjusted to Zip filename encoding in UTF-8 as a kind of natural match, whereas the latter could be clearer wrt the characters that can be used in the path. Anyway, I think some clarification - e.g. on of the above - is required. Thanks. Ok, I see what you mean now. I made the following change in the spec: 1. deleted the PC's ABNF definition of utf8-char. 2. added The utf8-char rule is defined in section 4 of [UTF-8]. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [PC] Low-level internationalization, XML deserialization, IRI or URI, IRI normalization
2009/7/25 Marcin Hanclik marcin.hanc...@access-company.com: Hi Marcos, All, Regarding the usage of IRI in the widget configuration document, I do not know which speicification is responsible for mandating the IRI normalization. It is possible that I simply have not yet found the proper existing explanation to the issue, so if you know it, I would be grateful to get this information. These are more details. The PC spec mixes the targets of the grammars (or low-level format specifications) it operates on. E.g. the sections about Zip archive operate on bytes http://www.w3.org/TR/widgets/#zip-archive http://www.w3.org/TR/widgets/#version-of-zip-needed-to-extract-a-file- and zip-rel-path grammar http://www.w3.org/TR/widgets/#zip-rel-path operates on characters, not bytes (it may not be fully clear from the PC text). We currently say this in the spec: For interoperability, manipulations of Zip relative paths must be performed on the string obtained by decoding the file name field using the appropriate encoding, and not on the bytes initially stored in the archive. For the sake of comparison and matching, it is recommended that a user agent treat all Zip-relative paths as [UTF-8]. XML Fifth Edition refers only to URI specification, it does not know about IRI. right. WUA must support XML and UTF-8: http://www.w3.org/TR/widgets/#dependencies-on-other-specifications-and However, in Step 7, we have not put what happens if the user agent does not understand the encoding. This would obviously result in the widget being treated as an invalid widget: To Step 7, I've added If doc is encoded in a format that is unsupported by the user agent, then the user agent must terminate this algorithm and treat this widget package as an invalid Zip archive. The configuration document is only required to be XML: http://www.w3.org/TR/widgets/#configuration-document and its encoding may be virtually any that is registered with IANA (my assumption). Yes. We don't impose restrictions on the encoding. I don't think we should. However, to the authoring guideline in the Configuration document section, I've added To ensure interoperability, encode the configuration document as [UTF-8]. So we can have the following situation: The WUA, that I develop widgets for, has a very interesting feature, whose IRI is really international (Polish in this case): http://example.com/ŁódzkiŚpiewnikŹdźbłowy Yep I.e. the IRI contains characters outside of the US-ASCII character set. Yep Then, I may not have an UTF-X capable editor at hand, so I convert the IRI to URI as in http://tools.ietf.org/html/rfc3987#section-3.1, Step 2. and I write the following config.xml with US-ASCII legacy encoding: ?xml version=”1.0” encoding=”us-ascii” widget … … feature name=”http://example.com/%C5%81%C3%B3dzki%C5%9Apiewnik%C5%B9d%C5%BAb%C5%82owy” / … /widget http://tools.ietf.org/html/rfc3987#section-3.2 provides a method to convert URI to IRI. However, I am not sure whether this conversion is mandated in PC, since PC just says that e.g. the name attribute is an IRI: I am not sure whether it should have IRI syntax in config.xml (not possible in my case, since I use US-ASCII only) or later. Percent encoding is allowed in IRIs: http://tools.ietf.org/html/rfc3987#section-2.2 and Terminals in the ABNF are characters, not bytes. Therefore it seems possible that the above config.xml, when parsed by XML- and UTF-8-supporting WUA, will refer to a feature whose IRI would be http://example.com/%C5%81%C3%B3dzki%C5%9Apiewnik%C5%B9d%C5%BAb%C5%82owy on the character level. Then, this valid IRI has to be checked for equivalence with http://example.com/ŁódzkiŚpiewnikŹdźbłowy ok based on the algorithm specified in http://tools.ietf.org/html/rfc3987#section-5.1 and http://tools.ietf.org/html/rfc3987#section-5.3.1 http://tools.ietf.org/html/rfc3987#section-5.3.2, specifically section 5.3.2.3 mentions percent-encoding normalization. I am not sure whether DOM3Core LoadSave mechanisms perform such normalization (as also below). I doubt it, as DOM3Core has no way of knowing if the value of an attribute is a URI or not. This is application dependent. PC does not specify it. PC says: An attribute defined as containing a valid IRI. A valid IRI is one that matches the IRI token of the [RFC3987] specification. Well, it defines the expected value. Again, is it the syntax in config.xml (i.e. impossible on byte level) or later? DOM3Core http://www.w3.org/TR/DOM-Level-3-Core/core.html says A solution for loading a Document and saving it persistently is proposed in [DOM Level 3 Load and Save]. DOM3LS http://www.w3.org/TR/DOM-Level-3-LS/load-save.html will normalize the entities AFAIK, but probably will not normalize percent-encoded characters in URI/IRI. I don't think it would. Proposal http://www.w3.org/TR/REC-xml-names/#iri-use says: Because of the risk of
Re: [PC] Low-level internationalization, XML deserialization, IRI or URI, IRI normalization
On Tue, Jul 28, 2009 at 12:27 PM, Marcin Hanclikmarcin.hanc...@access-company.com wrote: Hi Marcos, Yeah, that seems reasonable. I've added it. I have not seen your change, I do not know where to look for it. See http://dev.w3.org/2006/waf/widgets/Overview_TSE.html#iri-attribute Anyway, I think the actual problem remains unsolved. Maybe we should ask the developers? Which developers in particular did you have in mind? How do you propose we conduct this survey? Maybe we can ask BONDI to conduct a survey as part of their upcoming Widget coding thing? The target of widgets seems to be to address the most possible audience of developers and create a simple solution mainly for them. WUA may get a bit complex, I think. I don't understand the above. If e.g. a WUA exposes some nice feature specified as IRI (i.e. with characters outside of US-ASCII), then it mainly affects the developers who potentially may not have Unicode-capable editor. Right. config.xml can be specified e.g. in Shift-JIS or some other location specific charset (that people are used to), so Unicode-requirement also seems not to solve the problem, but just imposes something new. UTF-8 just serves as a base line... yes, there will be interop problems if UAs don't support the encodings used in the wild. However, that is an implementation detail me thinks. We have prescribed at least one encoding to be present (all UA MUST support UTF-8), which I think is a good basis for interop. Also maybe we should ask i18n people? Maybe we should. Please do. So we may want to specify the following (one of, more ideas welcome): a) the definition of feature names SHOULD/MUST use only US-ASCII characters. IMHO, this would mean that we actually assume that feature names are URIs, not IRIs. I don't like this. Authors will do whatever they want and implementers of features should be able to call features whatever they want. I think the best we could do here is just provide an authoring guideline saying, use US-ASCII for feature names. Rationale/advantage: simplicity Disadvantage: we are not i18n anymore right. b) Specify in PC that the IRI/URI - once retrieved from configuration document - must be normalized according to the algorithm specified in RFC3987 section 5. I'm ok to add this. So, in Step 7, for a given attribute (x): 1. if the value of attribute x is not UTF-8, let value-x be the value of attribute x encoded as UTF 8. 2. normalize value-x by applying section 5 of RFC3987. WRT 2 above, that is not clear enough for me. I will need help to specify that properly. Section 5.1 http://tools.ietf.org/html/rfc3987#section-5.1 says: Applications using IRIs as identity tokens with no relationship to a protocol MUST use the Simple String Comparison (see section 5.3.1). It may be valid for PC. Yes, that would be valid for wid...@id, for instance. As it would be valid for feat...@name. My preference is b), but I think that prior to a potential update of the PC, we need some discussion, as said e.g. with i18n. Sure. Please feel free to start this discussion with them. Additionally - but this may be out of the scope of PC - we may have to specify how to compare the feature names (and probably the other attributes) with the IRIs/features implemented in the WUA. We already went through this in the past. Comparison was going to be 1 to 1 (uri identifiers are treated as opaque strings or namespace identifiers, hance use literal comparisons). No normalization is done. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] BUG ALERT for P+C spec: Try to fallback to default start files when src path is invalid or not existing
On further consideration, Opera has decided this is not a bug. We would like to leave the behavior as is in the spec. What do others think? On Fri, Jul 31, 2009 at 5:50 PM, Marcos Caceresmarc...@opera.com wrote: Opera QA has found the following bug in the Widgets 1.0: Packaging and Configuration W3C Candidate Recommendation 23 July 2009 [1]. Description of bug: In Step 7, when a content element's src attribute's values is not a valid path, the UA treats the widget as an invalid widget. It should, instead, skip the offending content element and try to recover by using a default start file. Proposed solution: In Step 7, when a content element's src attribute's values is not a valid path, the UA should try to fallback to default start files. This would be achieved by changing the following text from: [[ If path is a valid path, let file be the result of applying the rule for finding a file within a widget package to path. If path is not a valid path, then a user agent must treat the widget package as an invalid Zip archive. ]] To: [[ If path is not a valid path, then the user agent must skip this element. If path is a valid path, let file be the result of applying the rule for finding a file within a widget package to path. If file is null or in error, then the user agent must skip this element. ]] [1] http://www.w3.org/TR/2009/CR-widgets-20090723/ -- Marcos Caceres http://datadriven.com.au -- Marcos Caceres http://datadriven.com.au
Widget Accessibility
Hi there, I've been looking through the widget specifications specifically 'Widgets 1.0: The Widget Landscape (Q1 2008)' - Figure 1 at http:// dev.w3.org/2006/waf/widgets-land/ I wonder if there is any concept of an accessibility bridge in either the widget of web application specifications. I was thinking of something like the Java Accessibility Bridge which links the code to the interpreter and on to the OS. If there is the concept of the Web as an application Platform then are there any similar concepts for making accessibility work in a uniform way - built-in at the start as opposed to an ARIA addition? Best Si. === Simon Harper University of Manchester (UK) Human Centred Web Lab: http://hcw.cs.manchester.ac.uk My Site: http://hcw.cs.manchester.ac.uk/people/harper/ My Diary (Web): http://hcw.cs.manchester.ac.uk/people/harper/ phpicalendar/week.php My Diary (Subscribe): http://hcw.cs.manchester.ac.uk/diaries/harper/ SimonHarper.ics
Re: Widget Accessibility
On Fri, Aug 7, 2009 at 5:12 PM, Simon Harpersimon.har...@manchester.ac.uk wrote: Hi there, I've been looking through the widget specifications specifically 'Widgets 1.0: The Widget Landscape (Q1 2008)' - Figure 1 at http://dev.w3.org/2006/waf/widgets-land/ I wonder if there is any concept of an accessibility bridge in either the widget of web application specifications. I was thinking of something like the Java Accessibility Bridge which links the code to the interpreter and on to the OS. If there is the concept of the Web as an application Platform then are there any similar concepts for making accessibility work in a uniform way - built-in at the start as opposed to an ARIA addition? No, not for widgets. Widgets rely on HTML and its hooks for accessibility. See also: http://dev.w3.org/2006/waf/widgets-reqs/#user-interface-accessibility However, if you have any ideas about a better way of doing this, we would certainly like to hear it. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
[widgets] Test Suite for Packaging and Configuration
I'm wondering, for the sake of testing, should we mandate the that in
order to run the test suite a user agent support the widgets AE
specification? This would kinda sucks because we say in the spec that
a UA is not required to support of the Widgets AE spec. However,
without the AE spec, testing becomes a bit more difficult.
For example, consider the following testable assertion:
If this is not the first name element encountered by the user agent,
then the user agent must skip this element.
The test would be:
!-- To pass, the second name element must be skipped by the user agent --
widget xmlns=http://www.w3.org/ns/widgets;
namePASS/name
nameFAIL/name
/widget
However, there is no way to visualize this test without using the
widgets AE spec:
!doctype html
html
body style=background-color:red
script
body = document.getElementsByTagName(body)[0];
if(widget.name == PASS){
body.setAttribute(style,background-color:green);
body.innerHTML = h1PASS /h1;
}else{
body.innerHTML = h1FAIL/h1;
}
/script
Actually, there are some tests that cannot even be visualized with the
AE spec... e.g., testing the license element, whose content is not
exposed via any attribute of the widget object. The only way for a UA
to verify if it passed, is to dump its internal representation of the
Configuration Defaults table.
Other things that suck about adding support for AE is that tests are
no longer atomic. To actually get widget.name, about 100 other
preconditions need to have occurred.
Thoughts? Or have I answered my own question (don't test with the AE
spec! :) )?
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
Re: [widgets] Test Suite for Packaging and Configuration
Hmm, well as you really can only test observable behaviour - and the
behaviour of a widget is really what the AE spec is concerned with...
I can see the problem we have here.
If we completed the widget catalogue Atom feed profile we mooted a
while back that would also give us another behaviour to test with (as
in, you can ask a UA what widgets do you have? and check the
catalogue metadata fits with the test cases).
It could be a good sanity check - if an element in PC has no effect
on any behaviour that we can observe, what is it there for? Should it
be exposed in AE? Or in a widget catalogue feed?
S
On 7 Aug 2009, at 17:33, Marcos Caceres wrote:
I'm wondering, for the sake of testing, should we mandate the that in
order to run the test suite a user agent support the widgets AE
specification? This would kinda sucks because we say in the spec that
a UA is not required to support of the Widgets AE spec. However,
without the AE spec, testing becomes a bit more difficult.
For example, consider the following testable assertion:
If this is not the first name element encountered by the user agent,
then the user agent must skip this element.
The test would be:
!-- To pass, the second name element must be skipped by the user
agent --
widget xmlns=http://www.w3.org/ns/widgets;
namePASS/name
nameFAIL/name
/widget
However, there is no way to visualize this test without using the
widgets AE spec:
!doctype html
html
body style=background-color:red
script
body = document.getElementsByTagName(body)[0];
if(widget.name == PASS){
body.setAttribute(style,background-color:green);
body.innerHTML = h1PASS /h1;
}else{
body.innerHTML = h1FAIL/h1;
}
/script
Actually, there are some tests that cannot even be visualized with the
AE spec... e.g., testing the license element, whose content is not
exposed via any attribute of the widget object. The only way for a UA
to verify if it passed, is to dump its internal representation of the
Configuration Defaults table.
Other things that suck about adding support for AE is that tests are
no longer atomic. To actually get widget.name, about 100 other
preconditions need to have occurred.
Thoughts? Or have I answered my own question (don't test with the AE
spec! :) )?
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
smime.p7s
Description: S/MIME cryptographic signature
Re: [File API] feedback on August 1/5 draft
On Thu, Aug 6, 2009 at 11:29 AM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Aug 6, 2009 at 4:04 AM, Anne van Kesterenann...@opera.com wrote: Thanks for the update to the draft! Below some feedback: In the table of contents the link to the filedata URL scheme is broken. The Web IDL syntax needs to be updated. E.g. FileList can be simply described as typedef sequenceany FileList; You mean: typedef sequenceFile FileList; right? I have not received any feedback on my comments as to why getAsDataURL is actually needed. I still think it should be dropped. Given that the filedata url is very limited in time, getAsDataURL still seems useful IMHO. I think getAsURL() should become an attribute instead. E.g. readonly attribute DOMString localURL; Since it is just a reference there is no need this needs to be asynchronous and there is also no need for it to be method. Agreed. The draft says a new UUID should be 'coined' for each method invocation. (Why is that?) Given the coinage of a new url on each access, accessing it thru an attribute feels a little odd. The constants of FileError need to be actually placed on the FileError object and renumbered as to make sense. They are not DOM exceptions so it does not make sense to align with that in any way. It seems useful to use the same code for people that want to display error messages to the user, this way you can either pass the value in the DOM event or from an exception to the same function. I also can't see a downside to aligning the values? But I don't feel strongly here. Last time I also made comments regarding the details of discovering the encoding of a file etc. Those still seem to apply. Got a pointer to the actual question? / Jonas
Re: FileAPI splice method
agreed... slice() seems more appropiate On Wed, Aug 5, 2009 at 10:34 PM, Adam de Boor adeb...@google.com wrote: this is a minor point, but I'm finding the name of the splice method to be odd. To me splice means to join, and slice would seem a more appropriate name. The Array object has both splice and slice, and the former is used for removing and inserting data and modifies the array in place, while the latter pulls out a sub-part of the array into a new array. a -- Adam de Boor Google
Re: [File API] feedback on August 1/5 draft
On Fri, Aug 7, 2009 at 3:21 PM, Jonas Sicking jo...@sicking.cc wrote: On Fri, Aug 7, 2009 at 12:23 PM, Michael Nordmanmicha...@google.com wrote: I think getAsURL() should become an attribute instead. E.g. readonly attribute DOMString localURL; Since it is just a reference there is no need this needs to be asynchronous and there is also no need for it to be method. Agreed. The draft says a new UUID should be 'coined' for each method invocation. (Why is that?) Given the coinage of a new url on each access, accessing it thru an attribute feels a little odd. I think we should removed that requirement though. I'd be in favor of removing that requirement too. (Unless there is an actual reason for it to start with? The draft was very expicit about calling for a new guid on each access, i have no clue why.) / Jonas
Things missing from Web IDL for HTML5
I updated HTML5 to use the new Web IDL stuff. Here's what's missing, and how I've used it: * Some interfaces need multipler callers. I've assumed that I can specify caller on multiple operations and have the overloading behaviour handle it automatically. * Some interfaces need the caller and the getter to be the same operation. I've assumed that one can specify both on the same operation. * [Supplemental]: For specification process reasons, some interface definitions don't get organised the same way as we want from implementations. I've assumed that [Supplemental] will exist, and used it as follows: - Setting [Supplemental, NoInterfaceObject] on an interface X with no ancestor and then saying: Y implements X; ...implies that the members in X are imported into Y as if the definition of Y always had X in it. - Setting [Supplemental, NoInterfaceObject] on an interface X that inherits from Y implies that there are objects called Y that have all the members of X and Y with X not appearing on the prototype chain. - Setting [Supplemental] on an interface that has the same name as an interface definition without [Supplemental]. The distinction between these cases is that I have three different cases where I need to do this. One is where I have some objects, e.g. Window, that are made up of APIs defined in other specs, and those APIs are also used by other interfaces. So I define Window, and then other specs slide stuff into Window, and slide stuff into other interfaces (like Worker- related ones). Another is WorkerGlobalScope, which I want to be the name of the interface implementing the global scope for workers, but there are two types of workers, and they have slightly different interfaces. And the third is the deprecated interfaces, where one interface, e.g. HTMLAnchorElement, is defined in two places. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: WebIDL and prototype chains
On Thu, 16 Jul 2009, Maciej Stachowiak wrote: On Jul 16, 2009, at 8:04 PM, Ian Hickson wrote: On Thu, 16 Jul 2009, Maciej Stachowiak wrote: HTML5 just says that new History, Location, etc, objects are created for each (inner) Window object. Is this not accurate? What do browsers do? Creating new ones on navigation is indeed correct, but a separate issue from making sure cross-origin cross-frame access to things like history.back() is safe for both parties. In HTML5, you can't access .history cross-domain, and you can't get to the prototype of the .location object (the only thing you can do to .location is set the .href member). Are these restrictions Web-incompatible? WebKit-based browsers allow cross-origin back(), forward() and go() on History, and replace(), reload() and assign() on Location, in addition to setting of href. I can't say definitively that all of those are needed to be Web compatible. Firefox allows access to at least location.replace() and history.back() cross-domain, and I would tentatively guess at least these two are required for Web compatibility. IE doesn't seem to allow history.back() cross-domain. I've made HTML5 allow everything IE8 seems to allow. postMessage() (or, say, focus()) is another example of something that needs to be accessible cross-origin, and I don't think you can fully hide its prototype because call() and apply() should be usable on it, for example. I haven't thought through exactly how this needs to work. The point is mainly that anything accessible cross-origin probably can't just follow the normal rules for building a prototype chain. How should I address this for HTML5? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Web IDL syntax
Cameron McCormack: I’ll think about it. :-) HTMLAppletElement can always have readonly attribute DOMString _object; to avoid conflicting with the reserved word. Ian Hickson: It's many years too late for that. The underscore is just an escaping mechanism. The identifier is still just object in this case. -- Cameron McCormack ≝ http://mcc.id.au/
Re: Web IDL syntax
On Sat, 8 Aug 2009, Cameron McCormack wrote: Cameron McCormack: I’ll think about it. :-) HTMLAppletElement can always have readonly attribute DOMString _object; to avoid conflicting with the reserved word. Ian Hickson: It's many years too late for that. The underscore is just an escaping mechanism. The identifier is still just object in this case. Oh. Fancy. Ok, done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Web IDL syntax
On Aug 7, 2009, at 6:23 PM, Cameron McCormack wrote: Cameron McCormack: I’ll think about it. :-) HTMLAppletElement can always have readonly attribute DOMString _object; to avoid conflicting with the reserved word. Ian Hickson: It's many years too late for that. The underscore is just an escaping mechanism. The identifier is still just object in this case. Wouldn't that get in the way of the possibility of underscores in identifiers in the future? I think it would be simpler to just capitalize the Object keyword. - Maciej
Re: Web IDL syntax
Maciej Stachowiak: Wouldn't that get in the way of the possibility of underscores in identifiers in the future? The underscore-escaping is a feature from OMG IDL. I don’t know if it’s worth changing to a different character like a backslash. If you want an identifier to actually begin with an underscore, you use two. -- Cameron McCormack ≝ http://mcc.id.au/
