Re: [whatwg] without keyboard editing
On 02/11/2010 11:46, Diego Perini wrote: On Mon, Nov 1, 2010 at 3:31 AM, TAMURA, Kent wrote: A team in Google tried to use for a product, and they decided not to use it. What they needed was a control to select an integer from a specific integer range such as 1 - 16. The number type control in Opera and WebKit allow a user to input out-of-range value even if the control has min=1 and max=16 attributes. It's not a good UI and the reason why they doesn't use type=number. They need a number control which - doesn't allow any keyboard / cut&paste operations and So, a text field part is read-only, but the spin-buttons work. - always has a valid value. "required" by default, and sanitization algorithm may be different. I'm not sure how to solve this issue. Introducing new content attribute or another number type? I would have suggested using a standard "select" element for that. Seems to me it covers all of your requirements: - cut/paste not allowed - keyboard spinning - always valid even then, I wouldn't do that just to avoid server validation. :-) Bah! I missed your reply and just posted exactly the same thing. :) -dean
Re: [whatwg] without keyboard editing
On 01/11/2010 02:31, TAMURA, Kent wrote: A team in Google tried to use for a product, and they decided not to use it. What they needed was a control to select an integer from a specific integer range such as 1 - 16. The number type control in Opera and WebKit allow a user to input out-of-range value even if the control has min=1 and max=16 attributes. It's not a good UI and the reason why they doesn't use type=number. They need a number control which - doesn't allow any keyboard / cut&paste operations and So, a text field part is read-only, but the spin-buttons work. - always has a valid value. "required" by default, and sanitization algorithm may be different. Use . -dean
Re: [whatwg] Customize HTML5 forms placeholder style
On 22 February 2010 15:11, Boris Zbarsky wrote:
> On 2/22/10 6:08 AM, Dean Edwards wrote:
>> There is a small chance that it could break some pages I guess.
>
> So why is it worth it, then?
I was agreeing with you. That's why I suggested :no-value.
>> I always wanted a pseudo-class that could match with no value.
>> Extending :empty is probably a bad idea but something like :no-value
>> would be useful.
>
> I'd be fine with :no-value, I think, though it could easily be misused due
> to unexpected situations when it happens (e.g. a text input that I'm typing
> in and delete all the text but am about to type more text is :no-value,
> right?).
>
Yes, I think it should be live. As soon as you delete the text then
the pseudo-class applies. It would be similar to :checked.
As Tab Atkins pointed out it makes styling placeholders doable (but
not as nice as a dedicated pseudo-class):
input[placeholder]:no-value:not(:focus) {
}
It would be nice to use with required too:
input[required]:no-value {
border-color: red;
}
It's a shame that we can't have generated content for elements
because I'd love to be able to do this:
input[required]:no-value:after {
content: "*required";
vertical-align: super;
color: red;
}
But you can't have everything. ;)
-dean
Re: [whatwg] Customize HTML5 forms placeholder style
On 22 February 2010 14:26, Tab Atkins Jr. wrote:
>> It gets around the need for a new :placeholder pseudo-class:
>>
>> input[placeholder]:empty {
>> color: red;
>> }
>
> To get it to act like implementations do, you have to use
> "input[placeholder]:empty:not(:focus)". That's pretty complex. ^_^
>
Ah, good point. It's not quite so readable now. :(
-dean
Re: [whatwg] Customize HTML5 forms placeholder style
On 22 February 2010 01:18, Boris Zbarsky wrote:
> On 2/21/10 7:11 PM, Dean Edwards wrote:
>>
>> Why not just extend :empty to include with no value?
>
> Because that's not backwards-compatible and in fact violates the current CSS
> spec?
>
>> It reads nicely:
>>
>> input[required]:empty:after {
>> content: "This value is required";
>> color: red;
>> }
>
> 1) :after is not defined for replaced elements (which is).
> Conforming CSS2.1 user agents do a variety of things here, ranging from not
> rendering such content at all to making it a sibling of the thing being
> styled instead of a child.
Fair enough. Ignore the :after example.
> 2) input[required]:empty is defined to match any input which has an
> attribute named "required" and no kids in the DOM. It does NOT match an
> input which has kids in the DOM.
>
> So today, input[required]:empty would match:
>
>
>
> in an HTML document and would not match the perfectly doable
>
>
> And some random text, too
>
>
> in an XHTML document.
>
> Unless this is in fact a proposal to completely redefine how :empty matching
> works in some backwards-incompatible way? Is there evidence that this won't
> break existing consumers?
>
Yes, I'm suggesting redefining how :empty works. For elements that
cannot have children it could mean having no content. e.g. An
with no value or an with no src.
It gets around the need for a new :placeholder pseudo-class:
input[placeholder]:empty {
color: red;
}
There is a small chance that it could break some pages I guess. If
people are using *:empty than it may start matching some
elements.
I always wanted a pseudo-class that could match with no value.
Extending :empty is probably a bad idea but something like :no-value
would be useful.
-dean
Re: [whatwg] Customize HTML5 forms placeholder style
On 21/02/2010 21:46, Aryeh Gregor wrote:
One implementation idea would be a pseudo-element, with something like
this in the UA stylesheet:
::placeholder { opacity: 0.6; }
Why not just extend :empty to include with no value?
It reads nicely:
input[required]:empty:after {
content: "This value is required";
color: red;
}
-dean
[whatwg] Error: Stray doctype.
http://html5.validator.nu/?doc=http://www.whatwg.org/specs/web-apps/current-work/multipage/ -dean
Re: [whatwg] boolean attributes in javascript
On 08/12/2009 23:04, Garrett Smith wrote: Setting an attribute to the empty string may have the effect of removing the attribute in some browsers. Which browsers/properties? -dean
Re: [whatwg] insertAdjacentHTML
On 24/11/2009 15:24, Daniel Glazman wrote: Anne van Kesteren wrote: The problem is that it is a legacy feature, much like innerHTML. That's not a problem. Make insertHTML with the new values and make insertAdjacentHTML with the old values just an alias to the new ones. Or the contrary. Or whatever. But it's not because it's shipped by MS that way that we must stick forever to such an horrible definition... Adding aliases does not reduce the horribleness of an API. -dean
Re: [whatwg] element.onFocus instead of window.onhashcange ?
On 17/11/2009 15:50, Bjartur Thorlacius wrote: As the discussion had turned into bunch (good) advice giving, I decided to repost this if anyone actually has opinion on this matter and/or could tell me why the spec recommends firing hashchange on the document instead of a specific element when a user navigates to a URI with a hash component. A lot of Ajax apps will manipulate the value of location.hash to represent the *state of the application*. In this case there is no corresponding element to trap the onfocus event. -dean
Re: [whatwg] The new content model for breaks rendering in MSIE5-7
On 14/10/2009 04:41, Ian Hickson wrote: On Tue, 29 Sep 2009, Dean Edwards wrote: It's going to take a while for IE7 to go away. In the meantime it becomes an education issue -- "You can start using HTML5 except which will look OK in some browsers but completely break others." ...and except for which will be slow or not work in IE for the forseeable future, and the drag and drop model's "draggable" attribute which will only work in new browsers, or the new controls which will look like text fields in legacy UAs, or... how is different? The other things you mentioned don't work but don't break anything. Using can potentially break entire pages. Can't we just invent some new elements? We've already created 20 new ones. Two more won't hurt. :) We have more than a dozen elements whose names would be appropriate here. Inventing entirely new elements to do the same thing again just to work around a very short-term problem is just silly. I don't think it is silly to prevent severe rendering problems in 30% of installed browsers. As far as I can see the options are as follows: 1. Drop support for and for now, revisit it later. 2. Use, and don't expect to be able to use it in any browsers sanely for a few years. 3. Use/, and don't expect to be able to use it in old versions of IE without rather complicated and elaborate hacks for a few years. 4. Invent a new element with a weird name (since all the good names are taken already), and don't expect to be able to use it in IE without hacks for a few years. I am not convinced of the wisdom of #4. I prefer #2 long term, but I see the argument for #3. If we go with #3, I can always add a "Best viewed with Firefox" badge to my web sites. That will solve the problem. -dean
Re: [whatwg] The new content model for breaks rendering in MSIE5-7
On 04/10/2009 18:11, Tab Atkins Jr. wrote: On Sun, Oct 4, 2009 at 10:58 AM, Dean Edwards wrote: On 04/10/2009 15:51, Tab Atkins Jr. wrote: only requires extra hacks in two browsers that are on the way out. Given a little bit more time they'll be gone completely, and we can stop worrying about this. I'm sorry but you are really understating the problem here. Can you elaborate? Are there rendering problems in any other browsers? Is there something else I'm missing? Is this too many questions in a row? MSIE5-7 usage is currently between 25% and 30%. It will take a number of years before it becomes insignificant. The two hacks you mention are fairly hideous. One of them can potentially prevent other scripts from executing. We've gone full circle on this subject now. We are starting to repeat ourselves. -dean
Re: [whatwg] The new content model for breaks rendering in MSIE5-7
On 04/10/2009 15:51, Tab Atkins Jr. wrote: only requires extra hacks in two browsers that are on the way out. Given a little bit more time they'll be gone completely, and we can stop worrying about this. I'm sorry but you are really understating the problem here. -dean
Re: [whatwg] The new content model for breaks rendering in MSIE5-7
On 03/10/2009 03:38, Tab Atkins Jr. wrote: Agreed, but won't be usable at all in modern browsers (without hacking support in via js) until everyone updates. That's the whole point of this thread. We are specifying something that won't be usable for years. Let's make the spec better so that we can use sooner. -dean
Re: [whatwg] The new content model for breaks rendering in MSIE5-7
On 02/10/2009 23:51, Tab Atkins Jr. wrote: On Fri, Oct 2, 2009 at 5:35 PM, Dean Edwards wrote: On 29/09/2009 21:55, Keryx Web wrote: 2009-09-29 21:53, Dean Edwards wrote: Can't we just invent some new elements? We've already created 20 new ones. Two more won't hurt. :) This has been discussed on the HTML5 WG list to death. Can we revisit this? It seems to important to sweep under the carpet. The basic issue is that the use-case for and are sorta minimal anyway - it's enough that they can justify themselves, but just barely. If we have to mint *more* new elements just to get them to work, that moves them from "barely worth the effort" to "meh, just drop it". If that's the way people feel then it is better to drop these elements rather than introduce potentially dangerous behaviours when using them. You say that the use cases are marginal but just as I started getting used to them I found an awesome way to use them. Now that I can't use them I feel less awesome. / only have parsing problems in IE6 and IE7. Only 30% of browsers you say? In the meantime, we can just keep usings to handle both of these cases, like we do right now. So we drop two new elements for the sake of adding two more? -dean
Re: [whatwg] The new content model for breaks rendering in MSIE5-7
On 29/09/2009 20:08, Dean Edwards wrote: You have two choices to get around the rendering bug: 1. The potentially dangerous document.write() On 29/09/2009 18:10, Dean Edwards wrote: There is a nasty side effect though. As you mentioned the document.write() should be the last thing in the . If there are any scripts following the document.write() then they are *not executed*. I consider this a serious drawback. 2. Inserting weird conditional comments into your code: I don't like either solution. On 29/09/2009 21:55, Keryx Web wrote: 2009-09-29 21:53, Dean Edwards wrote: Can't we just invent some new elements? We've already created 20 new ones. Two more won't hurt. :) This has been discussed on the HTML5 WG list to death. Can we revisit this? It seems to important to sweep under the carpet. -dean
Re: [whatwg] Closing tags for empty content model
On 02/10/2009 23:19, Michael Kozakewich wrote: From: "Anne van Kesteren" Sent: Tuesday, September 29, 2009 4:21 AM The problem with allowing this is that means ... This does suck a little when introducing new void elements, but keeping the syntax consistent is worth it in my opinion. But has always required , so it sounds like adding the would be the more consistent method. and can be kept the way they are, because they aren't problems, and has always been a special case (even in HTML5). There was a discussion, a few months back, about taking out the tag when a source is specified. I believe that ended with something like, "we can't take it out without ruining support in all older browsers." It makes sense to make tags support tags, even if they aren't necessary, so that developers can put tags in for older browsers (at least until the older browsers finally die). I was thinking of when I requested . They are at least consistent in that they provide a "src" attribute indicating pseudo-content. Can we allow and save legacy Opera browsers? Don't you work for Opera Anne? ;) -dean
Re: [whatwg] The new content model for breaks rendering in MSIE5-7
On 29/09/2009 20:41, Tab Atkins Jr. wrote: On Tue, Sep 29, 2009 at 2:08 PM, Dean Edwards wrote: You have two choices to get around the rendering bug: 1. The potentially dangerous document.write() 2. Inserting weird conditional comments into your code: I don't like either solution. The third solution, of course, is just to avoid until IE7 shrinks sufficiently to be ignored. That won't take too much longer, and then you can start using it with impunity (aided by a js shim to give it functionality in the browsers that accept it but don't implement it yet). It's going to take a while for IE7 to go away. In the meantime it becomes an education issue -- "You can start using HTML5 except which will look OK in some browsers but completely break others." This whole thing is really much less of an issue than the problems were, where you'd have to wait for *every* current browser to phase out, as opposed to just two that are already declining nicely. The issue was much easier to fix with JavaScript. But that was a horrible solution as well. Can't we just invent some new elements? We've already created 20 new ones. Two more won't hurt. :) -dean
Re: [whatwg] The new content model for breaks rendering in MSIE5-7
On 29/09/2009 19:30, Keryx Web wrote: 2009-09-29 19:10, Dean Edwards skrev: There is a nasty side effect though. As you mentioned the document.write() should be the last thing in the . If there are any scripts following the document.write() then they are *not executed*. I consider this a serious drawback. With server software generating script elements all over the place there are bound to be problems with this technique. It would be nice to find a better solution. I consider this a deal breaker. Fragile and unintuitive hacks, that really no one knows or can explain why they work, is NOT the kind of things we should rely on when pushing for HTML5. I'm starting to think that too. MSIE5-7 accounts for about a third of web users. This admittedly clever hack is just too hackish. You have two choices to get around the rendering bug: 1. The potentially dangerous document.write() 2. Inserting weird conditional comments into your code: I don't like either solution. -dean
Re: [whatwg] The new content model for breaks rendering in MSIE5-7
On 29/09/2009 17:55, Dean Edwards wrote: On 29/09/2009 16:12, Tab Atkins Jr. wrote: On Tue, Sep 29, 2009 at 8:47 AM, Dean Edwards wrote: This will also affect the element. Test case: http://dean.edwards.name/test/details.html Luckily this has already been discovered and hacked around: http://lists.w3.org/Archives/Public/public-html/2009Sep/0802.html This hack can also be applied via document.write(), so it can be integrated into existing scripts that fix legacy IE renderings via the document.createElement() hack. (The only restriction is that it immediately switches IE parsing into body mode, so it must be the very last thing in.) I can't get it to work using document.write(). Do you have a live example? It's always the last thing you try. :) http://dean.edwards.name/test/details2.html There is a nasty side effect though. As you mentioned the document.write() should be the last thing in the . If there are any scripts following the document.write() then they are *not executed*. I consider this a serious drawback. With server software generating script elements all over the place there are bound to be problems with this technique. It would be nice to find a better solution. -dean
Re: [whatwg] The new content model for breaks rendering in MSIE5-7
On 29/09/2009 16:12, Tab Atkins Jr. wrote: On Tue, Sep 29, 2009 at 8:47 AM, Dean Edwards wrote: This will also affect the element. Test case: http://dean.edwards.name/test/details.html Luckily this has already been discovered and hacked around: http://lists.w3.org/Archives/Public/public-html/2009Sep/0802.html This hack can also be applied via document.write(), so it can be integrated into existing scripts that fix legacy IE renderings via the document.createElement() hack. (The only restriction is that it immediately switches IE parsing into body mode, so it must be the very last thing in.) I can't get it to work using document.write(). Do you have a live example? And kudos to the guy that discovered this hack. I have no idea how it works but it seems to do the trick. Do you have any background to this hack apart from what was on the W3C list? -dean
[whatwg] The new content model for breaks rendering in MSIE5-7
This will also affect the element. Test case: http://dean.edwards.name/test/details.html -dean
Re: [whatwg] Closing tags for empty content model
On 29/09/2009 03:21, Tab Atkins Jr. wrote: On Mon, Sep 28, 2009 at 9:18 PM, Marius Gundersen wrote: Shouldn't you always close the tags, either self-closing or with a separate close tag? That is, this is the correct way to do it: Text after the video element. In the HTML syntax of HTML5, no, void elements do *not* have to be explicitly closed. You *can* put the trailing slash on them, but it doesn't do or mean anything; it's simply ignored. If the content is served as XHTML then it would have the same effect as adding the closing tags. For a JavaScript solution I would like to avoid having to require XHTML. This is further complicated by a new discovery, Safari 3 completely ignores elements. They don't appear in the DOM tree at all. But that's a separate problem. :) It's probably too late to change the spec. But the Opera bug I pointed out is serious enough to consider an alternative solution. Allowing closing tags for would solve the problem. I'm not sure of the implications for the defined rendering models in HTML5. Just to reiterate, Opera<10 treats all unknown elements as container (flow) elements. That means that as soon as it encounters a tag, all of the following elements are *children* of the element. This makes all DOM queries and CSS rules completely useless. Allowing a closing tag solves the problem. -dean
[whatwg] Closing tags for empty content model
I'm currently writing a JavaScript implementation of the element. I'm running into problems with Opera9.52. If I use the following markup then the text in the following element is coloured red: Text after the video element. Opera, before version 10, treats all unknown elements as block elements. That means that all elements following the first element are children of the first element. This is potentially disastrous. The only solution is to add closing tags: But then it is invalid. Is there any way we can change the content model for this element (and possibly ) to phrasing? The text content could be descriptive of the particular media or provide a fallback to download the file. download this video in OGG format Or do we not care about edge cases like this? -dean
[whatwg] formNoValidate/novalidate/willValidate
Hi all, It's been a while. :) Looking through the spec I see the following DOM properties: * formNoValidate * novalidate * willValidate "novalidate" sticks out like a sore thumb. Can we change it to "noValidate". It's only mentioned in the IDL so maybe it's a typo. -dean
Re: [whatwg] Why SQL? was: Comments on updated SQL API
Andrew Fedoniouk wrote: I am not against new things really. It just appears as UA will look like Christmas tree one day. Each member of the family is adding their own stuff. And someone put there SQL engine because it happens to lie on the shelf nearby and granddad decide that his old canvas will also look cool there and so on. For Christmas tree such decoration approach would work but for serious system design ... Client storage shall be as simple and universal as possible to be short. I wonder about the term "SQL" appearing in HTML specs too.. -dean
Re: [whatwg] Scripting Tweaks
Maciej Stachowiak wrote: On May 19, 2007, at 4:27 PM, Dean Edwards wrote: Maciej Stachowiak wrote: On May 18, 2007, at 10:14 PM, liorean wrote: On 19/05/07, Ian Hickson <[EMAIL PROTECTED]> wrote: The "uniqueID" thing is really working around a deficiency in JS (inability to use objects as keys). ES4 already has something of the kind. See http://developer.mozilla.org/es4/proposals/hashcodes.html> However, that is not usable in ES3 implementations, which uniqueID is. The hashcode() function is a library function and could be added to ES3 implementations - I'd be willing to support it for WebKit. It should be noted though that it has the same security/privacy issues as uniqueID: the DOM API is language agnostic. This feature is too important to leave to scripting language implementations. To my knowledge, most non-JavaScript programming languages already have facilities for hashing on object identity. This is true at least of C++, Java, Objective-C and C; it also appears to be true of Python, Ruby, Perl and C# as far as I can tell from the docs. What language besides JavaScript are you concerned about? The future looks bright but it is worth pointing out that none of the two currently available scripting languages support a hash ID. A DOM property will enable those languages (ECMAScript and VBScript) to provide backward compatibility. Note that hascode() would be more general than uniqueID since it applies even to non-DOM objects; it would still be needed in JavaScript even if uniqueID was added to the DOM. Agreed. I would use hashCode() if the language allowed it. -dean
Re: [whatwg] Scripting Tweaks
Maciej Stachowiak wrote: On May 18, 2007, at 10:14 PM, liorean wrote: On 19/05/07, Ian Hickson <[EMAIL PROTECTED]> wrote: The "uniqueID" thing is really working around a deficiency in JS (inability to use objects as keys). I think that's where it should be addressed. The uniqueID idea has a number of rather unique implementation difficulties. The obvious implementations have security and privacy implementations; the solutions to those tend to be expensive either in RAM or CPU. I recommend bringing this to the attention of the ES4 group. ES4 already has something of the kind. See http://developer.mozilla.org/es4/proposals/hashcodes.html> However, that is not usable in ES3 implementations, which uniqueID is. The hashcode() function is a library function and could be added to ES3 implementations - I'd be willing to support it for WebKit. It should be noted though that it has the same security/privacy issues as uniqueID: This is all relevant of course but the DOM API is language agnostic. This feature is too important to leave to scripting language implementations. -dean
Re: [whatwg] Sandboxing ideas
Ian Hickson wrote:
A number of people made proposals related to sandboxing content to improve
Web security.
On Fri, 15 Dec 2006, Dean Edwards wrote:
When creating DHTML widgets (e.g. a colour picker) developers have to
battle the CSS cascade. A widget might be made of various HTML elements
which inherit style from the page. Sometimes inherited styles can mess
with the layout of your widget. So we end up coding stuff like this:
#widget div {margin: 0 !important; padding: 0 !important;}
#widget input {border: 0 !important;}
You can't realistically cover all the cases so potentially a new style rule
can ruin your widget layout completely.
So I'm suggesting a new element:
This element is in the document flow as normal except that it acts as a
blank canvas as far as CSS is concerned. Ideally, it should have no
style at all. Like this:
http://developer.yahoo.com/yui/reset/
The element acts as a container for HTML elements that are not
included in the CSS cascade. That way we can build and style widgets
without worrying about the page that will contain them.
This sounds very much like something you'd do with XBL, no? Could you
elaborate on the use case? I mean, colour pickers are the poster child of
XBL use cases.
XBL has an attribute to cover inherited styles, so you're right.
Realistically, I can't see Microsoft ever implementing XBL (I hope I'm
wrong). So adding it to HTML might be the only way to achieve this
functionality.
All of the use cases will almost certainly overlap with XBL use cases.
-dean
On Fri, 15 Dec 2006, Dean Edwards wrote:
I would still like a way to prevent CSS inheritance though. So far the
suggestions are:
1. element
2. inheritstyle="false" attribute
3. cascade:off; CSS property
I don't really mind which one it is. None of them seems particularly
wrong.
Is it really inheritance you want to stop? Wouldn't you want to stop all
styles from applying at that point? e.g. if someone had:
* { border: solid; }
The 'border' property isn't inherited, but would yous till want the border
rule to not apply to the "widget"?
Good point, it's not just inherited styles. In which case only the first
choice, a element, is sufficient.
Some other nice-to-haves:
* this element would have its own JavaScript namespace
- scripts contained by the element would be bound to that namespace
- a element is allowable in
* can validly contain a
Re: [whatwg] Attribute for holding private data for scripting
Kristof Zelechovski wrote: (as client side Lisp is my personal dream) http://www.cs.stevens.edu/~dlong/software/kamen/index.php -dean
Re: [whatwg] Apply script.defer to internal scripts
Matthias Bauer wrote: Is there any chance DOMContentLoaded will be part of HTML5? Seems to have been forgotten: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2005-April/003709.html -dean
Re: [whatwg]
Maciej Stachowiak wrote: So to be sure I understand your proposal, you're suggesting that instead of You'd say: Why not call the element instead of ? That way the src and type attributes make more sense. -dean
Re: [whatwg] input type="password"
Daniel Glazman wrote: On 09/03/2007 11:17, Ian Hickson wrote: Does the "autocomplete" attribute's "off" value cater for your use case? http://www.whatwg.org/specs/web-forms/current-work/#the-autocomplete D'oh. Yes it does. To be honest, I was not expecting an attribute named "autocomplete" to have a security meaning... My bad, and sorry for the spam. Asking perfectly reasonable questions does not count as spam. :-) -dean
Re: [whatwg] Input field's hint value
Alexey Feldgendler wrote: On Wed, 21 Feb 2007 11:28:47 +0100, Wolfram Kriesing <[EMAIL PROTECTED]> wrote: I was searching, but didnt find a hint-attribute for an input. The more often we are using inline editing, the more the need for the following is rising, imho: From the semantic standpoint, I believe this is what the title attribute expresses. Please somebody correct me if I'm wrong, but this behavior (show the value of the title attribute whenever the control is not focused and has empty value) can already be specified with CSS over WF2. You're right. A hint attribute was discussed but the general feeling was that the title attribute was appropriate for this. -dean
Re: [whatwg] JavaScript libraries for Web forms 2.0
BTW, the WF2 implementation for IE, although unfinished, does work. It implements all of the types (except datetime), the element, the element, validation and ValidityState objects, multiple forms and the new events. The implementation looks and feels exactly like a native Windows implementation. We even mimic the user's current XP theme. Download it and try it. I would appreciate any feedback either privately or on this list. https://sourceforge.net/projects/wf2/ -dean Dean Edwards wrote: Elliotte Harold wrote: I know that Web Forms 2.0 is specifically designed so that most of it can be faked with JavaScript libraries as necessary. How far along is that effort? I've found a few bits and pieces here and there via Google such as https://sourceforge.net/projects/wf2/ but nothing seems very finished. In fact, to my surprise, the JavaScript libraries for XForms seem further along. Am I missing any projects? Has anyone published a decent partial or full implementation of Web Forms 2.0 as a JavaScript library yet? I'm the owner of the sourceforge project you mentioned. That project was to provide WF2 support for MSIE. Because Mozilla, Opera and Apple were expected to provide native support we didn't bother to make the library cross-platform. There is a cross-browser implementation of the repetition model here: http://sourceforge.net/projects/repetitionmodel/ The repetition model implementation was written by Weston Ruter. -dean
Re: [whatwg] JavaScript libraries for Web forms 2.0
Elliotte Harold wrote: I know that Web Forms 2.0 is specifically designed so that most of it can be faked with JavaScript libraries as necessary. How far along is that effort? I've found a few bits and pieces here and there via Google such as https://sourceforge.net/projects/wf2/ but nothing seems very finished. In fact, to my surprise, the JavaScript libraries for XForms seem further along. Am I missing any projects? Has anyone published a decent partial or full implementation of Web Forms 2.0 as a JavaScript library yet? I'm the owner of the sourceforge project you mentioned. That project was to provide WF2 support for MSIE. Because Mozilla, Opera and Apple were expected to provide native support we didn't bother to make the library cross-platform. There is a cross-browser implementation of the repetition model here: http://sourceforge.net/projects/repetitionmodel/ The repetition model implementation was written by Weston Ruter. -dean
Re: [whatwg] Sandboxing scripts in pages
Anne van Kesteren wrote: On Fri, 12 Jan 2007 17:34:03 +0100, James M Snell <[EMAIL PROTECTED]> wrote: Whatever shape the mechanism ultimately takes, having a way of isolating scripts within a document would be extremely beneficial. Thoughts? Use an and use cross-document messaging? This has been discussed a lot by the way. I posted a method to do this recently: http://dean.edwards.name/weblog/2006/11/sandbox/ -dean
Re: [whatwg] element?
Anne van Kesteren wrote: Now I get your "" idea better. Perhaps it would be useful to look into XBL? Yes, XBL can already do this for me. But I get the feeling that I won't be able to use it (cross-browser) until the year 2056. :-( -dean
Re: [whatwg] element?
Alexey Feldgendler wrote: In this context, would express the meaning better. I guess you're right. I would still like a way to prevent CSS inheritance though. So far the suggestions are: 1. element 2. inheritstyle="false" attribute 3. cascade:off; CSS property I don't really mind which one it is. None of them seems particularly wrong. -dean
Re: [whatwg] element?
Alexey Feldgendler wrote: Elements comprising a widget should carry appropriate semantic value by themselves. For example, a properly styled unordered list can be used as a color picker. should not be used as an excuse for writing a bunch of meaningless s to make a custom control. Agreed. But if I add boxes for Red, Green and Blue and some OK/Cancel buttons and wrap those up in a element then I feel like I've added semantic value not reduced it. -dean
Re: [whatwg] element?
James Graham wrote: But this element would be purely for the purpose of interacting with CSS so it does indeed seem to be a CSS issue. Not entirely. It also has some semantic value in that the element acts as a container for other elements that comprise a widget. Perhaps is the wrong name. I can't think of anything better though. Like I said, I don't like the name "widget" but it gives a better idea of what the element is. -dean
Re: [whatwg] element?
Anne van Kesteren wrote: On Fri, 15 Dec 2006 18:08:35 +0100, Dean Edwards <[EMAIL PROTECTED]> wrote: Thoughts? My thought is that this is a CSS issue and not a markup issue. It feels right to fix it with markup. Maybe does not give the right semantic meaning? But I hate the word "widget" so a tag is out of the question. :-) -dean
[whatwg] element?
When creating DHTML widgets (e.g. a colour picker) developers have to
battle the CSS cascade. A widget might be made of various HTML elements
which inherit style from the page. Sometimes inherited styles can mess
with the layout of your widget. So we end up coding stuff like this:
#widget div {margin: 0 !important; padding: 0 !important;}
#widget input {border: 0 !important;}
You can't realistically cover all the cases so potentially a new style
rule can ruin your widget layout completely.
So I'm suggesting a new element:
This element is in the document flow as normal except that it acts as a
blank canvas as far as CSS is concerned. Ideally, it should have no
style at all. Like this:
http://developer.yahoo.com/yui/reset/
The element acts as a container for HTML elements that are not
included in the CSS cascade. That way we can build and style widgets
without worrying about the page that will contain them.
Thoughts?
-dean
Re: [whatwg] JSON encoding
Douglas Crockford wrote:
> I think the hazard is very real and very serious.
> I don't see any additional expressiveness enabled by toJSONString.
No one is more concerned about the security of the platform than I am.
There isn't a security issue here. The hazard, if there is one, is
certainly not serious.
This is a convenience issue. Having toJSONString as a builtin is a
convenience, removing the need to load json.js.
Why not override the toString method?
Object.prototype.toString(type) {
if (type == "json") {
// return a json serialisation
} else {
// return the usual string conversion
}
};
That way legacy browsers can also support JSON serialisation without
breaking "for in" enumeration.
-dean
Re: [whatwg] getElementsByClassName()
Ian Hickson wrote:
On Mon, 23 Oct 2006, Dean Edwards wrote:
Personally, I prefer a comma delimited list. Passing an array seems
yukky.
Really? I always thought the comma-separated argument to window.open() was
one of the ugliest APIs ever...
This isn't the same thing. We are faking varargs so whatever we do is
going to look a bit ugly. Nine times out of ten this method will be
called with one argument:
var menus = document.getElementsByClassName("menu");
That is much more intuitive for the most common case.
Are there any problems with passing a JavaScript array to a DOM method?
Does it cast to a DOMArray or something? What about other platforms?
It's an array. Most languages support arrays. Why would there be a
problem?
Just checking. ;-)
-dean
Re: [whatwg] getElementsByClassName()
Ian Hickson wrote: On Mon, 23 Oct 2006, Jonathan Worent wrote: When asked if they would prefer a comma separated list or an array, there were mixed feelings. Three indicated a preference to a comma separated list, the other said he would expect to pass an array. Given this I would suggest not using a space delimited list. Ok, that's a compelling argument. I've removed the string version. We're down to just the array form now. If people want to call the method with a single class, they have to use square brackets; if they want to call it with a space-separated list of classes, they have to use .split() or some such. Personally, I prefer a comma delimited list. Passing an array seems yukky. Are there any problems with passing a JavaScript array to a DOM method? Does it cast to a DOMArray or something? What about other platforms? -dean
Re: [whatwg] getElementsByClassName()
On 23/10/06, Charles McCathieNevile <[EMAIL PROTECTED]> wrote: "adding stuff people want instead of referring them to vapourware" isn't a very clear distinction. Since both are currently vapourware, it would be helpful to ahve some rational basis for determining that one is desired and another is not. Like James, I so far don't see that in this discussion. This has been debated to death. People want this function. So I think we should add it. The only arguments against are that there are potentially better solutions, like matchAll/matchSingle. I don't think that is a good enough reason to not include it. First, it is analogous to getElementsByTagName. Second, alternatives are not currently implemented. It is not uncommon for API's to provide more than one way to achieve the same end. I don't see why the DOM should be any different. It is not going to break anything and people want it -- so let's spec it. I haven't heard a good argument against inclusion yet and we are on the 87th comment in this thread. -dean
Re: [whatwg] getElementsByClassName()
On 22/10/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
On Sun, 22 Oct 2006 20:16:06 +0200, Dean Edwards <[EMAIL PROTECTED]> wrote:
>>>> So what's the use case over matchAll(".foo.bar.baz") ..?
>>>
>>> I didn't know that this had been implemented. Which browser is
>>> supporting it?
>> It's not supported yet. What makes you think it is?
>
> You asked for a comparison with an unimplemented standard. We could be
> here all day doing that.
Neither getElementsByClassName nor matchAll have implementations (though
both have scripted implementations). I don't really see your point.
The point is that there is room for all of these methods for
retrieving DOM nodes. As there is no useful existing standard let's
add stuff that people actually want instead of referring them to
vapour ware.
-dean
Re: [whatwg] getElementsByClassName()
Anne van Kesteren wrote:
On Sun, 22 Oct 2006 20:03:48 +0200, Dean Edwards <[EMAIL PROTECTED]> wrote:
So what's the use case over matchAll(".foo.bar.baz") ..?
I didn't know that this had been implemented. Which browser is
supporting it?
It's not supported yet. What makes you think it is?
You asked for a comparison with an unimplemented standard. We could be
here all day doing that.
What's the use case of matchAll over XPath?
-dean
Re: [whatwg] getElementsByClassName()
Anne van Kesteren wrote:
On Sat, 21 Oct 2006 09:36:37 +0200, Ian Hickson <[EMAIL PROTECTED]> wrote:
This omnibus edition of your WHATWG mail includes replies to 50 or so
separate e-mails about getElementsByClassName(). Thanks to everyone for
their comment on this issue.
So what's the use case over matchAll(".foo.bar.baz") ..?
I didn't know that this had been implemented. Which browser is
supporting it?
-dean
Re: [whatwg] Detecting Web Forms for future proof scripts?
Kornel Lesinski wrote: On Mon, 02 Oct 2006 17:37:28 +0100, Shawn Wilsher <[EMAIL PROTECTED]> wrote: This project appears to be dead for over a year now. It seems to have at least intention to support Gecko, but I couldn't get it to work properly in Firefox. Just because the project appears to be dead doesn't mean you should just disregard all the work that has been done with it before. It's original aim is only for IE (as stated in the description). However, it has a large amount of work already done - why reinvent the wheel? If I need just a feature or two, it's easier for me to write and maintain my own bit of code rather than rip it out of an unfinished, unstable code that I'm not familiar with. I'd love to use that script once it's production-ready. The project isn't dead. We stopped developing it as Mozilla had not started on WF2. That has now changed [1] and we will soon restart development. There is no intention to support Gecko, it is an IE only implementation. Although it is not production ready, it is pretty close. By all means download and play with it. Let me know if you find any bugs! -dean [1] https://bugzilla.mozilla.org/show_bug.cgi?id=344614
Re: [whatwg] Workflow and web applications
On 23/08/06, Francisco Monteiro <[EMAIL PROTECTED]> wrote: How do you get workflow in a Web Application using only Web Browser technology, Microsoft I think is the only company which will bring a workflow to the masses, Using a combination of Dojo widgets we can achieve something very similar see this URL http://showoff2.awardspace.biz/pack/pack/examples/tabswitch2.html That page took about 20 seconds to load on my corporate network. And then it didn't work. I got "dojo" is undefined. -dean
Re: [whatwg] input type="country"?
On 23/08/06, Arve Bersvendsen <[EMAIL PROTECTED]> wrote: On Wed, 23 Aug 2006 16:02:24 +0200, Martijn <[EMAIL PROTECTED]> wrote: > I'm sure there is an official list out there (United Nations?), with > all the countries in the world. What happens when a web developer lives in a part of the world doesn't agree with the 'official' list of countries? You use a . -dean
Re: [whatwg] input type="country"?
On 23/08/06, Alexey Feldgendler <[EMAIL PROTECTED]> wrote: What would be different between and ? I would hope that the UA would maintain a list of countries/ISO codes and populate a combo box for you. Otherwise, there is no difference. -dean
Re: [whatwg] Return values of on* event handlers
Boris Zbarsky wrote: Consider the following testcase: http://www.example.com"; onclick="return 0">Click me Should clicking the link load www.example.com? Yes. You should explicitly return "false" to cancel an event. Most event handlers return nothing (undefined) which is equivalent to false. So equivalence is not good enough. -dean
Re: [whatwg] Intergrating the DOM and JavaScript (JSDOM)
On 12/05/06, Andrew Fedoniouk <[EMAIL PROTECTED]> wrote:
This is in fact just one line:
var checked = root.select("input[type=checkbox]:checked");
You appear to be using a different DOM to everyone else.
-dean
Re: [whatwg] fullscreen event?
On 11/05/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote: My suggestion would be to have a renderingMode event (or something like that) which in some way exposes a mediaList of the current rendering modes (mostly just one). If you go to print preview mode for example the event is dispatched and the mediaList contains 'print'. If you go to projection mode it contains 'print' etc. Sounds good to me. :-) -dean
Re: [whatwg] Intergrating the DOM and JavaScript (JSDOM)
Some code to illustrate:
// old way
var isChecked = false;
var inputs = document.getElementsByTagName("input");
for (var i = 0; i < inputs.length; i++) {
if (inputs[i].type == "checkbox" && inputs[i].checked) {
isChecked = true;
break;
}
}
// better (using iterators on NodeList)
var isChecked = document.getElementsByTagName("input").some(function(input) {
return input.type == "checkbox" && input.checked;
});
// even better (using W3C Selectors API)
var isChecked =
document.matchAll("input[type=checkbox]").some(function(checkbox) {
return checkbox.checked;
});
-dean
Re: [whatwg] Intergrating the DOM and JavaScript (JSDOM)
On 11/05/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote:
Dean Edwards wrote:
> It would be great if NodeLists were subclasses of JavaScript Array
> objects (especially with the introduction of Mozilla's Array Extras
> [1]). This makes iteration over DOM queries more flexible.
It sounds like a nice idea, but there are some problems with it that I
can see. NodeLists are live, meaning that changes made to the
underlying DOM will be reflected in the list. Conversely, it means that
any changes made to the NodeList would logically need to be reflected in
the DOM.
e.g. If you get a node list of P elements like this
var pNodes = document.getElementsByTagName("p");
then later in the script you remove one of those P elements from the
DOM, it will also be removed from that NodeList.
This is a problem for your idea because it means that changes made to
the NodeList would also need to be made to the DOM, in order to keep
them in sync.
e.g. What would happen if you used the Array push() function on the
NodeList?
pNodes.push(newNode);
Where in the DOM would that new node be added?
I guess mutator methods should throw an error. Because we are
subclassing Array, NodeLists don't have to behave /exactly/ the same
as Array objects. I guess the really useful methods are the iterator
methods introduced in recent versions of Firefox. Being able to use
these on NodeLists would be great.
-dean
[whatwg] Intergrating the DOM and JavaScript (JSDOM)
At the moment, DOM objects are specified in a language neutral way. That's fine. However, this makes these objects uninteresting and cumbersome to script with. Mozilla has a more integrated programming environment. It exposes DOM objects as native JavaScript objects. That means I can do things this like this: Object.prototype.foo = "bar"; alert(document.body.foo); ==> "bar" A trivial example but it demonstrates that the DOM and JavaScript are not totally separate on a Mozilla platform. This is very cool. 8-) It would be great if NodeLists were subclasses of JavaScript Array objects (especially with the introduction of Mozilla's Array Extras [1]). This makes iteration over DOM queries more flexible. I guess what I'm proposing is a new DOM API. One which is specified with JavaScript in mind. A redefinition of DOM objects as subclasses of JavaScript objects. Mozilla already does this by and large. It makes that browser a dream to program with. Is this within the remit of the Web Apps spec? This seems like a fundamental change in terms of browser architecture so I would understand if it was too difficult to implement in the short term. But it would be cool. -dean [1] http://developer.mozilla.org/en/docs/New_in_JavaScript_1.6#Array_extras
Re: [whatwg] fullscreen event?
Jim Ley wrote: On 10/05/06, Dean Edwards <[EMAIL PROTECTED]> wrote: I suggested onbeforeprint/onafterprint events a while back. It got shot down. :-( How disappointing, let's hope the webapi wg look at it... there's certainly existing implementations to just copy. They're useful events. Indeed. Even the W3C think so: http://www.w3.org/Talks/Tools/Slidy/slidy.js -dean
Re: [whatwg] IE Canvas
On 10/05/06, Pablo Sánchez <[EMAIL PROTECTED]> wrote: Hi, I did some fixes on the IE Canvas made by Emil at http://eae.net/ and the rotate method works fine. I even could get the Mozilla clock sample to run. But I can't get contact with Emil, his e-mail server keeps returning my messages. Any ideas where I can place the code? Google are now maintaining this code: http://excanvas.sourceforge.net/ -dean
Re: [whatwg] fullscreen event?
On 10/05/06, Jorgen Horstink <[EMAIL PROTECTED]> wrote: I just had a little chat with Anne and he thinks a rendering change event (ie: before printing, generate a table of contents) will be usefull. I think he is right. I suggested onbeforeprint/onafterprint events a while back. It got shot down. :-( -dean
Re: [whatwg] fullscreen event?
Martijn wrote: On 5/6/06, Dean Edwards <[EMAIL PROTECTED]> wrote: Martijn wrote: > I was thinking, maybe a fullscreen (and a normalscreen event or > something like that) event would be useful? > Also, a fullScreen property (which returns true or false) on the > window would in that case be handy. What do you have in mind? I know that the browser's chrome disappears but otherwise how is this different from a normal resize event? Hmm, yes, I guess it's not really that much different from a resize event. So, indeed a fullscreen event is probably not that useful. But I think a way of detecting when the browser is in fullscreen mode would be useful. I'm not really against the idea but Ian likes use cases. ;-) -dean
Re: [whatwg] fullscreen event?
Martijn wrote: I was thinking, maybe a fullscreen (and a normalscreen event or something like that) event would be useful? Also, a fullScreen property (which returns true or false) on the window would in that case be handy. What do you have in mind? I know that the browser's chrome disappears but otherwise how is this different from a normal resize event? -dean
Re: [whatwg] Web Forms: pattern attribute
Michel Fortin wrote: Le 3 avr. 2006 à 19:33, Dean Edwards a écrit : Michel Fortin wrote: Does that mean that a pattern attribute like "foo|bar" should translate to /^foo|bar$/ ? Wouldn't it make more sense it it was /^(foo|bar)$/ with the parentesis? You have a point. Would implied parentheses cause any side effects? None that I can think of... Now that you mention it, it could. With a pattern like this: "(.).*\1" which simply indicates that the first and the last characters must be the same, reference numbers won't refer to the right part. When the pattern get transformed to this: /^((.).*\1)$/ it makes `\1` a reference to the whole input text (the first parenthesis) rather than the first character (which has become the second parenthesis). This is not good. So we will need to use a non-matching group `(?: ... )` instead: /^(?:(.).*\1)$/ Problem solved. Very neat. However, I think it would be best if the UA did this little trick itself. :-) -dean
Re: [whatwg] alternatives/grouping in pattern attributes in Web Forms
[EMAIL PROTECTED] wrote: This text in section 2.6 doesn't seem to consider alternatives and grouping: | Thus, using the ^ character anywhere other than at the start of the pattern, | or the $ character anywhere other than at the end of the pattern, prevents | the pattern from matching anything (unless the characters are escaped or | part of a range). This is wrong (and what means "range"? should this read "CharacterClass"?). In pattern="[0-9]+$|^0[xX][0-9a-fA-F]+" they would be even required to prevent matching "123xyz", "abc0x0" or similar values, unless the whole string is enclosed in parentheses. More intuitive would be an implicit enclosure of the attribute value between "^(?:" and ")$" instead of plain ^ and $ to construct the actual regular expression. I'm in favour of this. As previously mentioned: http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-April/006182.html it will lead to more readable markup: compared with: -dean
Re: [whatwg] Web Forms: pattern attribute
Michel Fortin wrote: Something about the pattern attribute in Web Forms got me thinking: The regular expression language used for this attribute is the same as that defined in [ECMA262], except that the pattern attribute implies a ^ at the start of the pattern and a $ at the end (so the pattern must match the entire value, not just any subset). Does that mean that a pattern attribute like "foo|bar" should translate to /^foo|bar$/ ? Wouldn't it make more sense it it was /^(foo|bar)$/ with the parentesis? You have a point. Would implied parentheses cause any side effects? None that I can think of... -dean
Re: [whatwg] getElementsByClassName()
Jim Ley wrote: That is not immediately apparent, and neither is it apparent that a classname specific shortname is worthwhile when a CSSSelector one would be more appropriate.You don't continually add methods, methods are complexity, they need writing, they need testing etc. you have to have a reason to add a method. A good API should expose a meaningful interface to its consumer. If we are allowed to define data according to a skew on its structure (HTML className) then the interface to that data should reflect this. The getElementsByClassName() method has already been compared to the getElementsByTagName() and getElementById() methods. "class" is another way to slice the data. It is a core part of HTML, the language we are extending. To me, getElementsByClassName() is a missing feature of the DOM to support HTML4. I'd be happy if that were fixed in HTML5. Re CSSSelector: There are many ways to skin a cat. ;-) -dean
Re: [whatwg] [wf2] Restrict template attributes to only fieldset, tr, and li?
Ian Hickson wrote: Is this only because it is easier to implement the DOM interface on a limited set of elements than on all elements? Basically, yes. As far as the DOM is concerned it is nigh on impossible to support dynamic creation of repetition templates. Support for repetition blocks is slightly easier. Regarding CSS/markup, the only way to support the spec as it currently stands is to write some form of DOM-walking to identify repetition templates and associated blocks. I outlined a way to speed this up in a previous message: http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-March/003299.html (you might have to read the entire thread to get the point). If the tag set were restricted then the need for DOM walking would be removed and would significantly improve performance on an IE platform. -dean
Re: [whatwg] [wf2] Restrict template attributes to only fieldset, tr, and li?
dolphinling wrote: However, could it be made so the template attributes only apply to fieldsets and wherever else they need to because of current parsing, as opposed to all elements? I believe this would mean it applied to fieldset, tr, and li (and perhaps td, though that would be a strange thing to do). A minor consideration but this would make it easier to implement on an IE platform. -dean
Re: [whatwg] [WF3]
Anne van Kesteren wrote: Quoting Dean Edwards <[EMAIL PROTECTED]>: In the repetition models I've implemented in the past (always tables) I've provided a way to select a table row. This meant including either a radio button or checkbox in the first column. When checked, the entire row would be selected. === I think this name is very confusing. Personally I was thinking you were suggesting a, when I read the subject, Selector (:last-child, etc.) control. ? I suggest introducing a new input type to facilitate the selection of repetition blocks: . This would render as either a radio button or checkbox depending on an additional constraint on the repetition template. This does not seem to be very backwards compatible. True. :-( Wouldn't it be better to have some kind of global "label" attribute or "for" which you could then apply on the html:tr element for example. Actually, that's how I marked up this kind of thing in the past. I had class="selector" on the first of a table row. When the selector control is checked it results in the repetition block being selected (the CSS3 ":selected" pseudo class would apply). repeat-selection="single|multiple" == If you just use radio and checkbox controls you would not need this. But then you would have to script the actions of the radio/checkbox controls. I'm looking for a declarative solution. Are you suggesting using radio/checkbox controls and adding an attribute to them? Maybe that is a better solution. It would certainly degrade better than a new input type. -dean
[whatwg] [WF3]
This is something for Web Forms 3.0 (though it would be nice for WF2). In the repetition models I've implemented in the past (always tables) I've provided a way to select a table row. This meant including either a radio button or checkbox in the first column. When checked, the entire row would be selected. === I suggest introducing a new input type to facilitate the selection of repetition blocks: . This would render as either a radio button or checkbox depending on an additional constraint on the repetition template. When the selector control is checked it results in the repetition block being selected (the CSS3 ":selected" pseudo class would apply). repeat-selection="single|multiple" == I suggest adding a new attribute to repetition blocks (although this is only appropriate to repetition templates). "single" would be the default and would mean that only one block can be selected at a time. If another block is selected the currently selected block is deselected. controls are rendered as radio buttons. "multiple" means that any number of blocks can be selected. type="selector"> controls are rendered as checkboxes. Changes to the current definition of this control means that a type="delete"> element must be contained by a repetition block for it to be active. I suggest allowing the same constraints that apply to type="add"> so that the delete control can apply to selected elements if placed outside of a repetition block. In reality this means that you only need one delete button to control your repeating form controls. .selected DOM Property == Not sure we need this but it would be nice to be able to test whether or not a repetition block is selected using a DOM property. Other Possible Types The introduction of opens the door to other input types. Possibly and ? They would be similar to the add/delete controls but would use the clipboard. would delete selected blocks but store the associated data. would add new rows and populate them with data from the clipboard. -dean
