[buddypress-trac] [BuddyPress Trac] #5914: Registration form: Proposed enhancements for touch devices

[buddypress-trac]

#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/>
BuddyPress Trac