RE: [selection] Selection.setBaseAndExtent

[Ben Peters]

?This API is already used on the web so we should probably keep it as-is.



From: James M. Greene 
Sent: Tuesday, August 5, 2014 4:58 PM
To: Ben Peters
Cc: Ryosuke Niwa; public-webapps
Subject: RE: [selection] Selection.setBaseAndExtent


For consistent terminology with the rest of the API, shouldn't it be 
`setAnchorAndFocus`?

Sincerely,
James Greene
Sent from my [smart?]phone

On Aug 5, 2014 5:54 PM, "Ben Peters" 
mailto:ben.pet...@microsoft.com>> wrote:
I have added proposed text to this bug. Any objections to this?

Proposed text, based on the text for collapse():

void setBaseAndExtent (Node baseNode, unsigned long baseOffset, Node 
extentNode, unsigned long extentOffset);

The method must throw an IndexSizeError exception if offset is negative or 
longer than node's length ([DOM4]). Otherwise, it must create a new range, set 
([DOM4]) its start to (baseNode, baseOffset) and its and end to (extentNode, 
extentOffset), and set the context object's range to the newly-created range.

From: Ben Peters
Sent: Tuesday, May 20, 2014 11:37 AM
To: Ben Peters; Ryosuke Niwa; 
public-webapps@w3.org
Subject: RE: [selection] Selection.setBaseAndExtent

I have filed a bug to track this issue [1].

Ben

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25831


From: Ben Peters [mailto:ben.pet...@microsoft.com]
Sent: Monday, May 5, 2014 11:28 PM
To: Ryosuke Niwa; public-webapps@w3.org
Subject: [selection] Selection.setBaseAndExtent

I noticed that some websites use selection.setBaseAndExtent [1]. According to 
what limited documentation I could find, it works similar to selection.extend. 
Is there any intention to standardize this, or is it made obsolete by 
selection.extend?

Ben

[1] 
http://stackoverflow.com/questions/985272/jquery-selecting-text-in-an-element-akin-to-highlighting-with-your-mouse

RE: [selection] Selection.setBaseAndExtent

[James M. Greene]

For consistent terminology with the rest of the API, shouldn't it be
`setAnchorAndFocus`?

Sincerely,
James Greene
Sent from my [smart?]phone
On Aug 5, 2014 5:54 PM, "Ben Peters"  wrote:

>  I have added proposed text to this bug. Any objections to this?
>
>
>
> Proposed text, based on the text for collapse():
>
>
>
> void setBaseAndExtent (Node baseNode, unsigned long baseOffset, Node
> extentNode, unsigned long extentOffset);
>
>
>
> The method must throw an IndexSizeError exception if offset is negative or
> longer than node's length ([DOM4]). Otherwise, it must create a new range,
> set ([DOM4]) its start to (baseNode, baseOffset) and its and end to
> (extentNode, extentOffset), and set the context object's range to the
> newly-created range.
>
>
>
> *From:* Ben Peters
> *Sent:* Tuesday, May 20, 2014 11:37 AM
> *To:* Ben Peters; Ryosuke Niwa; public-webapps@w3.org
> *Subject:* RE: [selection] Selection.setBaseAndExtent
>
>
>
> I have filed a bug to track this issue [1].
>
>
>
> Ben
>
>
>
> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25831
>
>
>
>
>
> *From:* Ben Peters [mailto:ben.pet...@microsoft.com
> ]
> *Sent:* Monday, May 5, 2014 11:28 PM
> *To:* Ryosuke Niwa; public-webapps@w3.org
> *Subject:* [selection] Selection.setBaseAndExtent
>
>
>
> I noticed that some websites use selection.setBaseAndExtent [1]. According
> to what limited documentation I could find, it works similar to
> selection.extend. Is there any intention to standardize this, or is it made
> obsolete by selection.extend?
>
>
>
> Ben
>
>
>
> [1]
> http://stackoverflow.com/questions/985272/jquery-selecting-text-in-an-element-akin-to-highlighting-with-your-mouse
>

Re: IndieUI Teleconference Agenda; 6 August at 21:00Z for 60 minutes

[Janina Sajka]

Ben, All:

