That is unfortunate. However, if we do make use of this, I believe we will just use the underlying tech as opposed to the code from the demo directly.
Thanks Justin On 2013-08-06, at 12:05 PM, "Richards, Jan" <[email protected]> wrote: > Interesting... > > Too bad the demo's not as accessible as it could be... in particular buttons > lack proper labels, keyboard shortcuts, nav mechanisms (other than TAB)... > but it's simple enough that perhaps these can be added fairly easily. > > Cheers, > Jan > > (MR) JAN RICHARDS > PROJECT MANAGER > INCLUSIVE DESIGN RESEARCH CENTRE (IDRC) > OCAD UNIVERSITY > > T 416 977 6000 x3957 > F 416 977 9844 > E [email protected] > >> -----Original Message----- >> From: [email protected] [mailto:fluid-work- >> [email protected]] On Behalf Of Justin Obara >> Sent: August-06-13 11:13 AM >> To: Antranig Basman >> Cc: [email protected] >> Subject: Re: Architectural Issues around Text to Speech >> >> I ran into this on "A List Apart" last night. >> http://www.barneyparker.com/world-simplest-html5-wysisyg-inline-editor/ >> >> Basically it outlines a lightweight HTML wysiwyg inline editor, using >> "contenteditable" and "execCommand". I wonder if we could harness >> "contenteditable" as an easy and/or quick start at implementing the >> functionality designed for the Text to Speech enactor and widget? >> >> "contenteditable" has fairly wide browser support. >> http://caniuse.com/contenteditable >> >> Thanks >> Justin >> >> On 2013-04-29, at 6:53 PM, Antranig Basman >> <[email protected]> wrote: >> >>> Hi Justin, Johnny - I believe the approach described here, by the estimable >> Haverbeke, will carry us a long way to a working implementation of arbitrary >> selectable text - as well as lighting the way forward to our general content >> authouring work in some upcoming project. The idea is to constantly >> maintain a hidden textarea node whose contents are "aligned" with the real >> DOM, and use the selection events which are fired by this, whilst just >> cosmetically updating the real DOM. Many more details here: >>> >>> http://marijnhaverbeke.nl/blog/browser-input-reading.html >>> >>> Cheers, >>> Antranig >>> >>> On 19/04/2013 10:45, Johnny Taylor wrote: >>>> Justin, >>>> >>>> "How do we make a selection" with the keyboard alone? That's a great >>>> question. My instinct is Shift > arrow key, but how will it know >>>> where to start? Firefox allows a user to use the cursor key to navigate >> within pages. And using Shift > arrow keys to select content as you use this >> key combo does work to select text. >>>> >>>> That's pretty powerful. Especially in this context. My question given >>>> this is could you mimic this behaviour programatically? To bring this >>>> feature to browsers that don't have this function? And turn it on when >> you enable the text to speech function in UIO? >>>> >>>> Not only would this be nice. I can't imagine another, more intuitive/ >> natural, way to do it. >>>> >>>> Johnny >>>> >>>> >>>> On 2013-04-19, at 10:39 AM, Justin Obara <[email protected] >> <mailto:[email protected]>> wrote: >>>> >>>> Yesterday afternoon we started talking and tasking out the work for >>>> implementing the text-to-speech feature in UI options. The notes from >> that meeting are up on the wiki. >>>> http://wiki.fluidproject.org/display/fluid/UI+Options+Text+to+Speech+ >>>> Tasking >>>> >>>> In looking through the designs, there are several architectural >>>> issues that have arisen. In the current designs, text-to-speech will >>>> read out the contents of a predesignated section on the page, likely >>>> the contents of the <article>. The user will be able to play and pause the >> reading, but also be able to select a portion of the text via, keyboard or >> mouse, to start reading from. This raises two high level questions. >>>> >>>> * How do we make a selection? >>>> * How do we start reading from that selection? >>>> * How do we know when a selection was made? >>>> >>>> >>>> How do we make a selection? >>>> ======================= >>>> >>>> Mouse: >>>> >>>> This is straight forward, and should likely be supported on any system that >> supports a mouse. >>>> >>>> >>>> Touch: >>>> >>>> This is also likely handled by any current OS that supports touch. >>>> >>>> >>>> Keyboard: >>>> >>>> We should be able to make use of the browsers built in caret >>>> navigation. Although this may require the user to enable it in the >>>> browsers settings. Safari and chrome (tested on mac os x) seem to >> behave the same, in that you have to first double click on a word before you >> can use the keyboard to modify the selection. >>>> However, this interaction from Safari and Chrome is not ideal, as the >>>> user would still have to use the mouse to start the selection. >>>> >>>> http://hkitago.com/2009/03/safari-and-caret-browsing/ >>>> http://windows.microsoft.com/en-CA/windows7/select-text-and-move- >> arou >>>> nd-a-webpage-with-your-keyboard >>>> >>>> >>>> How do we start reading from a that selection? >>>> ==================================== >>>> >>>> This question was particularly nebulous. We would have to know what >>>> was selected, what DOM node that selection was from, and where in that >> DOM node the selection came from. >>>> >>>> Example 1: >>>> >>>> <p> A fool thinks himself to be wise, but*a <strong>wise* >>>> man</strong> knows himself to be a fool.</p> >>>> >>>> In Example 1, suppose we select "*a <strong>wise**". *There are at >>>> least two potential issues 1) starting in the middle of the DOM node, and >> 2) crossing DOM nodes. >>>> >>>> >>>> Example 2: >>>> >>>> <p> Give every man *thy* ear, but few thy voice. <p> >>>> >>>> In Example 2, suppose we selected "*thy*". Since the word "thy" is >>>> contained within the text for the node multiple times, how would we >> know which one was correct? >>>> >>>> >>>> One possible would be to make use of window.getSelection(). This will >>>> provide us with a selection object that we can use to get the text >>>> selected as well as the node(s) that the selection starts and ends >>>> in. We should also be able to determine where in the DOM node the text >> selection is, making it possible to distinguish between multiple occurrences >> of the same text. >>>> >>>> https://developer.mozilla.org/en/docs/DOM/Selection >>>> http://blogs.msdn.com/b/ie/archive/2010/05/11/dom-range.aspx >>>> >>>> There is a question of browser support, particularly for IE 8 and >>>> below, but we might be able to find a polyfil to help with that. >>>> >>>> http://www.quirksmode.org/dom/range_intro.html >>>> http://code.google.com/p/rangy/ >>>> >>>> >>>> How do we know when a selection was made? >>>> ==================================== >>>> >>>> There doesn't seem to be any specific selection events that we could >>>> listen to. However we could probably use mouse presses, key presses >> and touch events to trigger a check of the selection object (see above). >>>> >>>> http://stackoverflow.com/questions/2859985/event-on-html-selection >>>> >>>> >>>> Thanks >>>> Justin >>>> _______________________________________________________ >>>> fluid-work mailing list - [email protected] >>>> <mailto:[email protected]> >>>> To unsubscribe, change settings or access archives, see >>>> http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work >>>> >>> >>> _______________________________________________________ >>> fluid-work mailing list - [email protected] To unsubscribe, >>> change settings or access archives, see >>> http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work >> >> _______________________________________________________ >> fluid-work mailing list - [email protected] To unsubscribe, change >> settings or access archives, see >> http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work > _______________________________________________________ > fluid-work mailing list - [email protected] > To unsubscribe, change settings or access archives, > see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
