[whatwg] Web Forms 2.0 - repetition model control
ROBO Design
robodesign at gmail.com
Sat Oct 15 10:05:02 PDT 2005
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
More information about the whatwg
mailing list