As we're progressing in our discussions about working jointly, allow me
to invite you to the next Indie-UI teleconference as detailed below.
Please feel free to join us on this call, or any following call to
discuss our mutual interests. This is simply another opportunity to
advance our discussions, and you will be most welcome, should you be
able to join us.

Janina, Indie-UI Chair

Janina Sajka writes:
What:   IndieUI Task Force Teleconference
When:   Wednesday 6 August
 2:00 PMSan Francisco -- U.S. Pacific (Daylight) Time   (PDT: 
UTC -7)
 4:00 PMAustin -- U.S. Central (Daylight) Time   (CDT: UTC -5)
 5:00 PMBoston -- U.S. Eastern (Daylight) Time  (EDT: 
UTC -4)
10:00 PMLondon -- British (Summer) Time (BST: 
UTC +1)
11:00 PMParis -- Central European Time  (CET: UTC +2)
 5:00 AMBeijing -- China Standard Time  (Thursday, 7 
August CST: UTC +8)
 6:00 AMTokyo -- Japan Standard Time  (Thursday, 7 
August JST: UTC +9)
 7:00 AMMelbourne -- Australian Eastern (Standard) Time 
 (Thursday 7 August AEST: UTC +10)
Where:  W3C Teleconference--See Below

* Time of day conversions

Please verify the correct time of this meeting in your time zone using
the Fixed Time Clock at:

http://timeanddate.com/worldclock/fixedtime.html?msg=IndieUI+Teleconference&iso=20140806T1700&p1=43&ah=1

** Preliminary Agenda for IndieUI Task Force Teleconference 6 August 2014

Meeting: IndieUI Task Force Teleconference
Chair: Janina_Sajka
agenda+ preview agenda with items from two minutes
agenda+ TPAC 2014 http://www.w3.org/2014/11/TPAC/
agenda+ Editor's Report
agenda+ Open Items with Web Apps' Editing TF [See below]
agenda+ Testing Conversation; Polyfills
agenda+ User Context Issues & Actions 
https://www.w3.org/WAI/IndieUI/track/products/3
agenda+ Events Issues & Actions https://www.w3.org/WAI/IndieUI/track/products/2
agenda+  Other Business
agenda+ Be Done

Resource: IndieUI Minutes
http://www.w3.org/2014/07/23-indie-ui-minutes.html

Resource: Web Apps Editing TF
Minutes:http://www.w3.org/2014/07/11-webapps-minutes.html
Explainer:  http://w3c.github.io/editing-explainer/commands-explainer.html

Resource: For Reference
Home Page:  http://www.w3.org/WAI/IndieUI/
Email Archive:  http://lists.w3.org/Archives/Public/public-indie-ui/

