--- Comment #19 from MZMcBride <> ---
(In reply to comment #16)
> It's a perfectly valid argument. Yes, after the days of ftp and usenet, the
> web experience has involved many sites with a different look and feel. And
> despite this, certain UI widgets like radio buttons, checkboxes, drop-down
> lists and text boxes (where there is no need for them to differ between sites)
> have been standardized by HTML tags like "input". When a website switches from
> these to custom AJAX widgets that do the same thing, users are absolutely
> correct to say that this is a functionality regression.

Only if the AJAXified widget introduces actual regressions, of course. AJAX,
like anything else, can be misused. But if we assume good faith, we can imagine
that most programmers write additional code of this nature to add
features/benefit to the user experience. Any regressions need to be weighed
against actual benefit (cost–benefit analysis is a part of any code).

> Well this would certainly decrease code bloat wouldn't it? If killing the
> feature is on the table, I would first invert the option so that users have
> to specifically enable suggestions to see them.

I don't think killing the option is realistically on the table. I think most
users like the suggestions (or at least don't mind them). We could survey a
random sample of users to get better data on the matter. For better or worse,
we currently rely largely on anecdotal evidence and general best practices when
deciding matters of this nature (reducing user interface clutter, reducing code

> I don't think this is a solution. If you hide suggestions with CSS, the
> "autocomplete" attribute is still off. This means that no search history
> shows up like it used to.

This is browser-level search history, right? Doesn't this drop-down also
obstruct the buttons? (And potentially introduce privacy concerns, no?)

You are receiving this mail because:
You are on the CC list for the bug.
Wikibugs-l mailing list

Reply via email to