Re: [whatwg] Structured option element
The natural implementation of such a paradigm is using a table with a group of radio buttons. It seems the tool you attempt to use does not match the task you want to perform. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Filip Likavcan Sent: Saturday, August 25, 2007 7:58 PM To: [EMAIL PROTECTED] Subject: [whatwg] Structured option element Hi, I would like to propose structured option element. The option element is now described (=displayed in select box) only by simple text value. The problem is, that in real world the option acts like object with more properties. There are many cases in which options are described by more than one property. For example the list of URL's in the Firefox displays for each item its URL and page title. Another example: I'm developing e-shop backend application for sellers. Seller can create/edit an order, manage products on stocks and generate invoices. When the seller wants to add new product into the order, it is important for him to know how many products are there on each stock. Products are displayed in select as its options. It would be great if I could specify multiple properties for the option and the interface would somehow reflect it. Something like this: select name=products option id=1 propertyProduct's name/property propertyX/property propertyY/property ... propertyZ/property /option /select [Product's name | X | Y | Z] Where X, Y, Z represent the numbers of products on stocks. | represents a column border. Columns should be displayed as columns in tables (covering entire width of table, able to have specified exact width, padding, ...). Maybe this is already covered somehow. I tried to find something in older e-mails in this mailinglist, but I haven't found anything. Filip filer Likavčan
Re: [whatwg] Progress Events done event
Remember that JavaScript is a programming language after all. You can use a
loop to get rid of the repetitions.
Start from
var done = [load, error, abort]...
and apply the closure image.aEL(?, hPB, false) to it.
Sincerely,
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Sunday, August 26, 2007 8:25 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [whatwg] Progress Events done event
==
function showImage(imageHref) {
...
// remove the progress bar when done.
image.addEventListener(load, hideProgressBar, false);
image.addEventListener(error, hideProgressBar, false);
image.addEventListener(abort, hideProgressBar, false);
}
==
This is somewhat verbose. Clearly, the author is forced to repeat
himself when all he really wants to do is hide the progress bar after
the call is done.
Re: [whatwg] Offline Web Apps
Ian Hickson wrote: Comments? As useful as this would be, I can't help thinking that: 1. It's a huge time sink that will delay the rest of the spec. 2. We simply don't know enough at this point in time to reliably standardize something like this. Keep in mind that most of what this group is doing is based on 5-10 years of practical, hard-earned experience. Offline web apps are based on what we'd like to do at some point in the future. I would suggest this be a separate, experimental effort. When we know more about the problem, we can come back to it in a couple of years. -- Elliotte Rusty Harold [EMAIL PROTECTED] Java I/O 2nd Edition Just Published! http://www.cafeaulait.org/books/javaio2/ http://www.amazon.com/exec/obidos/ISBN=0596527500/ref=nosim/cafeaulaitA/
