Re: Bug 11239

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.   `._.-(,_..'--(,_..'`-.;.'
>

Received on Thursday, 28 April 2011 23:56:07 UTC