[buddypress-trac] [BuddyPress Trac] #5914: Registration form: Proposed enhancements for touch devices
noreply at wordpress.org
Thu Jan 1 19:10:13 UTC 2015
#5914: Registration form: Proposed enhancements for touch devices
Reporter: standardspace | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: 2.2
Component: Theme / Template Parts | Version:
Severity: normal | Resolution:
Keywords: good-first-bug |
Comment (by hnla):
Replying to [comment:7 boonebgorges]:
> hnla - Aside from the fact that some of these are vendor-specific, which
is kind of icky from an aesthetic point of view, are there any negative
consequences of adding these attributes? This seems like a case where the
"nonstandard" nature of the attributes may well be outweighed by the
benefits to the user.
I hear your point, there are times when one weighs up benefits Vs
Standards, then again one would expect that if these are truly useful
attributes that they might be under CR in which case I would have less
qualms about using them.
Upholding Standards has been a long hard struggle which continues to this
day and likely for evermore, not so much a concern of 'ickynes' as a
concern of the slightest return to the code free for all that existed in
the early days of web development.
To answer the question though, no likely as not there won't be any
negative consequences and I have to acknowledge that the larger entities
on the web delivering api's deem it perfectly fine to 'invent' attributes
as suits their purposes regardless that they exist in any formal schema.
As to us employing these I'm still not sure it feels right, but as r-a-y
points out some of these are mobile specific so we would need to apply
them only if mobile device detected really, either using wp_is_mobile() or
building our own device detection class; not sure I'm happy to have BP
force these on me as as a web dev building a site as I might prefer to
make my own judgement call on this sort of thing?
>I wonder if, for username fields, what we really want is
spellcheck="false" and autocapitalize="off"
As this was your earlier suggestion i.e to use these but not
autocomplete='off' I doubt there would be particular issues, but again,
ideally would like them set conditionally.
Checking again and 'spellcheck' is actually a W3C CR while
'autocapitalize' remains proprietary - My personal view is that while it
remains proprietary and simply to aid a particular UA it should not be
used; 'false' ought to have been the default really and thus is more their
issue to resolve :) N.B I believe the value has been updated from a
boolean one to keyword 'none'
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5914#comment:8>
BuddyPress Trac <http://buddypress.org/>
More information about the buddypress-trac