Re: [Editing] Splitting Selection API Into a Separate Specification
I've uploaded the first cut the selection API specification unofficial draft at https://github.com/rniwa/selection-api I've modernized and rephrased the text; e.g. the spec refers to browsing context instead of defaultView, and defines selection's range being null as being empty. Finally, I've turned all Aryeh's comments and notes into notes that are visible. We can remove those comments as we solidify the spec. and get implementation reports. As mentioned in the spec (thanks to Aryeh), there are 11 serious open issues in the current draft. The most serious one is that stringification of selection is completely undefined due to its dependency on innerText, which in turn is also undefined. Given defining innerText is completely outside the scope of the selection API specification, we might need to defer this part to a level 2 specification since the only alternative is to wait for someone to write a innerText spec. While I completely forgot to mention at F2F today, I'm looking for a test facilitator. Aryeh has already written some tests in https://dvcs.w3.org/hg/editing/raw-file/tip/selecttest/ so he/she just needs to import those into web-platfrom-tests repository on github, and modernize them as needed. - R. Niwa On Mar 13, 2014, at 4:43 PM, Ryosuke Niwa rn...@apple.com wrote: Hi, It appears that there is a lot of new features such as CSS regions and shadow DOM that have significant implications on selection API, and we really need a spec. for selection API these specifications can refer to. Thankfully, Aryeh has done a great work writing the spec. for selection API as a part of HTML Editing APIs specification [1] but no browser vendor has been able to give meaningful feedback or has implemented the spec due to the inherent complexity in HTML editing. As a result, the specification hasn't made much progress towards reaching Last Call or CR. Given the situation, I think it's valuable to extract the parts of the spec that defines selection API into its own specification and move it forward in the standards process so that we can make it more interoperable between browsers, and let CSS regions, shadow DOM, and other specifications refer to the specification. Any thoughts and opinions? [1] https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html - R. Niwa
RE: [Editing] Splitting Selection API Into a Separate Specification
From: Ryosuke Niwa [mailto:rn...@apple.com] Given defining innerText is completely outside the scope of the selection API specification, we might need to defer this part to a level 2 specification since the only alternative is to wait for someone to write a innerText spec. I don't know all the history here, but this bug and proto-spec seems relevant: - https://www.w3.org/Bugs/Public/show_bug.cgi?id=13145 - https://web.archive.org/web/20121127212525/http://aryeh.name/spec/innertext/innertext.html The work already done on this might make including innerText-dependent features more feasible.
Re: [Editing] Splitting Selection API Into a Separate Specification
On 4/10/14 11:41 PM, ext Ryosuke Niwa wrote: I've uploaded the first cut the selection API specification unofficial draft at https://github.com/rniwa/selection-api Wow, that was quick; thanks! To facilitate review, I think it would be helpful if you would please create a `directly readable` version (f.ex. use GH pages to create something like http://rniwa.github.io/selection-api.html). WDYT? -Thanks, AB
CfC: publish FPWD of Service Workers; deadline April 18
Alex and Jungkee propose WebApps publish a First Public Working Draft of Service Workers and this is a Call for Consensus to do so, using the following Editor's Draft as the basis: http://slightlyoff.github.io/ServiceWorker/spec/service_worker/ This CfC satisfies the group's requirement to record the group's decision to request advancement. 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. If you have any comments or concerns about this CfC, please reply to this e-mail by April 18 at the latest. Positive response is preferred and encouraged, and silence will be considered as agreement with the proposal. -Thanks, AB
Re: [Editing] Splitting Selection API Into a Separate Specification
Done: http://rniwa.github.io/selection-api.html On Apr 11, 2014, at 7:35 AM, Arthur Barstow art.bars...@nokia.com wrote: On 4/10/14 11:41 PM, ext Ryosuke Niwa wrote: I've uploaded the first cut the selection API specification unofficial draft at https://github.com/rniwa/selection-api Wow, that was quick; thanks! To facilitate review, I think it would be helpful if you would please create a `directly readable` version (f.ex. use GH pages to create something like http://rniwa.github.io/selection-api.html). WDYT? -Thanks, AB
[Bug 25329] New: Do not allow locking to angles
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25329 Bug ID: 25329 Summary: Do not allow locking to angles Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Screen Orientation Assignee: mou...@lamouri.fr Reporter: mou...@lamouri.fr QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Mozilla and Microsoft would prefer if locking could only be done on orientation types. There is no strong use cases for that and it can always be added later so it should be fine to change. There is still the question of whether we should be able to lock to '0' (ie. 'native'). -- You are receiving this mail because: You are on the CC list for the bug.
Spec'ing innerText (Was Re: [Editing] Splitting Selection API Into a Separate Specification)
On Apr 11, 2014, at 7:09 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Ryosuke Niwa [mailto:rn...@apple.com] Given defining innerText is completely outside the scope of the selection API specification, we might need to defer this part to a level 2 specification since the only alternative is to wait for someone to write a innerText spec. I don't know all the history here, but this bug and proto-spec seems relevant: - https://www.w3.org/Bugs/Public/show_bug.cgi?id=13145 - https://web.archive.org/web/20121127212525/http://aryeh.name/spec/innertext/innertext.html The work already done on this might make including innerText-dependent features more feasible. Thanks for the pointer. Unfortunately, we might need to take a slightly different approach more based on the CSS box tree because whitespace collapsing, etc... are defined in CSS2.1 and CSS level 3 specifications. - R. Niwa
[Bug 25314] screen.orientation.angle should be an unsigned short
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25314 Mounir Lamouri mou...@lamouri.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Mounir Lamouri mou...@lamouri.fr --- https://dvcs.w3.org/hg/screen-orientation/rev/2c7b0a46fe3e -- You are receiving this mail because: You are on the CC list for the bug.
Re: CfC: publish FPWD of Service Workers; deadline April 18
On 11/04/2014 08:44, Arthur Barstow art.bars...@nokia.com wrote: Alex and Jungkee propose WebApps publish a First Public Working Draft of Service Workers and this is a Call for Consensus to do so, using the following Editor's Draft as the basis: http://slightlyoff.github.io/ServiceWorker/spec/service_worker/ This CfC satisfies the group's requirement to record the group's decision to request advancement. 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. If you have any comments or concerns about this CfC, please reply to this e-mail by April 18 at the latest. Positive response is preferred and encouraged, and silence will be considered as agreement with the proposal. -Thanks, AB Fully support publishing a FPWD. Dan This electronic message contains information from Telefonica UK or Telefonica Europe which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email. Switchboard: +44 (0)113 272 2000 Email: feedb...@o2.com Telefonica UK Limited 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 1743099. VAT number: GB 778 6037 85 Telefonica Europe plc 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 05310128. VAT number: GB 778 6037 85 Telefonica Digital Limited 260 Bath Road, Slough, Berkshire SL1 4DX Registered in England and Wales: 7884976. VAT number: GB 778 6037 85
[Bug 25053] Specify clear security requirements
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25053 Mounir Lamouri mou...@lamouri.fr changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Mounir Lamouri mou...@lamouri.fr --- https://github.com/w3c/screen-orientation/commit/fe334b38accdf01d2ab6c42a0863921ab80aed1b -- You are receiving this mail because: You are on the CC list for the bug.
[April2014Meeting] Draft minutes for April 11
The Draft minutes from WebApps' April 11 f2f meeting are at the following and copied below: http://www.w3.org/2014/04/11-webapps-minutes.html Corrections, comments, etc., are welcome. Thanks very much to the various scribes and special thanks to Kris for handing me the missing minutes. W3C - DRAFT - WebApps f2f Meeting (San Jose CA US) 11 Apr 2014 Agenda See also: IRC log Attendees Present anssik, [Paypal], +1.301.460., Arnaud_Braud, Takeshi_Yoshino, krisk, dglazkov, israel, hilerio, Art_Barstow, Anssi_Kostiainen, Ali_Alabbas, Yves_Lafon, Chris_Wilson, israel_hilerio, Feras_Moussa, MichaelTmSmith, John_Hazen, Matt_Falkenhagen, Ben_Peters, Adrian_Bateman, Hayato_Ito, Zhiqiang_Zhang, Olivier_Potonniee, Gene_Lian, Jungkee_Song, Maciej, Laszlo_Gombos, Alex_Russell Regrets Chair ArtB Scribe Art, israelh, Ali, krisk, Yves, BenjamP, slightlyoff Contents Topics Web Components Custom Elements Shadow Dom imports conclusion Summary of Action Items ArtB ScribeNick: ArtB scribe Scribe: Art dglazkov http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0074.html smaug hello all Web Components adrianba scribe: israelh dglazkov: Would like to break down discussion into three topics: Shadow DOM, Custom Elements, and HTML Imports ... Shadow DOM is the more interesting. Let's pick which one we want to discuss first. ... Start with Custom Elements ? ... Shadow DOM after that? ... Custom elements is in first draft ArtB https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html - Custom Elements Editor's Draft dglazkov https://www.w3.org/Bugs/Public/show_bug.cgi?id=24578 dglazkov: And interesting topic to start with 24578 buhg ... Registering a register primitive ... Having the ability to expose internal attributes on Customer elements allow you to clone it, assing it to a different document ArtB https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567#c69 - Anne's comment #69 for bug 20567 dglazkov: The idea is that when an element is adopted from one doc to another, and as an an author of the element you will get a callback that allows you to reason about the attribute being used in other elements ... also, the idea that you could use the registry as a way to scope the element names. ... a web developer has a sub-tree in their document and would like to parse their specific elements from the local registry. Having a scoping concept would be very useful for them. However, if you want to rountrip when coming back form the parse you would have problems ... because when you serialize the tree the parse would have no idea of where that element came from, thus surprising. ... I would like to introduce the registry concept into the spec and see where it goes from there. ... I want to allow allowNode callback to reason about registries. ... I would like to get everyone's opinion about it. rniwa: What is the use case for the callback. dglazkov: deeper into this subject. IE and FF have a behavior that is different from blink and WebKit and their prototype when it is adopted from another doc. ... IE and FF when you are adopted from one doc to another, you loose your old prototypes. Blink and WebKit don't do that. ... there is disagrements whether this should be on spec. ... the callback we are discussing provides a mechanism to allow elements to update the prototypes dynamically. Thus, becoming and implementation detail instead of part of the spec. rniwa: it might be more useful to standardize the UA behaviors instead of putting this on the hands of the devs. dglazkov: for custom elements this decision is not so clear. It is not always clear what is the right behavior. Specially if the definintion of my element is not defined on the new environment. ... element foo may colide with a different definition of another element foo on that document. rniwa: it seems strange that each doc would behave diff on each environment. It doesn't allow you to reason about the custom element on the environment that is being used. dglazkov: this seems bad if you don't have the ability to reason about the custom elements diff. adrianba: it would be bad. rniwa: it seems like we need to figure out how we can guarantee that the custom element keeps the same information across document. Maybe this is the issue. dglazkov: that is what registers let you do. You can look at the registry and reason about this. rniwa: potentially you can have a global map for each page. that checks if the definition of the class has been raised and possibly rejected. Some type of consistency check. ... we probably don't want to reason about having different custom elements that are of the same expected type. dglazkov: the thing is that it doesn't have to be the case, the problem is that the scenario could happen and we need to figure out how to deal with this. rniwa: for ex. you can imagine the registry happening about all in one script context, within one navigation.
Re: [Editing] Splitting Selection API Into a Separate Specification
On 4/11/14 10:09 AM, Domenic Denicola wrote: - https://www.w3.org/Bugs/Public/show_bug.cgi?id=13145 - https://web.archive.org/web/20121127212525/http://aryeh.name/spec/innertext/innertext.html The outcome of that was basically that the WebKit folks wanted innerText to be some sort of complicated prettyprinting thing (which is nothing like the spec linked above) while Gecko was not all that interested in implementing a complicated prettyprinting thing that wouldn't even be compatible with other browsers' complicated prettyprinting things. The work already done on this might make including innerText-dependent features more feasible. innerText is not particularly interoperable even across UAs that implement it, last I checked -Boris