Resource: Teleconference Logistics
Dial the Zakim bridge using either SIP or the PSTN.
PSTN: +1.617.761.6200 (This is a U.S. number).
SIP: za...@voip.w3.org
You should be prompted for a pass code,
This is
46343#
(INDIE#)

Alternatively, bypass the Zakim prompts and SIP directly into our
teleconference.
SIP: 0046...@voip.w3.org

Instructions for connecting using SIP:
http://www.w3.org/2006/tools/wiki/Zakim-SIP
Place for users to contribute additional VoIP tips.
http://www.w3.org/2006/tools/wiki/Zakim-SIP-tips

IRC: server: irc.w3.org, channel: #indie-ui.

During the conference you can manage your participation with Zakim
commands as follows:
   61# to mute yourself
   60# to unMute yourself
   41# to raise your hand (enter speaking queue)
   40# to lower your hand (exit speaking queue)

The system acknowledges these commands with a rapid, three-tone
confirmation.  Mobile phone users especially should use the mute
function
if they don't have a mute function in their phone.  But the hand-raising
function is a good idea for anyone not using IRC.

* IRC access

An IRC channel will be available. The server is
irc.w3.org,
The port number is 6665 (Note this is not the normal default) and
The channel is #indie-ui.

* Some helpful Scribing and Participation Tips
http://www.w3.org/WAI/PF/wiki/Teleconference_cheat_sheet

For more on the IRC setup and the robots we use for agenda and speaker
queuing and for posting the log to the web, see:

- For RRSAgent, that captures and posts the log with special attention
to action items:
http://www.w3.org/2002/03/RRSAgent

- For Zakim, the IRC interface to the bridge manager, that will
maintain speaker and agenda queues:
http://www.w3.org/2001/12/zakim-irc-bot

- For a Web gateway to IRC you can use if your network administrators
forbid IRC, see:
http://www.w3.org/2001/01/cgi-irc

- For more on W3C use of IRC see:
http://www.w3.org/Project/IRC/

-- 

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
IndieUI http://www.w3.org/WAI/IndieUI/

RE: [selection] Selection.setBaseAndExtent

[Ben Peters]

I have added proposed text to this bug. Any objections to this?

Proposed text, based on the text for collapse():

void setBaseAndExtent (Node baseNode, unsigned long baseOffset, Node 
extentNode, unsigned long extentOffset);

The method must throw an IndexSizeError exception if offset is negative or 
longer than node's length ([DOM4]). Otherwise, it must create a new range, set 
([DOM4]) its start to (baseNode, baseOffset) and its and end to (extentNode, 
extentOffset), and set the context object's range to the newly-created range.

From: Ben Peters
Sent: Tuesday, May 20, 2014 11:37 AM
To: Ben Peters; Ryosuke Niwa; public-webapps@w3.org
Subject: RE: [selection] Selection.setBaseAndExtent

I have filed a bug to track this issue [1].

Ben

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25831


From: Ben Peters [mailto:ben.pet...@microsoft.com]
Sent: Monday, May 5, 2014 11:28 PM
To: Ryosuke Niwa; public-webapps@w3.org
Subject: [selection] Selection.setBaseAndExtent

I noticed that some websites use selection.setBaseAndExtent [1]. According to 
what limited documentation I could find, it works similar to selection.extend. 
Is there any intention to standardize this, or is it made obsolete by 
selection.extend?

Ben

[1] 
http://stackoverflow.com/questions/985272/jquery-selecting-text-in-an-element-akin-to-highlighting-with-your-mouse

Screen Orientation Feedback

[Jonas Sicking]

Hi All,

I think the current interaction between the screen orientation and
device orientation specs is really unfortunate.

Any time that you use the device orientation in order to render
something on screen, you have to do non-obvious math in order to get
coordinates which are usable. Same thing if you want to use the device
orientation events as input for objects which are rendered on screen.

I would argue that these are the by far most common use cases for

I agree that the main problem here is that the deviceorientation spec
defined that their events should be relative to the device rather than
to the screen. However we can still fix the problem by simply adding

partial interface DeviceOrientationEvent
{
  readonly attribute double? screenAlpha;
  readonly attribute double? screenBeta;
  readonly attribute double? screenGamma;
}

No new events needs to be defined.

I guess we can argue that this should be added to the
DeviceOrientation spec, but that seems unlikely to happen in practice
anytime soon. I think we would do developers a disservice by blaming
procedural issues rather than trying to solve the problem.

I think mozilla would be happy to implement such an addition to the
DeviceOrientation event (I'm currently checking to make sure). Are
there other UAs that have opinions (positive or negative) to such an
addition?

/ Jonas

Re: Screen orientation API feedback

[Marcos Caceres]

On August 5, 2014 at 6:33:46 AM, Anne van Kesteren (ann...@annevk.nl) wrote:



This is great feedback - thanks for this Anne! I've captured each of the issues 
you raised in the bug tracker on GH [1] (and cc'ed you on them). We will 
address them in the next few days. 

https://github.com/w3c/screen-orientation/issues/ 

Re: File API: reading a Blob

[Anne van Kesteren]

Sorry for the late response Arun. I blame vacation and not being quite
sure how we should solve this taking into account the legacy
consumers.

On Thu, Jul 17, 2014 at 2:58 PM, Arun Ranganathan  wrote:
> There are two questions:
>
> 1. How should FileReaderSync behave, to solve the majority of use cases?
> 2. What is a useful underlying abstraction for spec. authors that can be 
> reused in present APIs like Fetch and future APIs?

I'm not sure.


>>> We agreed some time ago to not have partial data.
>>
>> Pointer? I also don't really see how that makes sense given how
>> asynchronous read would perform.
>
> Well, the bug that removed them is: 
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=23158 and dates to last year.
>
> Problems really include decoding strings according to the encoding 
> determination for incomplete Blobs:
>
> http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0063.html
>
> Another thread covered deltas in progress events:
>
> http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/0069.html
>
> I don’t have pointers to IRC conversations, but:
>
> 1. Decoding was an issue with *readAsText*. I suppose we could make that 
> method alone be all or nothing.

Well a synchronous readAsText would presumably operate on the bytes
returned. What that would do is clearly defined.


>> Yeah, I now think that we want something even lower-level and build
>> the task queuing primitive on top of that. (Basically by observing the
>> stream that is being read and queuing tasks as data comes in, similar
>> to Fetch. The synchronous case would just wait for the stream to
>> complete.
>
> If I understand you correctly, you mean something that might be two-part 
> (some hand waving below, but …):
>
>  To read a Blob object /blob/, run these steps:
>
>  1. Let /s/ be a new buffer.
>
>  2. Return /s/, but continue running these steps asynchronously.
>
>  3. While /blob/'s underlying data stream is not closed, run these
> substeps:
>
> 1. Let /bytes/ be the result of reading a chunk from /blob/'s
>underlying data.
>
> 2. If /bytes/ is not failure, push /bytes/ to /s/ and set
>/s/'s transmitted to /bytes/'s length.
>
> 3. Otherwise, signal some kind of error to /s/ and terminate
>these steps.
>
> AND
>
> To read a Blob object with tasks:
>
> 1. Run the read a Blob algorithm above.
> 2. When reading the first /bytes/ queue a task called process read.
> 3. When pushing /bytes/ to /s/, queue a task called process read data.
> 4. When all /bytes/ are pushed to /s/ queue a task called process read EOF.
> 5. If an error condition is signaled queue a task called process error with a 
> failure reason.
>
> Is “chunk” implementation defined? Right now we assume 1 byte or 50ms. 
> “Chunk” seems a bit hand-wavy and hard to enforce, but… it might be the right 
> approach.

Would have to discuss with Domenic, but something like chunks seems to
be much closer to how these things actually work.


-- 
http://annevankesteren.nl/

Screen orientation API feedback

[Anne van Kesteren]

"Unless stated otherwise, the term screen is ..." Does it ever state
otherwise? Please remove the conditional if not.


"a Promise object whose associated task" Instead of "task" use a word
like "operation" so readers are not confused with the event loop from
HTML.


"Unless specified otherwise, when queuing a task, ..." You never state
otherwise. I would ask you to remove the conditional, but I think
screen orientation changes ought to be relayed during the "animation
frame task". See
http://lists.w3.org/Archives/Public/www-dom/2014JulSep/0061.html for
context.


"the values of type and angle will be strongly linked" It might be
better to talk about the abstract underlying concepts here as type and
angle have no values. They have getters. Also, shouldn't these values
be updated based on the animation frame task rather then return
something when reading them? It seems doing the operation on reading
creates racing issues, e.g. no guarantee that obj.angle === obj.angle,
and might cause some amount of locking.


Rather than using DOMException, can we simply use JavaScript's
TypeError? What we want with DOMException hasn't been figured out and
using TypeError works just as well. Or are there scenarios here where
you want branching based on the exception? That would be interesting
to know.


"apply an orientation lock" has no information about context. E.g.
what document are we talking about here? That could be more explicit.
That it has to be a top-level browsing context's document is also
unclear.


"Set pending promise to be null." To be or not to be? "to null" would be better.


"If the active orientation lock is not the current orientation lock"
how does this work given that at least current orientation lock is a
list? (It would help to rename these variables to more clearly
indicate what is a list. That might also help avoid such errors.


The way the task queuing happened is also bad by the way. You are
queuing a task to perform an asynchronous operation (locking). You
first want to change the orientation and only then queue a task (well,
do something with the animation frame task) to synchronize state.


"fullscreen enabled flag has been set (i.e., when the document is in
fullscreen)" I think you misunderstand the fullscreen enabled flag. It
does not mean this.


"Fire a simple event named change at each screen.orientation object."
This needs to talk about the actual objects or you need to ensure you
talk about resolving this reference before any developer code got a
handle on the screen reference, let alone the orientation reference.
Typically you would enumerate the objects somehow.


(Sorry for not having all of it in order and for it being incomplete.
Will review again once the major pieces have been reshuffled to be
correct.)


-- 
http://annevankesteren.nl/