Re: contentEditable=minimal
On May 23, 2014, at 5:19 , Robin Berjon wrote: > Which brings me to think: when we discussed this at the Summit, there was > some agreement (between all four of us :) that it was a good idea to support > multi-range selections. These are useful not just for tables, but also for > bidi. The reason for the latter is that when selecting a line with multiple > embedded directions (using a mouse), you want to have the visual selection be > an unbroken line (as opposed to the crazy jumping around you get if you > follow logical order). Were any speakers of bidirectional languages in the room when this was discussed? Norbert
[selectors-api] Reference to obsolete ECMAScript Language spec version
The current drafts of the Selectors API specifications [1, 2, 3] refer to the third edition of the ECMAScript Language Specification, published 1999, although with a URL that is now home to edition 5.1, published 2011 [4]. Is there a reason to still reference the old version, or can the reference be updated to the current version? BTW, an HTML version of the ECMAScript Language Specification is now available for reference [5]. Norbert [1] http://www.w3.org/TR/selectors-api/ [2] http://dev.w3.org/2006/webapi/selectors-api/ [3] http://dev.w3.org/2006/webapi/selectors-api2/ [4] http://www.ecma-international.org/publications/standards/Ecma-262.htm [5] http://www.ecma-international.org/ecma-262/5.1/
[selectors-api] Comment on Interoperability Considerations
Dear Web Apps WG,
I've reviewed the Selectors API [1], and have one comment:
The Interoperability Considerations section states that in certain
cases "such implementations could return different results from those
that do support them". While this is a non-normative section, just
referring to "different results" seems a bit too vague and is not
really helpful for applications relying on the specification. Even
more worrying, after reading the rest of the specification and the
underlying Selectors specification [2] I can still not tell what the
intended behavior is. The Selectors specification introduces Profiles,
which indicate which selectors are supported ("accepted") by a
specification using Selectors, but it neither introduces a similar
concept for implementations, nor does it seem to specify the behavior
resulting from the use of selectors that are not supported by a
specification or an implementation.
I would expect the specification to prescribe
- either that the implementation raises an exception when given a
selector that it doesn't support,
- or that the implementation return null (for querySelector) or an
empty list (for querySelectorAll) when given a selector that it
doesn't support.
Best regards,
Norbert Lindenberg
[1] http://www.w3.org/TR/2008/WD-selectors-api-20081114/
[2] http://www.w3.org/TR/2005/WD-css3-selectors-20051215/
