Re: [Element Traversal LC] Minor comments
Hi, Sergiu- Thanks for your detail review Sergiu Dumitriu wrote (on 3/14/08 4:07 PM): Some quick comments on the Element Traversal Last Call Working Draft. These attributes must be read only, but this is only stated in the bindings. Shouldn't there be something about this in Section 2? Added: All of these attributes are read-only. to Section 2. 2.5: typo: must +be+ counted Fixed. 3.2: Is window.innerWidth in any spec? As far as I know, no, so is it good to use it? It is planned to be part of the Window spec. The example is non-normative, so I think it's safe to leave it in. 3.2: The way the position is computed is wrong. It should either be: var eachWidth = window.innerWidth / (elCount + 1); instead of var eachWidth = window.innerWidth / elCount; if the intention is to leave a space between the window margin and the elements, or: var nextPos = 0; instead of var nextPos = eachWidth/2; if the intention is to leave no space. Good catch. Fixed. Also, perhaps the width should also be set? childEl.style.setProperty( 'width', eachWidth + 'px', '' ); Not strictly necessary, but I added it anyway. B: typo: Element has -the- all the attributes Fixed. B: Shouldn't the In a User Agent... text be placed outside the code div? In its current position it looks bad all bold, and it also causes: B: Repetition: ...has the attributes defined below. The Element object has the following attributes: Fixed. Regards- -Doug Schepers W3C Team Contact, WebApps, SVG, and CDF
Re: ISSUE-5 (Unexpanded Entities): Wording for the Treatment of Unexpanded Entity References and Entity Replacement Markup [Element Traversal]
Hi, Bjoern and Anne- Bjoern Hoehrmann wrote (on 6/21/08 6:18 PM): * Web Applications Working Group Issue Tracker wrote: Simon Pieters suggests wording similar to HTML5, in http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0191.html. That is not a technically valid solution (and that particular wording does not, in fact, apply to the core node traversal interfaces, if you implement, say, .nextSibling as if entities had been expanded, entities have in fact been expanded). Anne's proposed solution is not valid either, except when applied to DOM Core, rescinding EntityReference nodes alltogether, as the issue is about how to implement this interface if you do have EntityReference nodes in the tree (or want your code to work whether or not you do). Having just researched the matter a bit more, I now have some improved wording that is more procedural, and makes fewer assumptions and impositions on the user agent. I believe that this wording should satisfy Björn's concerns while producing the well-defined behavior that Anne wants: EntityReference nodes are not visible to the Element Traversal mechanism; if the tree-walker encounteres an EntityReference node, it descends into it without informing the caller, and processes any children as if they had been present at the place where the entity node was found. If this does not satisfy either of you, please respond within two weeks, or sooner if possible. Regards- -Doug Schepers W3C Team Contact, WebApps, SVG, and CDF
Re: [Element Traversal LC] Minor comments
Hi, Sergiu- I forgot to mention, if you are not satisfied by these responses, please respond within two weeks, or sooner if possible. Regards- -Doug Doug Schepers wrote (on 7/30/08 2:56 AM): Hi, Sergiu- Thanks for your detail review Sergiu Dumitriu wrote (on 3/14/08 4:07 PM): Some quick comments on the Element Traversal Last Call Working Draft. These attributes must be read only, but this is only stated in the bindings. Shouldn't there be something about this in Section 2? Added: All of these attributes are read-only. to Section 2. 2.5: typo: must +be+ counted Fixed. 3.2: Is window.innerWidth in any spec? As far as I know, no, so is it good to use it? It is planned to be part of the Window spec. The example is non-normative, so I think it's safe to leave it in. 3.2: The way the position is computed is wrong. It should either be: var eachWidth = window.innerWidth / (elCount + 1); instead of var eachWidth = window.innerWidth / elCount; if the intention is to leave a space between the window margin and the elements, or: var nextPos = 0; instead of var nextPos = eachWidth/2; if the intention is to leave no space. Good catch. Fixed. Also, perhaps the width should also be set? childEl.style.setProperty( 'width', eachWidth + 'px', '' ); Not strictly necessary, but I added it anyway. B: typo: Element has -the- all the attributes Fixed. B: Shouldn't the In a User Agent... text be placed outside the code div? In its current position it looks bad all bold, and it also causes: B: Repetition: ...has the attributes defined below. The Element object has the following attributes: Fixed.
Re: XDomainRequest Integration with AC
On Jul 29, 2008, at 5:52 PM, Sunava Dutta wrote: Access-Control-Allow-Origin: * seems to be the consensus for the public scenario, please confirm. Yes. On a less urgent note did we get any further traction on the discussion on angle brackets for the URL specified scenario? The last mail here seems to be on 7/21. Jonas and I agreed offline that angle brackets are not required for unambiguous parsing. - MAciej -Original Message- From: Maciej Stachowiak [mailto:[EMAIL PROTECTED] Sent: Saturday, July 19, 2008 9:32 PM To: Jonas Sicking Cc: Sunava Dutta; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn; public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: Re: XDomainRequest Integration with AC On Jul 18, 2008, at 11:15 PM, Jonas Sicking wrote: Maciej Stachowiak wrote: On Jul 18, 2008, at 4:20 PM, Sunava Dutta wrote: I'm in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas's proposal. http://lists.w3.org/Archives/Public/public- webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. I think Anne's email represents the most recent agreement and I don't think anyone has objected: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0142.html The change would be: Instead of checking for XDomainRequestAllowed: 1 check for Access-Control-Allow-Origin: * or Access-Control-Allow-Origin: url where url matches what was sent in the Origin header. So I have one final request for a change to the above syntax. How would people feel about the syntax Access-Control-Allow-Origin: url I don't think the angle brackets are necessary for forward compat, since we can just disallow spaces from the URL. - Maciej This would give us at least something for a forwards compatibility story if we wanted to add to the syntax in future versions of the spec. I really think we are being overly optimistic if we think that the current syntax is the be-all end-all syntax that we'll ever want. For example during the meeting we talked about that banks might want to enforce that the requesting site uses a certain level of encryption, or even a certain certificate. A syntax for that might be: Access-Control-Allow-Origin: origin https://foo.com encryption sha1 Or that the site in question uses some opt-in XSS mitigation technology (such as the one drafted by Brandon Sterns in a previous thread in this WG). This could be done as Access-Control-Allow-Origin: origin https://foo.com require-xss- protection So the formal syntax would be Access-Control-Allow-Origin: (* | url) / Jonas / Jonas
Re: XDomainRequest Integration with AC
Please note that Access-Control-Allow-Origin: url is also allowed syntax. Where the url must contain only scheme, domain and host. So the following syntax is allowed: Access-Control-Allow-Origin: http://example.com It is somewhat unclear if the following syntaxes are allowed: Access-Control-Allow-Origin: http://example.com/ Access-Control-Allow-Origin: http://example.com/? Access-Control-Allow-Origin: http://example.com/# Access-Control-Allow-Origin: http://example.com/; I think the first one should be ok, but not the other three. / Jonas Sunava Dutta wrote: Access-Control-Allow-Origin: * seems to be the consensus for the public scenario, please confirm. On a less urgent note did we get any further traction on the discussion on angle brackets for the URL specified scenario? The last mail here seems to be on 7/21. -Original Message- From: Maciej Stachowiak [mailto:[EMAIL PROTECTED] Sent: Saturday, July 19, 2008 9:32 PM To: Jonas Sicking Cc: Sunava Dutta; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn; public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: Re: XDomainRequest Integration with AC On Jul 18, 2008, at 11:15 PM, Jonas Sicking wrote: Maciej Stachowiak wrote: On Jul 18, 2008, at 4:20 PM, Sunava Dutta wrote: I'm in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas's proposal. http://lists.w3.org/Archives/Public/public- webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. I think Anne's email represents the most recent agreement and I don't think anyone has objected: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0142.html The change would be: Instead of checking for XDomainRequestAllowed: 1 check for Access-Control-Allow-Origin: * or Access-Control-Allow-Origin: url where url matches what was sent in the Origin header. So I have one final request for a change to the above syntax. How would people feel about the syntax Access-Control-Allow-Origin: url I don't think the angle brackets are necessary for forward compat, since we can just disallow spaces from the URL. - Maciej This would give us at least something for a forwards compatibility story if we wanted to add to the syntax in future versions of the spec. I really think we are being overly optimistic if we think that the current syntax is the be-all end-all syntax that we'll ever want. For example during the meeting we talked about that banks might want to enforce that the requesting site uses a certain level of encryption, or even a certain certificate. A syntax for that might be: Access-Control-Allow-Origin: origin https://foo.com encryption sha1 Or that the site in question uses some opt-in XSS mitigation technology (such as the one drafted by Brandon Sterns in a previous thread in this WG). This could be done as Access-Control-Allow-Origin: origin https://foo.com require-xss- protection So the formal syntax would be Access-Control-Allow-Origin: (* | url) / Jonas / Jonas
Re: XDomainRequest Integration with AC
And note that this syntax should be supported even in the public data scenario. / Jonas Jonas Sicking wrote: Please note that Access-Control-Allow-Origin: url is also allowed syntax. Where the url must contain only scheme, domain and host. So the following syntax is allowed: Access-Control-Allow-Origin: http://example.com It is somewhat unclear if the following syntaxes are allowed: Access-Control-Allow-Origin: http://example.com/ Access-Control-Allow-Origin: http://example.com/? Access-Control-Allow-Origin: http://example.com/# Access-Control-Allow-Origin: http://example.com/; I think the first one should be ok, but not the other three. / Jonas Sunava Dutta wrote: Access-Control-Allow-Origin: * seems to be the consensus for the public scenario, please confirm. On a less urgent note did we get any further traction on the discussion on angle brackets for the URL specified scenario? The last mail here seems to be on 7/21. -Original Message- From: Maciej Stachowiak [mailto:[EMAIL PROTECTED] Sent: Saturday, July 19, 2008 9:32 PM To: Jonas Sicking Cc: Sunava Dutta; [EMAIL PROTECTED]; Sharath Udupa; Zhenbin Xu; Gideon Cohn; public-webapps@w3.org; IE8 Core AJAX SWAT Team Subject: Re: XDomainRequest Integration with AC On Jul 18, 2008, at 11:15 PM, Jonas Sicking wrote: Maciej Stachowiak wrote: On Jul 18, 2008, at 4:20 PM, Sunava Dutta wrote: I'm in time pressure to lock down the header names for Beta 2 to integrate XDR with AC. It seems no body has objected to Jonas's proposal. http://lists.w3.org/Archives/Public/public- webapps/2008JulSep/0175.html Please let me know if this discussion is closed so we can make the change. I think Anne's email represents the most recent agreement and I don't think anyone has objected: http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0142.html The change would be: Instead of checking for XDomainRequestAllowed: 1 check for Access-Control-Allow-Origin: * or Access-Control-Allow-Origin: url where url matches what was sent in the Origin header. So I have one final request for a change to the above syntax. How would people feel about the syntax Access-Control-Allow-Origin: url I don't think the angle brackets are necessary for forward compat, since we can just disallow spaces from the URL. - Maciej This would give us at least something for a forwards compatibility story if we wanted to add to the syntax in future versions of the spec. I really think we are being overly optimistic if we think that the current syntax is the be-all end-all syntax that we'll ever want. For example during the meeting we talked about that banks might want to enforce that the requesting site uses a certain level of encryption, or even a certain certificate. A syntax for that might be: Access-Control-Allow-Origin: origin https://foo.com encryption sha1 Or that the site in question uses some opt-in XSS mitigation technology (such as the one drafted by Brandon Sterns in a previous thread in this WG). This could be done as Access-Control-Allow-Origin: origin https://foo.com require-xss- protection So the formal syntax would be Access-Control-Allow-Origin: (* | url) / Jonas / Jonas
Re: XDomainRequest Integration with AC
Adam Roben wrote: On Jul 30, 2008, at 12:19 PM, Jonas Sicking wrote: Please note that Access-Control-Allow-Origin: url is also allowed syntax. Where the url must contain only scheme, domain and host. Do you mean scheme, host, and port? Yes :) / Jonas
Re: [Widgets] - Requirements Working Draft 23 June 2008 Review
Hi Benoit, Thank you for taking the time to prepare a detailed review. I think I was able to address all your comments, except for the one about R27. Widget State Change Events. It would be great if you could help clarify what you want me to do there. Please see below for detailed description of the changes I made. Please let me know if you are satisfied with the responses I've have given below or if you would like any further clarification. On Wed, Jul 30, 2008 at 8:52 AM, SUZANNE Benoit RD-SIRP-ISS [EMAIL PROTECTED] wrote: Marcos, Here are my comments on the Requirements (W3C Working Draft 23 June 2008) 1. Introduction [...] This document does not address the requirements of web widgets, such as iGoogle Gadgets or Windows Live Gadgets. I Think we can add a wording at the end of the sentense to read: ..., although this version of the widget specification, the Working group will address the web widget in the next iteration of the widgets specifications. Although I personally agree, I don't think we have reached a resolution as a working group about what features should be included in future versions of the Widgets specification. I don't want to prematurely commit us to feature which we may not end up implementing in the future. If anything, this should go into a Widgets 2.0 Requirements document. It might be good to prepare such a document once this one reaches CR. 3. Design Goals Longevity: ... I think in this chapter we should talk about the versioning of a widget. I'm not sure it should be presented as a specific item, or if it can be added inside the logevity section in relation to the longevity of the content provided and related updates it will need over time. I see what you are saying, but I think mentioning versioning is better served in the Web and offline distribution section. I've added the following text: A conforming specification needs to deal with cases where an end-user acquires a widget resource over HTTP or via some other non HTTP-based (offline) means, such as a local file system, Bluetooth or a Multimedia Message Service. In addition, a conforming specification needs to provide a means by which widgets can be updated when a new or different version of a widget becomes available. It must be possible to perform updates from either an online or offline source. R7. Internationalization Guidelines Rationale: [...] (e.g. 'resources/en/' for all English content, 'resources/en-au/' for further localized Australian-English content, and so on). Insert an and in between the 2 english example to stress the need to allow both Done. R15 R16 Is there a reason why they should not be must instead of should? I've changed R15 to a must, as we have already spec'd the license element. We are still undecided about rendering dimensions (R16). R19. Iconic Representations Rationale: [...] For example, an a small graphic of a calendar may represent a calendar widget. an a should be corrected Fixed. But I propose to add the following after: And a small graphic of today's calendar page may also represent this same calendar widget I changed the text to read: For example, a small graphic of a calendar showing today's date may represent a calendar widget. This is to incorporate your suggested text and to imply that the graphic may change dynamically (in accordance with R34 - Icon API). R27. Widget State Change Events This requirement must be available both ways, you should be able to capture the change of state when it happens, but you should also be able as an author to force the state change as well. I propose the following text: A conforming specification must also allow the author to programmatically change the state of the widget to allow a change in the view of the instantiated widget. I'm not sure this is the right place for this. I think this should be in R24. Instantiated Widget API. However, I'm not sure that the proposed text covers the actual requirement. I wanted to put something like you suggested into R24: The API SHOULD also also allow authors to programmatically change the visual state of a widget, but I'm not sure what that means. Can you please provide an example or a use case? R28. Network State Change Events In the specific case of a network drop, the author will need to know when the network works again, in order to not have to code a checking loop, it is important to put together a mechanism whereby it's the widget engine that wakes up the widget when the network is back on. What do you think? Agreed. Does the way the requirement has been rewritten in regards to events address the looping issue?: A conforming specification MUST specify a means that allows authors to check if the widget resource is connected to the network. A conforming specification MUST define the scope of the term network and MUST specify a means by which connection and disconnection events can be captured by an author through script. A conforming
Re: Accessibility requirement
On Tue, Jul 29, 2008 at 4:15 AM, Arthur Barstow [EMAIL PROTECTED] wrote: Marcos, Cynthia, Perhaps requirement #37 as currently written [1] is overly prescriptive. For example, rather than trying to enumerate the sub-requirements for the other language (i.e. the non-HTML language), there could just be a reference to a spec/doc that defines the requirements for a language to be accessible. Also, the last sentence appears to be a statement about a Widget instance (and not a requirement for a Widget UA) and hence should not be normative. Combining the above comments, I get: [[ A conforming specification must specify that the language used to declare the user interface of a widget be either HTML or a language that is accessible as defined by [?SOME-WAI-RESOURCE?]. ]] I'm willing to point the Requirements doc to WCAG 1 or 2 if the group wants me to. I personally don't agree with a lot of the things in WCAG 1 or 2, but if it's the best we have so be it. It would be helpful if others with more experience in this area could provide some guidance on how to proceed. -- Marcos Caceres http://datadriven.com.au
