Re: Re[2]: WF2, abolish <button type=remove>

Hello Dmitry,
I agree with Josh Sled in opposition to your proposal.

> This in not analogous seggestion - it's necessary to rank buttons:
. . .
> It's disputable question, what is more clear: co-located control or button
in
> browser itself. But what is definitely, that quantity of remove-buttons
grows
> in _geometrical progression_ and make documents bulky.

I believe that your ranking of the various button types is subjective (and
personally unconvincing) and so does not bolster your proposal to remove the
repetition buttons. Removing repetition buttons is removing more features
from HTML5, features which give authors the ability to easily allow the user
to add, move, or remove repetition blocks (even if at the expense of being
"bulky"). If authors do not wish to add bulk to their documents, then they
may discard all repetition buttons and use the addRepetitionBlock,
moveRepetitionBlock, and removeRepetitionBlock methods to invoke the desired
repetition behaviors.

As it is, the buttons provide non-scripted contextual repetition controls
which are much more intuitive (and common UI conventions, a la Gmail file
attachments) than requiring the user to unconventionally access a browser
menu. So on the contrary to it being a "disputable question, what is more
clear," because of UI conventions, it *is* more clear to employ repetition
buttons.

Dimitry, can you provide an example of how your proposal is superior to the
current UI conventions and how it would facilitate access to repetition
functionality while at the same time giving authors control over which items
may be copied, moved, or deleted?

Regards,
Weston


On 5/29/07, Dmitry Turin <html60@narod.ru> wrote:
>
>
> Good day, Josh.
>
> JS> An analogous suggestion would be to move form reset and submit buttons
> JS> into the browser.
>
> JS> add/remove as well as reset/submit
>
> This in not analogous seggestion - it's necessary to rank buttons:
> (1) form contains one submit- and one reset-button,
> (2) repetation block contains one add-button
>     (but form can contains several and even nested repetation blocks,
>     thus form contains _several_ add-button),
> (3) copy of repeated block contains one remove-button
>     (but repetation block can consist of several copies,
>     thus repetation block contain several remove-button,
>     and form contains __several-in-square__ remove-button).
>
> I take _not_ arbitrary case (as you thought), but polar case.
> You try to refuse my proposal by bringing example from _opposite_ pole
> - that is not correct from point of logic.
>
> Ranking show,
> that necessity to abolish is different to different buttons.
>
> JS> if multiple forms are present on the page,
> JS> it's more clear to have each control co-located with its form.
>
> It's disputable question, what is more clear:
> co-located control or button in browser itself.
> But what is definitely,
> that quantity of remove-buttons grows in _geometrical progression_ and
> make documents bulky.
>
>
>
> Dmitry Turin
> http://html6.by.ru
> http://sql4.by.ru
> http://computer2.by.ru
>
>
>