Re: Bug 11239

I object to the inclusion of the following text in it's entirety, it is not part of the decision.


"Authors should avoid implementing text editing controls using the + canvas element. Doing so has a large number of + disadvantages:
+ +

+ +
Mouse placement of the caret has to be reimplemented. + +
Keyboard movement of the caret has to be reimplemented (possibly across lines, for multiline text input). + +
Scrolling of the text field has to be implemented (horizontally for long lines, vertically for multiline input). + +
Native features such as copy-and-paste have to be reimplemented. + +
Native features such as spell-checking have to be reimplemented. + +
Native features such as drag-and-drop have to be reimplemented. + +
Native features specific to the user, for example custom text + services, have to be reimplemented. This is close to impossible + since each user might have different services installed, and there + is an unbounded set of possible such services. + +
Bidirectional text editing has to be reimplemented. + +
Text selection has to be reimplemented. + +
Dragging of bidirectional text selections has to be reimplemented. + +
Platform-native keyboard shortcuts have to be reimplemented. + +
Platform-native input method editors (IMEs) have to be reimplemented. + +
Undo and redo functionality has to be reimplemented. + +
Accessibility features such as magnification following the + caret or selection have to be reimplemented. + + 

+ +

This is a huge amount of work, and authors are most strongly + encouraged to avoid doing any of it by instead using the + input element, the textarea element, or + the contenteditable + attribute.
+ +

Authors that eschew these existing solutions and instead take on + the monumental task of implementing a text editor from scratch"

I would not object to the following ONLY:

"Authors should avoid implementing text editing controls using the + canvas element. Doing so has a large number of + disadvantages"


Sent from my iPhone

On 29 Apr 2011, at 00:55, Maciej Stachowiak <mjs@apple.com> wrote:

> 
> 
> Hi everyone,
> 
> Thanks to Ian for providing this sample patch, and to Richard for reviewing. Also thanks to everyone else participating in the discussion.
> 
> One thing I'd like to request for the conversation going forward. Some of the discussion has been focused on "I agree with this / think this is correct" vs "I disagree with this / think this is incorrect". For now, I'd like to ask discussion of the patch to focus on "This follows from the Decision and Change Proposal" vs "This does not follow from the Decision and Change Proposal".
> 
> To be more specific:
> 
> - If there is something in this diff that is clearly required by the Decision that you don't like, then please don't object to the diff. The proper channels for expressing disagreement with the Decision would be to raise a Formal Objection, or to provide new information and make a request to reopen the issue based on new information. An example of this are the objections to including the blink rate API. This is clearly required. If you have new information that would lead to reconsidering this issue, then you should be asking for reconsideration of the Decision, not the diff.
> 
> - If there is something in this diff that is clearly contrary to the Decision that you *do* like, then please don't argue for including it in the diff. The proper channels for expressing disagreement with the Decision would be to raise a Formal Objection, or to provide new information and make a request to reopen the issue based on new information.
> 
> - If there is anything in the diff which is neither forbidden or required by the Decision, then it can be included if there is consensus to combine it with landing the diff, but if anyone objects, it seems that it would be simpler to submit such changes separately. An example of this would be the text describing issues that may come up for anyone implementing text editing using Canvas. The Decision and Change Proposal don't say anything about adding or not adding such text. If there isn't a quick consensus, it seems that it would be simpler to pursue that change separately, for instance by filing a bug..
> 
> 
> Note: I do not mean to imply that Ian specifically is not following these guidelines; this just seemed like a convenient message to reply to.
> 
> 
> Regards,
> Maciej
> 
> 
> 
> On Apr 28, 2011, at 11:25 AM, Ian Hickson wrote:
> 
>> 
>> Just prior to seeing this e-mail I posted an updated patch to the bug:
>> 
>> http://www.w3.org/Bugs/Public/attachment.cgi?id=980
>> 
>> 
>> On Thu, 28 Apr 2011, Benjamin Hawkes-Lewis wrote:
>>>> 
>>>> In the agreed on change proposal getCaretBlinkPeriod should return a 
>>>> value less than zero if no operating system setting exists. Ian 
>>>> removed that from the chairs decision.
>>> 
>>> Yes, I'm not sure of Ian's rationale here.
>> 
>> The chairs asked me to apply the bullet points here:
>> 
>> http://www.w3.org/html/wg/wiki/ChangeProposals/CaretSelection#Details
>> 
>> ...except for bullets 2 and 6. None of these bullets mention anything 
>> about "no operating system setting" existing. I have no idea what this 
>> would even mean. Is there an example of this somewhere?
>> 
>> 
>>> Ian: could we perhaps specify to return -1 in this case?
>> 
>> What case is this case, exactly? An example would be most helpful.
>> 
>> 
>>> * Ian's patch is less detailed in its suggestion of how focus notification
>>>  should be approached, whereas your list suggests that a best fit
>>>  rectangle on
>>>  screen should be created and surfaced in the accessibility tree. I suppose
>>>  vagueness provides for accessibility APIs that can understand
>>>  non-rectangular
>>>  areas. Ian, could we perhaps include the best fit rectangle approach as just
>>>  as an example?
>> 
>> The best-fit approach text in the proposed patch is completely 
>> meaningless. I have no idea what was even _intended_ by the text. If 
>> someone could explain what it means, I would be happy to make sure the 
>> spec fully defines whatever is appropriate.
>> 
>> 
>>> * Ian's patch tries to ensure notification about change of focus happens
>>>  after drawing the focus ring (potentially in the next event loop), whereas
>>>  in your list the notification happens *before* drawing the focus ring
>>>  (presumably preventing progress to the next event loop). Is this a bad
>>>  change?
>> 
>> It's a required change; the alternative is that every time the UA draws 
>> the focus ring and then the caret the magnifier would blink around 
>> creating exactly the kind of situation that might lead to seizures, which 
>> is what a big part of this patch is about avoiding.
>> 
>> -- 
>> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
>> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
>> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>> 
> 
>