Re: [selectors-api] Consider backporting find() behavior to querySelector()
On Mon, 18 Jun 2012 16:57:17 +0200, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: (12/06/18 22:45), Simon Pieters wrote: I think we should instead either fix the old API (if it turns out to not Break the Web) or live with past mistake (if it turns out it does). To find out whether it Breaks the Web (and the breakage can't be evanged), I suggest we ship the backwards-incompatible change to querySelector() in nightly/aurora (or equivalent) in one or more browsers for some time. I didn't read through all the QSA threads, but isn't the function name itself a mistake that many people don't want to live with? We have lots of shipped APIs with worse names. I think we should live with past mistakes, try not to make them again, and move on. -- Simon Pieters Opera Software
Re: CfC: publish a LCWD of Selectors API Level 1; deadline June 25
On Mon, 18 Jun 2012 15:57:02 +0200, Arthur Barstow art.bars...@nokia.com wrote: Lachlan has made some changes to the Selectors API Level 1 spec (last published as a CR) and we consider the changes sufficient to require the spec be published as a Working Draft (see the [1] thread). As such, this is a Call for Consensus to publish a new LCWD of this spec using the following document as the basis http://dev.w3.org/2006/webapi/selectors-api/. Please publish :) cheers -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan noen norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
On Tue, Jun 19, 2012 at 1:31 AM, fantasai fantasai.li...@inkedblade.net wrote: On 06/01/2012 05:02 AM, Anne van Kesteren wrote: On Wed, May 30, 2012 at 5:47 PM, fantasaifantasai.li...@inkedblade.net wrote: Though it seems likely that 'fixed' is required here, no? The top layer concept is also used by HTML for itsdialog element. This response doesn't seem to match the quoted sentence. ?? For fullscreen it is set to fixed per the default rendering rules. We do not want to do that all the time because HTML dialog uses the same rendering concepts. I expect we'll just update the specification. If it's still actively edited at that point, sure. If it's not maintained it's dead and unreliable anyway... You also need to state its relationship to other elements in the tree. Right now its inheritance behavior is undefined. Why? It has no children. -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
On Tue, Jun 19, 2012 at 1:45 AM, fantasai fantasai.li...@inkedblade.net wrote: It looks like you missed #2. I think ::backdrop is clear enough. Not entirely sure what you would expect seeing there more than what it already says. -- Anne — Opera Software http://annevankesteren.nl/ http://www.opera.com/
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
Le 19/06/12 09:41, Anne van Kesteren a écrit : On Tue, Jun 19, 2012 at 1:45 AM, fantasaifantasai.li...@inkedblade.net wrote: It looks like you missed #2. I think ::backdrop is clear enough. Not entirely sure what you would expect seeing there more than what it already says. Well, the spec says how it's named, where it is created and still lacks a description of *WHAT IT IS*, functionnally speaking... It would help really a lot to have such an explanation. /Daniel
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
Le 18/06/12 13:09, Arthur Barstow a écrit : On 5/30/12 10:38 AM, ext Daniel Glazman wrote: Le 30/05/12 14:43, Arthur Barstow a écrit : Chris, Daniel, Peter - when will the CSS WG make a decision on the FPWD? We'll try to make one today during our weekly conf-call. Please note that we're going to review the bits of this document falling under CSS WG's wings. In particular section 6. Peter and I already have discovered a few things : 1. position: center in section 6.1 refers to an Editor's Draft that is not actively discussed at this time. Only normative references should be made to CSS specs or the Fullscreen draft will have to wait until that ED becomes a REC to itself become a REC. 2. the ::backdrop pseudo-element is not explained in the document outside of section 6.2. It's unclear to me why it is needed, what it represents, etc. 3. the parenthesis in section 6.2 seems to me to contain a copy/paste error above the element below the element 4. layer and layer 10 in section 6.1 are unclear. Layer is used nowhere in CSS references used in this spec. This must be clarified. Does the latest ED http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html address the above concerns? No, item 2 above is still not addressed, and I guess most readers of the document won't understand what functionally represents ::backdrop. 1. the definition of requestFullScreen() says what are the steps it should run but it does not even say what feature it provides. I think a sentence saying The requestFullScreen() method sends a request for the Element to go fullscreen. Please see section 7 for the Security Considerations attached to this method. is needed. 2. allowfullscreen and iframe in section 7 should be hyperlinks. I note the reference is at WHATWG while it should be at W3C. These two points are still unaddressed too. /Daniel
Re: Browser Payments API proposal
On Sat, 16 Jun 2012 06:05:35 +0200, Alex MacCaw macc...@gmail.com wrote:
I've been working on a way of integrating one-click payments (and signup)
into the browser, and I wanted to put it in front of a few people to get
some feedback.
The API I was playing about with was pretty simple, and is documented
here:
http://blog.alexmaccaw.com/preview/MjQxMDcwOTcwNjAYz14YvbdZWrrVg
(that link seems to go nowhere except the front of your blog)
It's basically an API to autocomplete data, already stored in the browser
and containing things like credit card number and name.
For example:
navigator.requestProfile(['firstName', 'email', 'cardNumber'], function(
profile){ console.log('Your name is:', profile.firstName); /* ... */ });
So it seems you are just using an API to support autocomplete, but with
magic tokens as well as the browser heuristics that are normally used.
This seems to introduce a lot of UI security issues (asking for data for
hidden form fields or fields that are out of the rendering view, ...).
cheers
Chaals
I've also created a Chrome
extensionhttps://github.com/maccman/request-profile demonstrating
the API. I think the key thing to getting adoption for something like
this
is to keep it really simple.
Cheers,
Alex
--
Charles 'chaals' McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [manifest] screen sizes, Re: Review of Web Application Manifest Format and Management APIs
On Wed, 06 Jun 2012 14:39:35 +0200, Henri Sivonen hsivo...@iki.fi wrote: On Sun, May 27, 2012 at 7:45 PM, Anant Narayanan an...@mozilla.com wrote: Well, we haven't received this request from developers explicitly yet, but one can imagine a situation in which a developer makes an app only for mobile phones (Instagram?) and doesn't want users to use it on desktops. Even though it'll technically work, it might look ugly due to scaling. Shouldn't it be up to the user to refrain from using ugly apps instead of the developer preventing them? I agree with Henri. I certainly don't support this use case where it doesn't have any real requests to back it up. There are cases where a user chooses for some important reason (e.g. accessibility) to use the wrong app on their device, and not supporting *that* use case would be a serious change from how the Web is generally expected to work. In the tradition of the Web, authors are given information to help them propose, but it is users who dispose - decide what it is they will actually use. -- Charles 'chaals' McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg kan noen norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Fwd: IndieUI Call For Proposals
The Independent User Interface WG (aka IndieUI) was started a few weeks ago [Charter] and they now have a CfP for the group's two specifications: IndieUI Events, and IndieUI User Context. Details below. -AB [Charter] http://www.w3.org/2012/05/indie-ui-charter Original Message Subject:IndieUI Call For Proposals Resent-Date:Tue, 19 Jun 2012 01:44:24 + Resent-From:public-indie...@w3.org Date: Mon, 18 Jun 2012 21:43:56 -0400 From: ext Janina Sajka jan...@rednote.net To: Independent User Interface Task Force public-indie...@w3.org Call for Proposals: Use Cases, Requirements and Specification Inputs Independent User Interface Task Force World Wide Web Consortium 18 June 2012 The WAI Independent User Interface (IndieUI) Working Group and the Web Events Working Group are now seeking proposals from W3C members for their two joint deliverables: 1.) Indie UI: Events 1.0, an abstraction between device-specific user interaction events and inferred user intent such as scroll, activate, etc. This provides an intermediate layer between device- and modality-specific user interaction events, and the basic user interface functionality used by Web applications. Indie UI: Events focuses on granular user interface interactions such as scrolling the view, canceling an action, changing the value of a user input widget, selecting a range, placing focus on an object, etc. Implementing platforms will take modality-specific user input, user idiosyncratic heuristics to determine the specific corresponding Indie UI event, and send that to the Web application (along with details of the modality-specific input such as mouse or keyboard events should applications wish to process it). 2.) Indie UI: User Context 1.0, a set of properties and methods related to the environmental context of a specific user, and a vehicle to access them to facilitate a Web application's ability to adapt to the user's needs. This is meant to provide information about whether a user is using a screen reader, screen magnifier, or other Assistive Technology, and to expose relevant user settings, allowing optimal adaptation of the Web application's user interface. In addition to inputs for the above deliverables, we also welcome and encourage Use Cases and Requirements for these deliverables. Please see the related wiki that includes some initial Use Case inputs: http://www.w3.org/WAI/IndieUI/wiki/Use_Cases_and_Requirements Proposals received will be evaluated for use as initial starting points in the creation of these deliverables by the IndieUI Task Force, which is the locus of joint work on these deliverables for the WAI_IndieUI WG and the Web Events WG. Proposals should be submitted by 15 July 2012, and should be submitted to the IndieUI Task Force's email list (public-indie...@w3.org). Proposals submitted after that date are still welcome but may not be included in First Public Working Drafts. More information concerning the work of the IndieUI Task Force, including instructions on how to participate, is available on the IndieUI Task Force Home Page: http://www.w3.org/WAI/IndieUI/IUITF The WAI Independent User Interface (IndieUI) Working Group Home Page is at: http://www.w3.org/WAI/IndieUI/ The Web Events Working Group Home Page is at: http://www.w3.org/2010/webevents/ -- Janina Sajka, Phone: +1.443.300.2200 sip:jan...@asterisk.rednote.net Email: jan...@rednote.net The Linux Foundation Chair, Open Accessibility: http://a11y.org The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) Chair, Protocols Formats http://www.w3.org/wai/pf Indie UIhttp://www.w3.org/WAI/IndieUI/
Re: CfC: Publish FPWD of Web Intents spec; deadline June 12
On 5/29/12 2:45 PM, ext James Hawkins wrote: Dave Raggett (d...@w3.org) made a call [1] on April 10 to publish a first public working draft, and this is a Call for Consensus to do so, using the following document as the basis: dvcs.w3.org/hg/web-intents/raw-file/tip/spec/Overview.html I included public-webapps and public-device-apis on this CfC since Web Intents is a joint-deliverable [2][3] between these two groups. By publishing this FPWD, the group sends a signal to the community to begin reviewing the document. The FPWD reflects where the group is on this spec at the time of publication; it does not necessarily mean there is consensus on the spec's contents. Positive response to this CfC is preferred and encouraged and silence will be considered as agreement with the proposal. The deadline for comments is June 12. Please send all comments to: Dave - it appears this CfC passed. Unless I hear otherwise from you, I will assume DAP will take care of the Transition Request and Publication Request. -Thanks, AB public-web-inte...@w3.org Thanks, James Hawkins [1] http://lists.w3.org/Archives/Public/public-web-intents/2012Apr/0016.html [2] http://www.w3.org/2012/webapps/charter/ [3] http://www.w3.org/2011/07/DeviceAPICharter
Re: [selectors-api] Consider backporting find() behavior to querySelector()
I am very opposed to this, they do different things. Having abilities isn't a bad thing and numerous Web sites and libraries make use of qsa, not just because find was not available but because different APIs shapes interesting new possibilities, different ways of looking at problems, etc... We solve problems with the tools at hand, so given that it has been widely implemented a long time, you can safely assume we have found good uses for it. There are a vast number of libraries and websites that have use cases for find, this is especially true because selector engines that solved those cases evolved in the wild a long time ago it probably would have been nice to have had that native first, as it would have been a more immediate help for the vast number of users, but qsa is definitely useful. On Jun 18, 2012 10:45 AM, Simon Pieters sim...@opera.com wrote: So http://dev.w3.org/2006/webapi/**selectors-api2/http://dev.w3.org/2006/webapi/selectors-api2/introduces the methods find() and findAll() in addition to querySelector() and querySelectorAll() and changes the scoping behavior for the former methods to match what people expect them to do. I'm not convinced that doubling the API surface is a good idea. If we were to do that every time we find that a shipped API has suboptimal behavior, the API surface on the Web would grow exponentially and we wouldn't make the overall situation any better. What if we find a new problem with find() after it has shipped? Do we introduce yet another method? I think we should instead either fix the old API (if it turns out to not Break the Web) or live with past mistake (if it turns out it does). To find out whether it Breaks the Web (and the breakage can't be evanged), I suggest we ship the backwards-incompatible change to querySelector() in nightly/aurora (or equivalent) in one or more browsers for some time. -- Simon Pieters Opera Software
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
On 6/19/12 3:52 AM, ext Daniel Glazman wrote: Le 18/06/12 13:09, Arthur Barstow a écrit : On 5/30/12 10:38 AM, ext Daniel Glazman wrote: Le 30/05/12 14:43, Arthur Barstow a écrit : Chris, Daniel, Peter - when will the CSS WG make a decision on the FPWD? We'll try to make one today during our weekly conf-call. Please note that we're going to review the bits of this document falling under CSS WG's wings. In particular section 6. Peter and I already have discovered a few things : 1. position: center in section 6.1 refers to an Editor's Draft that is not actively discussed at this time. Only normative references should be made to CSS specs or the Fullscreen draft will have to wait until that ED becomes a REC to itself become a REC. 2. the ::backdrop pseudo-element is not explained in the document outside of section 6.2. It's unclear to me why it is needed, what it represents, etc. 3. the parenthesis in section 6.2 seems to me to contain a copy/paste error above the element below the element 4. layer and layer 10 in section 6.1 are unclear. Layer is used nowhere in CSS references used in this spec. This must be clarified. Does the latest ED http://dvcs.w3.org/hg/fullscreen/raw-file/tip/Overview.html address the above concerns? No, item 2 above is still not addressed, and I guess most readers of the document won't understand what functionally represents ::backdrop. 1. the definition of requestFullScreen() says what are the steps it should run but it does not even say what feature it provides. I think a sentence saying The requestFullScreen() method sends a request for the Element to go fullscreen. Please see section 7 for the Security Considerations attached to this method. is needed. 2. allowfullscreen and iframe in section 7 should be hyperlinks. I note the reference is at WHATWG while it should be at W3C. These two points are still unaddressed too. My interpretation of your comments is the first set (#1-#4 above) are considered FPWD Showstoppers by the CSS WG and the second set of comments (#1-#2) were your personal comments (since they are related to the API and process) and as such, Not FPWD Showstoppers. Given this interpretation - and of course, please correct it if it is wrong - it appears the only remaining FPWD Showstopper is #2 in the first set of comments. Is that correct? (FYI, before the FPWD is published in /TR/, the HTML reference will use a link to the W3C's HTML5 spec.) -Thanks, AB
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
Le 19/06/12 14:10, Arthur Barstow a écrit : Given this interpretation - and of course, please correct it if it is wrong - it appears the only remaining FPWD Showstopper is #2 in the first set of comments. Is that correct? Yes. /Daniel
Re: Browser Payments API proposal
Nice idea Alex! I have done some work on this in the past, but it didn't go very far. A few tips: 1. As long as many users don't have this, websites would still have to do form-based credit-card forms. But browsers and extensions are getting pretty good at auto-filling these forms. So you have a tough competition from the entrenched technology and there are ways websites can help the auto-complete work even better (e.g. proper element names). 2. The permissions dialog needs to be more visible and proactive. Users (even advanced ones) often miss the permissions prompts. 3. Requiring the user to type a security code / pin every time you give a site your credit card info might increase awareness and security. 4. Can we do something that doesn't require scripting? Maybe a new tag? The motivation for that is embedding one click payments in emails where scripting is disabled. 5. Minor things: How to deal with multiple credit cards? What if a site only suports AmEx but not Visa? On Sun, Jun 17, 2012 at 5:34 AM, Arthur Barstow art.bars...@nokia.comwrote: On 6/16/12 8:16 PM, ext Alex MacCaw wrote: The blog article link has changed to: http://blog.alexmaccaw.com/** preview/**Pc1LYBw4xDT95OPWZGihod7z8Whrnf**AdXMjQxMDg3MTc5NDIaXNjA1phttp://blog.alexmaccaw.com/preview/Pc1LYBw4xDT95OPWZGihod7z8WhrnfAdXMjQxMDg3MTc5NDIaXNjA1p Alex - perhaps this API will be of interest to the Web Payments Community Group http://www.w3.org/community/**webpayments/http://www.w3.org/community/webpayments/. -AB
Re: Browser Payments API proposal
I'm not sure this is a problem worth solving in the platform. In 5-10 years I doubt we'll be typing our card numbers into pages. You'll tap your phone to your laptop or use some kind of payment service like paypal/wallet/etc. There's so many security/privacy issues with exposing your payment information behind an infobar to any page that requests it. On Tue, Jun 19, 2012 at 10:15 AM, Yaar Schnitman y...@chromium.org wrote: Nice idea Alex! I have done some work on this in the past, but it didn't go very far. A few tips: 1. As long as many users don't have this, websites would still have to do form-based credit-card forms. But browsers and extensions are getting pretty good at auto-filling these forms. So you have a tough competition from the entrenched technology and there are ways websites can help the auto-complete work even better (e.g. proper element names). 2. The permissions dialog needs to be more visible and proactive. Users (even advanced ones) often miss the permissions prompts. 3. Requiring the user to type a security code / pin every time you give a site your credit card info might increase awareness and security. 4. Can we do something that doesn't require scripting? Maybe a new tag? The motivation for that is embedding one click payments in emails where scripting is disabled. 5. Minor things: How to deal with multiple credit cards? What if a site only suports AmEx but not Visa? On Sun, Jun 17, 2012 at 5:34 AM, Arthur Barstow art.bars...@nokia.comwrote: On 6/16/12 8:16 PM, ext Alex MacCaw wrote: The blog article link has changed to: http://blog.alexmaccaw.com/** preview/**Pc1LYBw4xDT95OPWZGihod7z8Whrnf**AdXMjQxMDg3MTc5NDIaXNjA1phttp://blog.alexmaccaw.com/preview/Pc1LYBw4xDT95OPWZGihod7z8WhrnfAdXMjQxMDg3MTc5NDIaXNjA1p Alex - perhaps this API will be of interest to the Web Payments Community Group http://www.w3.org/community/**webpayments/http://www.w3.org/community/webpayments/. -AB
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
On 6/19/12 3:49 AM, ext Daniel Glazman wrote: Le 19/06/12 09:41, Anne van Kesteren a écrit : On Tue, Jun 19, 2012 at 1:45 AM, fantasaifantasai.li...@inkedblade.net wrote: It looks like you missed #2. I think ::backdrop is clear enough. Not entirely sure what you would expect seeing there more than what it already says. Well, the spec says how it's named, where it is created and still lacks a description of *WHAT IT IS*, functionnally speaking... It would help really a lot to have such an explanation. Anne, Tantek, please work Daniel, Fantasai, et al. to address their concern(s). (AFAIK, this is the only issue blocking FPWD.) -Thanks, AB
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
On 06/19/2012 12:40 AM, Anne van Kesteren wrote: On Tue, Jun 19, 2012 at 1:31 AM, fantasaifantasai.li...@inkedblade.net wrote: On 06/01/2012 05:02 AM, Anne van Kesteren wrote: On Wed, May 30, 2012 at 5:47 PM, fantasaifantasai.li...@inkedblade.net wrote: Though it seems likely that 'fixed' is required here, no? The top layer concept is also used by HTML for itsdialogelement. This response doesn't seem to match the quoted sentence. ?? For fullscreen it is set to fixed per the default rendering rules. We do not want to do that all the time because HTMLdialog uses the same rendering concepts. Hm, so if I scroll with a fullscreened dialog, the dialog scrolls out of view, but if I scroll with a fullscreened img, the image stays in view? I expect we'll just update the specification. If it's still actively edited at that point, sure. If it's not maintained it's dead and unreliable anyway... How unreliable it is depends on how stable it became before it was abandoned. It doesn't hurt to word things in ways that will remain true once you are busy working on something else; rather it helps the spec remain reliable to reduce the dependencies on the exact details of other specs. You also need to state its relationship to other elements in the tree. Right now its inheritance behavior is undefined. Why? It has no children. Sure, that's fine. Might make it explicit, but really the issue is what element does the ::backdrop element inherit from? ~fantasai
Re: Should MutationObservers be able to observe work done by the HTML parser?
On Sun, Jun 17, 2012 at 12:17 PM, Ryosuke Niwa rn...@webkit.org wrote: On Sun, Jun 17, 2012 at 5:03 AM, Jonas Sicking jo...@sicking.cc wrote: On Sat, Jun 16, 2012 at 7:04 AM, Rafael Weinstein rafa...@google.com wrote: I too thought we had intentionally spec'd them to not fire during load. The HTML spec is clear about this WRT Mutation Events: http://www.whatwg.org/specs/web-apps/current-work/#tree-construction: DOM mutation events must not fire for changes caused by the UA parsing the document. (Conceptually, the parser is not mutating the DOM, it is constructing it.) This includes the parsing of any content inserted using document.write() and document.writeln() calls. It seems like this should also apply to Mutation Observers, unless we have compelling reasons to do otherwise. This was something that we got people complaining about with mutation events over the years. Our answer used to be that mutation events generally suck and you can't depend on them anyway. Obviously not an argument we'd want to use for MutationObservers. I can't think of any cases where you would *not* want these to fire for parser mutations. Agreed. I'm in favor of observers being notified for parser-initiated DOM mutations. The primary reason we don't fire mutation events for parser insertion removal is because they're synchronous and introduces all sorts of problems including security vulnerabilities but that isn't the case with mutation observers. One question. Should we also notify mutation observers immediately before executing synchronous scripts (i.e. script elements without differ or async content attributes) to address Mihai's use case? This is one part of a more general question (raised by Ojan on webkit.org/b/89351): what should the timing be for delivery of these parser-initiated mutations? Mihai's use case is one example where we might want something other than end-of-task delivery. Ojan points out that simply using end-of-task could expose low-level implementation detail of the parser to script (such as how much parsing is done in a single task before the parser yields). Does Firefox do anything special here? Or does it simply use the same end-of-task delivery as everywhere else? - Adam
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On Mon, Jun 18, 2012 at 10:59 PM, Simon Pieters sim...@opera.com wrote: On Mon, 18 Jun 2012 16:57:17 +0200, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: (12/06/18 22:45), Simon Pieters wrote: I think we should instead either fix the old API (if it turns out to not Break the Web) or live with past mistake (if it turns out it does). To find out whether it Breaks the Web (and the breakage can't be evanged), I suggest we ship the backwards-incompatible change to querySelector() in nightly/aurora (or equivalent) in one or more browsers for some time. I didn't read through all the QSA threads, but isn't the function name itself a mistake that many people don't want to live with? We have lots of shipped APIs with worse names. I think we should live with past mistakes, try not to make them again, and move on. This is not a good argument. qSA is used often enough, and has a long enough name, that the name is actually a pretty significant misfeature. This is a pretty core API, and both it and its precursors (getElementByID, etc.) are very commonly renamed by libraries precisely because you need a very short name for such a commonly used function. ~TJ
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
On 06/19/2012 12:49 AM, Daniel Glazman wrote: Le 19/06/12 09:41, Anne van Kesteren a écrit : On Tue, Jun 19, 2012 at 1:45 AM, fantasaifantasai.li...@inkedblade.net wrote: It looks like you missed #2. I think ::backdrop is clear enough. Not entirely sure what you would expect seeing there more than what it already says. Well, the spec says how it's named, where it is created and still lacks a description of *WHAT IT IS*, functionnally speaking... It would help really a lot to have such an explanation. You could just work in the explanation I sent in http://www.w3.org/mid/4fc64100.3060...@inkedblade.net e.g. | Each element in the top layer's stack has a ::backdrop pseudo-element, | which can be styled to create a backdrop that hides the underlying | document when the element is displayed fullscreen. I think that would address Daniel's comment. The CSSWG generally tries to explain the intention of a feature at a high level rather than simply giving the processing model and asking implementers to blindly implement it. This helps spec reviewers understand the goal of the feature and therefore comment intelligently on how it fulfills that goal, and it helps implementers and authors create a mental context for interpreting the rest of the spec text and applying it to real code. ~fantasai
Re: Should MutationObservers be able to observe work done by the HTML parser?
On 06/19/2012 11:37 PM, Adam Klein wrote: On Sun, Jun 17, 2012 at 12:17 PM, Ryosuke Niwa rn...@webkit.org mailto:rn...@webkit.org wrote: On Sun, Jun 17, 2012 at 5:03 AM, Jonas Sicking jo...@sicking.cc mailto:jo...@sicking.cc wrote: On Sat, Jun 16, 2012 at 7:04 AM, Rafael Weinstein rafa...@google.com mailto:rafa...@google.com wrote: I too thought we had intentionally spec'd them to not fire during load. The HTML spec is clear about this WRT Mutation Events: http://www.whatwg.org/specs/web-apps/current-work/#tree-construction: DOM mutation events must not fire for changes caused by the UA parsing the document. (Conceptually, the parser is not mutating the DOM, it is constructing it.) This includes the parsing of any content inserted using document.write() and document.writeln() calls. It seems like this should also apply to Mutation Observers, unless we have compelling reasons to do otherwise. This was something that we got people complaining about with mutation events over the years. Our answer used to be that mutation events generally suck and you can't depend on them anyway. Obviously not an argument we'd want to use for MutationObservers. I can't think of any cases where you would *not* want these to fire for parser mutations. Agreed. I'm in favor of observers being notified for parser-initiated DOM mutations. The primary reason we don't fire mutation events for parser insertion removal is because they're synchronous and introduces all sorts of problems including security vulnerabilities but that isn't the case with mutation observers. One question. Should we also notify mutation observers immediately before executing synchronous scripts (i.e. script elements without differ or async content attributes) to address Mihai's use case? This is one part of a more general question (raised by Ojan on webkit.org/b/89351 http://webkit.org/b/89351): what should the timing be for delivery of these parser-initiated mutations? Mihai's use case is one example where we might want something other than end-of-task delivery. Mihai's use case is related to https://www.w3.org/Bugs/Public/show_bug.cgi?id=17529 (where I think Gecko's behavior is the good one) If we start to call mutation callbacks right before script execution, we would need to handle cases when script element is moved in the DOM right before script execution etc. Ugly stuff. Ojan points out that simply using end-of-task could expose low-level implementation detail of the parser to script (such as how much parsing is done in a single task before the parser yields). Does Firefox do anything special here? Or does it simply use the same end-of-task delivery as everywhere else? end-of-microtask or end-of-task everywhere. And yes, some parsing / networking details may unfortunately be exposed, but in a way which should be quite random. Web devs just can't really rely on network packages to be delivered to parser in some exact way. - Adam
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
Le 19/06/12 22:48, fantasai a écrit : You could just work in the explanation I sent in http://www.w3.org/mid/4fc64100.3060...@inkedblade.net e.g. | Each element in the top layer's stack has a ::backdrop pseudo-element, | which can be styled to create a backdrop that hides the underlying | document when the element is displayed fullscreen. I think that would address Daniel's comment. Yes. But please note I insist on this only because I think the current prose is absolutely not self-explanatory enough. The CSSWG generally tries to explain the intention of a feature at a high level rather than simply giving the processing model and asking implementers to blindly implement it. This helps spec reviewers understand the goal of the feature and therefore comment intelligently on how it fulfills that goal, and it helps implementers and authors create a mental context for interpreting the rest of the spec text and applying it to real code. Again, yes. I am in particular thinking of implementors who will read this document w/o having followed the discussions here. I know our (W3C) specs are not meant for end-user consumption but it's not a reason to make them hard to understand even to implementors. That's also the reason why I asked to explain requestFullscreen(). It can sound obvious, but it's not. And in fact, we should _never_ introduce a new syntax, API, whatever w/o saying _what it does_ from a functional point of view before explaining how it works. /Daniel
Re: [selectors-api] Consider backporting find() behavior to querySelector()
20.06.2012, 00:38, Tab Atkins Jr. jackalm...@gmail.com: On Mon, Jun 18, 2012 at 10:59 PM, Simon Pieters sim...@opera.com wrote: On Mon, 18 Jun 2012 16:57:17 +0200, Kang-Hao (Kenny) Lu kennyl...@csail.mit.edu wrote: We have lots of shipped APIs with worse names. I think we should live with past mistakes, try not to make them again, and move on. This is not a good argument. qSA is used often enough, and has a long enough name, that the name is actually a pretty significant misfeature. This is a pretty core API, and both it and its precursors (getElementByID, etc.) are very commonly renamed by libraries precisely because you need a very short name for such a commonly used function. There is a key difference between native functionality and one implemented as a library -- they quite differently relate to backward compatibility. A library can be rewritten partially or even entirely if needed (older applications can just continue using older versions of the library), while native functionality, once widely implemented, have to be supported forever and in fact cannot (and should never) be dropped. As for `querySelector()` in particular, its name is indeed not the best, but _not_ because it's too long, but because it's not quite _clear_ / _self-documenting_. `querySelector()` and `querySelectorAll()` should have been named `getElementBySelector()` and `getElementsBySelector()` instead. In this regard, `find()` is far less clear (and even confusing) as for what it does.
RE: CfC: publish FPWD of Fullscreen spec; deadline May 24
[Daniel Glazman:] That's also the reason why I asked to explain requestFullscreen(). It can sound obvious, but it's not. And in fact, we should _never_ introduce a new syntax, API, whatever w/o saying _what it does_ from a functional point of view before explaining how it works. To the extent possible I think specs should document some of the core use-cases and scenarios they are derived from e.g. as an informative intro or appendix. Extra points for covering scenarios that are explicitly out of scope for the current version. This would be especially valuable for new specifications. I don't think people who don't live in WHATWG/W3C mailing lists and/or make browsers for a living can read a document like this one - or, say, CORS - and hope to figure out what problems they are/aren't trying to solve. (I'm not sure they're even that obvious for people who do)
Re: CfC: publish FPWD of Fullscreen spec; deadline May 24
On 6/20/12 12:05 AM, Sylvain Galineau sylva...@microsoft.com wrote: [Daniel Glazman:] That's also the reason why I asked to explain requestFullscreen(). It can sound obvious, but it's not. And in fact, we should _never_ introduce a new syntax, API, whatever w/o saying _what it does_ from a functional point of view before explaining how it works. To the extent possible I think specs should document some of the core use-cases and scenarios they are derived from e.g. as an informative intro or appendix. Extra points for covering scenarios that are explicitly out of scope for the current version. This would be especially valuable for new specifications. I don't think people who don't live in WHATWG/W3C mailing lists and/or make browsers for a living can read a document like this one - or, say, CORS - and hope to figure out what problems they are/aren't trying to solve. (I'm not sure they're even that obvious for people who do) Can't agree more. Unpublished / hard to find use cases makes everyone's life harder and worsens the perception authors have of spec writers and implementors. Calling them authors doesn't help, either. :-/ --tobie
[IndexedDB] Origins and document.domain
By my reading, the spec does not clearly specify what the 'origin' should be. IDBFactory.open/deleteDatabase say Let origin be the origin of the IDBEnvironment used to access this IDBFactory. The IDL states Window implements IDBEnvironment; The HTML5 spec, as far as I can tell, does not define the concept of an origin for a window, but only for a document. There is another related question here: how should IndexedDB behave in the presence of modifications to document.domain? - Kyle
Re: [IndexedDB] Origins and document.domain
IndexedDB should ignore document.domain. Adam On Tue, Jun 19, 2012 at 9:06 PM, Kyle Huey m...@kylehuey.com wrote: By my reading, the spec does not clearly specify what the 'origin' should be. IDBFactory.open/deleteDatabase say Let origin be the origin of the IDBEnvironment used to access this IDBFactory. The IDL states Window implements IDBEnvironment; The HTML5 spec, as far as I can tell, does not define the concept of an origin for a window, but only for a document. There is another related question here: how should IndexedDB behave in the presence of modifications to document.domain? - Kyle
Re: [selectors-api] Consider backporting find() behavior to querySelector()
On Tue, Jun 19, 2012 at 1:38 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: ... This is not a good argument. qSA is used often enough, and has a long enough name, that the name is actually a pretty significant misfeature. This is a pretty core API, and both it and its precursors (getElementByID, etc.) are very commonly renamed by libraries precisely because you need a very short name for such a commonly used function. Why does it need a short name? If the name is too long to type then that's an argument for better IDEs. Otherwise you end up with stuff like strncpy to save typing. gzip eliminates the file size issue. I'm in agreement with Marat that find() is not as clear as most DOM APIs usually are. findBySelector() makes much more sense. - Elliott - E
[IndexedDB] Extracting keys and null/undefined
Consider an autoincrementing IDBObjectStore with keyPath foo.bar.
Which of the following (if any) should succeed?
1. objectStore.put({foo: null});
2. objectStore.put({foo: undefined});
3. objectStore.put({foo: {bar: null}});
4. objectStore.put({foo: {bar: undefined}});
By my reading of the spec, currently #1 and #2 succeed, and #3 and #4 do
not.
First, we look at the foo property on the object. All 4 objects have a foo
property. We take the value of the foo property and consider that further.
Then we look for a bar property. Because 'null' and 'undefined' do not
have that property, we return from step 5 of the steps for extracting a
key from a value using a key path with no value for #1 and #2. For #3 and
#4, we return the value of the bar property, null or undefined,
respectively.
IDBObjectStore.put throws if, among other conditions, the object store
uses in-line keys and the result of evaluating the object store's key path
yields a value and that value is not a valid key. Since null and
undefined are not valid keys, #3 and #4 are rejected, while #1 and #2 go on
to receive autogenerated keys.
IMO, this is not intuitive behavior.
- Kyle
