[whatwg] Web Forms 2.0 - repetition model control

On Sat, 15 Oct 2005 00:19:19 +0300, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 14 Oct 2005, ROBO Design wrote:
<...>
>
> You have a point. However, I think the benefit of the ease of authoring  
> of
> just having to type type="remove", rather than type="template-remove" or
> type="remove-block" or similar, should not be underestimated.
>
>
<...>
>
> I've added a note with such a link.
>
> I agree with you that there would be benefit in having the names more
> specific, but I think people would quickly get tired of typing it out all
> the time. (This is the same reason that <navigation> was renamed <nav> in
> the WA1 draft.) What do you think?
>

Hello!

Thanks for your answer.

You've made a mistake in the spec note you added :).

> Note: Four other new types, add, remove, move-up and move-down, have  
> been introduced. They are defined are part of <the repeating form  
> controls model>.

Correction:

> Note: Four other new types, add, remove, move-up and move-down, have  
> been introduced. They are part of <the repetition model for repeating  
> form controls>.

Yes, I also agree with your point and I was sure your reply will say that,  
yet if you want something shorter ... then use type="tpl-add" or find a  
better prefix.

<nav> instead of <navigation> is not a problem. It's actually an  
improvement.

Last, but not least, I must emphase that 'ease of typing' (or short  
attributes and tags) should not take over. This is because the  
specification may 'suffer' in the future, when new versions will be  
written. You should think of 'what if I will add something which also uses  
those keywords?'.

Another reason for not being 'afraid' of having the code more 'talkative'  
is that people use specialized editors with auto-complete or WYSIWYG  
editors. Therefore, the amount of chars needed to type ain't really that  
high.

Now, I got an idea. Not sure if it's acceptable at all, but ... why not?

You've added a new attribute to the <input> tag:  
template="some-template-ID". This is optional.

Why not leave the type= attribute alone and make better use of template=.  
How:

1. template="add|remove|move-up|move-down"
This behaves exactly as <input type="add|remove|move-up|move-down">
Note: without any specific declaration of a template ID.

2. template="some-ID;(add|remove|move-up|move-down)"
See where I am going? This would behave as <input  
type="add|remove|move-up|move-down" template="some-ID">

Perhaps this idea ain't 'the best', but with your experience maybe you can  
derive something better.

Having no type shouldn't cause any problems with older browsers: they will  
assume type="text", just like before.

Regarding the DOM:
- element.type should be as with any normal <input> tag the doesn't have  
the attribute.
- element.action = (add|remove|move-up|move-down)

Another idea that came up while writing this email. If the above would be  
done, that would be not so good, yet again. Here's why: an implementor  
must check if the <input> has a well-formed template= attribute, otherwise  
use the type= attribute. If the template= attribute is well-formed, then  
ignore the type= attribute. This not really good.

What would probably be better:
<input type="template" for="some-template-ID"  
action="add|remove|move-up|move-down">

Now, I know what you are thinking: that this suggestion adds even more  
chars for the devs to type, but this would probably better than the  
previous suggestion, since implementation is more straight forward and  
there's also better readability of the code.

Going back and reviewing all of the 3 suggestions ... first was the best:  
type="template-add". The second one requires less typing for web  
developers. Each suggestion has its weakness and strength.

As a conclusion, any of the 3 above would be better than what's currently  
in the spec. I really believe something should be done (if I am not too  
late)... this was the only thing that really seemed 'bad'/wrong  
immediately after reading.

You do what you think it's best.

-- 
http://www.robodesign.ro
ROBO Design - We bring you the future

Received on Saturday, 15 October 2005 10:05:02 UTC