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
> 
> 


Reply via email to