Re: XForms Basic

Ian Hickson wrote:

>On Fri, 5 Dec 2003, Daniel Brooks wrote:
>  
>
>>In section 7.4 I'd like to see a seperate error code for the file picker
>>to indicate when the specified file is not found. Lumping it in with
>>other error coniditions will only generate confusion on the part of the
>>user. You can't say the field needs to be filled out, especially since
>>they would have to type in a value themselves to get that result. The
>>others fit even less well. I really do like the user defined error
>>status though. That's a really great idea.
>>    
>>
>
>An error code for "mising file" would open the way to a privacy leak. I've
>added a section that says that the file upload control is simply not
>successful when it doesn't point to a valid file.
>
>
>  
>
as long as the webpage cannot modify the value of the file upload field 
(and therefore control which file is uploaded), I think it'd be fine. 
However, making the field unsuccessful is just as good.

>>in 7.6, when you say "reset just the relevant control to its initial
>>value," do you mean that the UA uses just the initial value specified in
>>the value= attribute of the HTML, or is it supposed to also look in the
>>file specified by the control's form's data= attribute?
>>    
>>
>
>I meant the initial value, which is defined as the value given in the
>markup (value=""). Interesting point about resetting to the seeded value
>though, I hadn't thought of that.
>
>
>  
>
>>Also, the parts about the onformchange event aren't entirely clear. If
>>the onformchange event on the first form control changes the value of a
>>form control, does that cause another set of onformchange events, or are
>>they batched up somehow?
>>    
>>
>
>onchange is only triggered by _user_ initiated changes, so .value = "foo"
>can't change it. At least that's my intention. So the problem doesn't
>arise.
>
>
>  
>
Ah, ok.

>>Section 4.4.1 completely lost me. As I understand it, you're saying that
>>the onformchange event could take a stripped down form of javascript
>>(ecmascript) simply because declaritive dependancies are easier to
>>track. Why bother? The javascript interpreter that pretty much has to be
>>built into any modern browser can already do that for the full js syntax
>>(though perhaps that data is never exposed to the outside, and it'd
>>probably take just as long as running the code in the first place to
>>determine the dependancies, etc)
>>    
>>
>
>Some people are against scripting. This is just explaining to these people
>that if they want to, they can use this without script.
>
>
>  
>
Against scripting!? :)

>>The one large thing I'd do differently is the template/repeated block
>>stuff. With the system here, you have to completely specify the form
>>twice, first for the template and then for the first repeated block.
>>What I'd like to do is be able to just put repeat="repeated" on an
>>element and not put any content in it at all. The UA would take care of
>>filling out the DOM with a copy of the template's children. On the other
>>hand, maybe that's exactly what you had in mind and I just missed it.
>>    
>>
>
>Hmm, yeah, I had intended to do that but forgot. I'll add it to my list of
>things to try and add.
>
>
>  
>
>>It also might be nice to be able to for a repeate block to be a copy of
>>a template that isn't a sibling.
>>    
>>
>
>Maybe, but that would be hard. I've yet to actually see a use case for
>that one.
>
>
>  
>
Seperate it into two attributes, template="true" and repeat="templateid" 
or something like that. As for a use case, wouldn't nesting repeat 
blocks keep the inner one from working? I'll have to go back and reread 
that section, since I didn't have any idea what you were trying to 
accomplish until I'd read the entire section, and could put all the 
pieces together into a concept. You should probably put some more 
explanation about what it's going to do at the beginning of the section, 
rather than just starting out with a description of the attribute to 
use, etc.

>>Anyway, I think it's a great idea, even though it does make Page Info a
>>little harder ;) Well, maybe we'll call it more interesting instead.
>>    
>>
>
>:-) It actually shouldn't make much difference. You can still enumerate
>forms and you can still enumerate form controls. In fact it might even be
>easier, since you get the implied form now.
>
>Let me know if you want anything added to the DOM to help with that.
>
>  
>
Obviously page info would need to list the template and repeated blocks 
seperately.

I'll also have to go strictly off of the HTMLFormElement.elements list, 
but I think there's already a mozilla bug on that already because page 
info fails to find some fields for invalid forms that mozilla fudges. 
And putting a <form> element in the <head> of a document would just feel 
weird. I hope nobody really wants to do that :)

HTMLFormFields.templateElements gives me the controls in the template, 
which is good. I'd like to be able to get an array of HTMLCollections to 
represent the repeated blocks though. That could turn out to be a 
problem since repeated blocks can nest. I really have no idea how that 
would/should look in page info. Can you nest forms? I'm pretty sure you 
couldn't in XHTML and I didn't read anything in this proposal, so I 
guess not. I hope not :)

db48x

Received on Saturday, 6 December 2003 10:20:34 UTC