Re: [whatwg] Web Forms 2.0 - select element
Ian Hickson wrote: On Wed, 12 Oct 2005, Jon Levell wrote: A simple use-case for this is a web-based email program. With the inbox shown, messages can be marked as selected with check-boxes then actions applied to the selection with a select box. If 5 messages are selected and then say marked as important and then 2 more messages are selected and then the operation is repeated the onchange handler is not called. This is inappropriate use of a select. On the long term, the menu features of WA1 will hopefully address your need more directly. On the short term, I would recommend simply setting the value of the select back to a neutral default in onblur=, or something along those lines. You are right, on reflection that isn't such a good use case but I do maintain that there are good use cases for it. Slightly less familiar than an email app hence I (wrongly) used that one first. The actual situation I want to use it in is as follows. I have a dynamic web page that represents a table in a relational database. Each row in the table is a row on the page. Some columns refer to other tables, these columns have a select box at the top of the page containing a list of all the values that entries in this column could be changed to. If rows are selected and then a value in the select box is chosen then that value is set for all selected rows. The values shown in the select box will vary as you navigate around the database - I don't think the menu is appropriate - it could be very long and will vary when you have a similar view of two different tables. I don't think I'd use it in a desktop program. Setting the value to a neutral default with onblur= is better but still not ideal - the list could be long and common options are likely to be grouped together (if the target database table is organised). I admit that such use cases are much rarer - are they worth bothering about at such a late stage - or do you think my usage here is inappropriate as well? Jon Levell.
Re: [whatwg] Web Forms 2.0 - repetition model control
On Sun, 16 Oct 2005 04:46:39 +0300, Lachlan Hunt [EMAIL PROTECTED] wrote: ROBO Design wrote: ... If you want it done like that, then at least use type=button. That way, users of legacy UAs don't get confused by a strange text box that they don't know what to put into it, but rather end up with a button that does nothing when clicked. Neither are ideal from a usability perspective, but the button seems like better graceful degradation. However, button type=add already does that, so I'd just leave it as is. I know neither are ideal from a usability perspective. Yet, 'ideal' cannot be achieved in this case (or probably ... ideals can't be achieved). It's up to Ian to decide what he believes to be the best. -- http://www.robodesign.ro ROBO Design - We bring you the future
Re: [whatwg] Web Forms 2.0 - select element
On Sun, 16 Oct 2005, Jon Levell wrote: I have a dynamic web page that represents a table in a relational database. Each row in the table is a row on the page. Some columns refer to other tables, these columns have a select box at the top of the page containing a list of all the values that entries in this column could be changed to. If rows are selected and then a value in the select box is chosen then that value is set for all selected rows. This works today, no? This is a frequent idiom in desktop UIs; you select a bunch of things, then select a value from a dropdown. If all the selected items had the same value, it is selected already (so selecting it again will have no effect). If all the selected items have not got the same value, then the dropdown will be blank, and selecting a value will make it apply. (Checkboxes have a UI for this too, tri-state checkboxes. This currently isn't supported by HTML.) It's pretty bad UI for a select to do something if you reselect the current selection, IMHO. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [WA1] Quick thoughts on menus.
On Sun, 16 Oct 2005, Matthew Raymond wrote: [...] Also, my model doesn't allow menus to be displayed via a hyperlink. Displaying menus via hyperlink would introduce weird situations like bookmarking menus and referencing menus outside the document. While it may be possible to create a set of rules to deal with these various problems, I believe my menulabel solution to be far simpler and easier to learn. [...] I'll take a closer look at this in a few months when I rewrite the menu section, but I just wanted to jump in here to give some context for people who do wish to come up with a better model than what is currently in the spec (and heck knows we need one). There are several key things that this part of the spec is trying to achieve, and several things which are nice to haves which we should aim for but which should not constrain the design. Requirements: * The design should be related to the way people do DHTML menus on sites today. Either it should be possible to easily annotate existing markup and get native menus out of them, or it should be possible to easily get older UAs to render the new menus in the old way, or something of a real migration story. * Same with the way people do select menus. These two points are the cause of the way the current proposal handles a and select specially. * It must be possible to do context menus with this system. This implies getting data like mouse X/Y position, getting target element information, having a way to update the context menu based on where it was called from, etc. This is really badly handled at the moment. * The feature must support a way to keep toolbar buttons and menu items in sync regarding things like disabled state, radio button selection, icons, etc. This last requirement is the source of command et al. IMHO this works reasonably well as currently specified. * A balance between ease of authoring, ease of implementation, ease of specification, ease of testing, etc. Nice to haves: * It could be possible to have a stand-alone HTML document that has a native menu bar in stand-alone mode, and have that same document work fine in a non-trusted environment (i.e. a Web browser content area). menubar was supposed to help with this, but IMHO fails to do it in a sane way. * It should be possible to have this fallback to a sane rendering even in Lynx, where instead of scripting to do the commands, you'd have a list of items and have things happen server side. This was the thinking behind using menu li. * Should be possible to share menus, e.g. to have one drop-down menu shared between a toolbar button and a context menu without having to list it twice. The current proposal does this, though not that intuitively IIRC. * Should be possible to have menus drop down from buttons (the way that select is often abused today for doing commands, e.g. in GMail; this kind of UI is seen a lot in native applications on all platforms). I don't remember if this is possible in the current proposal. Non-requirements: * Script-free. There's no reason to design this in a way that it doesn't require script somewhere to do it. (Though of course, cutting down on script is always good if it is replaced by something simpler.) * Replicate every feature of every OS in the first version. * Having arbitrary form controls in menus. * Introducing no new elements. It's ok to introduce new elements. Let me know if you have any questions. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] web-apps - TCPConnection
On Sun, 16 Oct 2005, S. Mike Dierken wrote: http://whatwg.org/specs/web-apps/current-work/#network My only question is - why? Imagine trying to play a game like Quake implemented in a Web page. You need bidirectional communication. Another example would be something like an IM or chat client. All the current implementations of that are huge hacks that would be much simpler to implement if they could just open a TCP connection and send free-form data back and forth. It seems bizarre to introduce this section into a Web browsing environment where HTTP is available to define most of the interactions described in this section. HTTP is a stateless synchronous protocol for resource management. The TCPConnection interface is a stateful asynchronous protocol for bidirectional realtime communication. They are very different. I realize this is just a draft, but there are some odd descriptions - for example, the TCPConnection must use port 80 (the port that defines HTTP), but later the communication requirements define a completely different and new protocol on that port: It's not intended to use port 80 only; where does it say that? That's an error. It is intended to be usable on ports 80, 443, and anything greater than 1024. (80 and 443 to attempt to tunnel out of psychotic firewalls, and anything greater than 1024 so that you can't talk to things like SMTP or FTP servers, something that could allow all kinds of security problems. The handshake also attempts to reduce the risk of security issues.) Once a TCP/IP connection to the remote host is established, the user agent must transmit the following sequence of bytes, represented here in hexadecimal form: 0x48 0x65 0x6C 0x6C 0x6F 0x0A This represents the string Hello followed by a newline, encoded in UTF-8. This whole section seems somewhat unnecessary. If you are trying to securely establish a connection then switch to a private/proprieatry protocol, you can use the Upgrade header to transition beyond HTTP once the connection is established: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.42 We don't want to require that authors implement an entire HTTP server just to be able to switch to a proprietary protocol. Also, HTTP does not define a reliable handshake protocol to prevent bogus data injection into other servers of protocols -- for example, HTML forms have already been used to inject data into SMTP servers and FTP servers in (successful) attempts at distributing spam from third-party computers by sending HTTP packets at SMTP and FTP ports. By having a very specific handshake protocol that servers must obey before the client will allow arbitrary data out, we avoid the possibility of servers getting hijacked in this way. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
