How's this sound for a proposal to wrap all this up, then:- Drop the public
DisclosureHeader class, as Ray suggested earlier.
- Implement the <g:header/><g:body/> version of the parser (I agree it's
probably clearer).
- Create a separate issue (possibly eclipsing issue 1449, possibly simply
clarifying it), that captures the desire to be able to add focusable widgets
to the header without conflicting with the anchor.

?

On Wed, Oct 14, 2009 at 12:55 PM, Ray Ryan <[email protected]> wrote:

> Thomas, this all makes sense but I don't think we can make it happen for
> 2.0. Certainly not MS2, and probably not for the RC (though it's tempting,
> DisclosurePanel is so close to being so much more useful). Do you mind
> creating an issue on the public tracker capturing this?
>
>
> On Wed, Oct 14, 2009 at 9:45 AM, <[email protected]> wrote:
>
>> On 2009/10/14 15:43:38, jgw wrote:
>>
>>> Broadly, I'm not entirely sure what we're trying to achieve by
>>>
>> promoting
>>
>>> DisclosurePanelHeader to a public top-level class. It's pretty
>>>
>> complex, for a
>>
>>> seemingly simple problem. If you were to replace it wholesale within
>>>
>> an
>>
>>> application, you will pretty much be replacing the entire widget.
>>>
>>
>>  It seems that being able to (a) replace the images, and (b) replace
>>>
>> the header
>>
>>> contents with an arbitrary widget, would handle all reasonable
>>>
>> use-cases.
>>
>> Say I want to add an "online indicator" as in the chat panel in GMail?
>> or I want to add a button in the header (my use case: I have a
>> disclosure panel for data filters, much similar to GMail saved searches
>> or labels, and initially I'd have liked to put the "create filter"
>> button in the header, but that would have meant re-implementing the
>> image toggle, so I gave up in included it within the disclosure panel's
>> content)? also think about Reader's menu in its left pane panels.
>>
>>   And it
>>> doesn't really solve the problem Thomas mentions with the focusable
>>>
>> part of the
>>
>>> header (i.e., the anchor) interfering with form elements placed within
>>>
>> it.
>>
>> The only issue if you replace the anchor with a FocusImpl is in the case
>> it is a FocusImplOld (i.e. in WebKit, although Safari 4 and Chrome 3 now
>> correctly implement tabIndex as a way to make any element focusable –I
>> don't know about mobile webkits such as the iPhone and Android, but
>> they're not officially supported afaik–, and in "old gecko", which was
>> still supported only because of the hosted mode), because it'll steal
>> the focus from a focusable child (see issue 1471)
>>
>>
>> http://gwt-code-reviews.appspot.com/78817/diff/15/1029
>> File user/src/com/google/gwt/user/client/ui/DisclosurePanel.java
>> (right):
>>
>> http://gwt-code-reviews.appspot.com/78817/diff/15/1029#newcode62
>> Line 62: super(DOM.createAnchor());
>> On 2009/10/14 15:43:39, jgw wrote:
>>
>>  I don't actually believe that switching from using an anchor to
>>>
>> FocusImpl will
>>
>>> make much of a difference. They both have the effect of wrapping the
>>>
>> contained
>>
>>> widget in a "focusable" area, which is necessary to make them
>>> keyboard-accessible.
>>>
>>
>> but the anchor impacts your CSS, as you'll inherit its color:blue style
>> in your header text.
>>
>>  It's not immediately obvious how we could *both* make the
>>> header focusable, *and* not interfere with form elements stuck inside
>>>
>> it.
>>
>> Hence my other proposition, to have two public disclosure headers: one
>> that can only contain text, as is the case today, and one that can
>> contain widget (in this case, only the image is focusable and
>> clickable). And if you want to replace the whole header with your own
>> (which handles the image display, as of today), that's still possible,
>> but you'd also have to handle focusability and clicks (for backwards
>> compatibility, widgets that do not implement OpensAndCloses –or should
>> it be OpensAndCloses.Handler?– would automatically be wrapped within a
>> special, private header based on e.g. a FocusPanel).
>>
>>
>> http://gwt-code-reviews.appspot.com/78817
>>
>
>

--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---

Reply via email to