- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Fri, 01 Jul 2005 08:01:25 -0400
Karl Pongratz wrote:
> Matthew Raymond wrote:
>> People know where the back and next buttons are. They use them all
>>the time. Why would you not design your web app to take advantage of a
>>piece of UI that the user is so familiar with?
>
> The back button is great, for documents. Personaly I find the back
> button annoying in the case that it returns me to a page where it
> doesn't make sense, which is not the case for documents but for web
> applications.
There is an entire continuum that exists between web documents and
web apps, but I'll accept that for some specific web apps, browsing
history is irrelevant and a distraction.
> And I don't remember how many times the web browser back
> button has been called the evil of web apps in related discussion.
> Hence, chromeless windows give me the chance to unlock from the broswer
> back/next button and the browser history.
Perhaps instead of addressing the chrome, we should address the
browser history issues. Perhaps a way of locking a window for browser
history at the time of creation is in order.
>> Color pickers aren't in HTML, but perhaps they should be:
>>
>>| <label>Foreground Color: <input type="color" name="foreground"></label>
>>
>> Now, I've seen quite a few color pickers that /aren't/ modal, that
>>are either flat controls or temporary pop-up style controls like a
>>combobox. Therefore, for the markup above, the implementation is the
>>domain of the UA, not HTML.
>>
>> That's important to note. HTML isn't the place for behavioral
>>features. At the very least we should probably be talking about this
>>specifically in the context of Javascript, in which case we should be
>>talking about how a web app might degrade with Javascript turned off.
>
> It should be left to the developer if a web application can degrade or
> not if Javascript is turned off. In many cases it wont simply not be
> allowed to run an application if javascript is turned off. That's 100%
> legal I think.
Well, also keep in mind that if they don't have the new Javascript
features, it won't run either, so you'd be rejecting non-WA1 and non-JS
user agents alike. If modal windows can't degrade to non-modal even when
Javascript is enabled, you're cutting all the current IE users off
from the application.
>> If you're talking about DHTML color pickers, I think the
>>combobox-style approach is pretty well established in that case.
>
> Please leave developers decide what kind of color picker they want to use.
It's not limiting developers' choice to suggest that we introduce a
new <input> type that allows easy implementation of color pickers
(which UA vendors could support using modal dialogs) without breaking
existing DHTML ones. Developers are already limited by the lack of
standards support for modal dialogs, so I'm not presenting them with a
decision that's any more limited than the one they have now.
Sure, modal dialogs are good for color pickers under certain given
conditions. However, color pickers are also a very common form of
widget, so it makes more sense to support them via markup than to create
a modal dialog system so that web developers can individually create
their own custom color pickers.
> I am still convinced that chromeless windows for forms/applications have
> advantages over the traditional approach and that the addition of modal
> windows would just make it better. I respect that you would do it
> different, though I think developers should be free to choose the
> approach they think is better for there users. I am using chromeless
> windows in a number of places and as far as I can tell it just works
> perfect for the users..
Just had a thought: It's important to note that modal windows need
to be chromeless windows, but chromeless windows need not be modal.
Therefore, if chromeless windows are absolutely unacceptable, so are
modal windows. So, yes, you are right to fight for chromeless windows if
you want modal ones.
Received on Friday, 1 July 2005 05:01:25 UTC