I think changing the default size attribute is the right way to go. Automatic fix-up is nice in theory, but runs into a couple of problems: - Browsers will change, making your heuristic wrong later. Mozilla did exactly this - they changed their sizing algorithm to one that very closely matched Internet Explorer, so early attempts I made to sync them all up broke badly. - Developers who *are* aware of the issue will get very annoyed when their explicitly set values get changed in non-obvious ways.
-- Adam On 8/16/06, Joseph Rozier <[EMAIL PROTECTED]> wrote:
On further inspection for this particular issue, I've found that the number of characters displayed (depending on the device, font and font-size used) is just too variable to do any kind of automatic calculation. It looks like in this case the developer targetting a BlackBerry device will have to know that BlackBerry treats it as a hint. I'm still going to change the default size attribute (which is hard-coded in the renderers) for the case where the developer has not specified one. The general issue regarding how much app developers should have to target a particular device/browser in their code. Obviously a developer of an app for a company widely using BlackBerry Browsers will likely test it on that platform. But should an app developer expect everything to work/look right across all supported browsers without the need for actually trying each one? Take care, Joey On 8/15/06, Joseph Rozier <[EMAIL PROTECTED]> wrote: > Just to be clear, when I said the BlackBerry Browser "allows me to > type" a certain number of characters in an input text field, I meant > that that was the number of characters visible on screen at any given > time. This is unrelated to "maxColumns," which works fine. > > Take care, > > Joey > > On 8/15/06, Joseph Rozier <[EMAIL PROTECTED]> wrote: > > Hello, > > > > Another general question I'd like to get other people's thoughts on > > regarding how much we should handle in our renderers vs. how much we > > should expect the developer to handle with regards to browser-specific > > functionality/workarounds. > > > > The BlackBerry Browser does not honor the "size" attribute on an input > > type=text correctly. When it is specified (with default styles), it > > allows for significantly more space than expected (for example, if > > size="1", it allows me to type 4-6 capital M's, at size="10", it > > allows 16-18 capital M's. > > > > I've made a local change that makes this adjustment for the user > > automatically. If the user specifies the columns attribute on an > > af:inputText, I've written code that divides it by 1.7, which gets to > > approximately the desired behavior for most values. > > > > Should this go in the renderers, though? Or should the developer > > wanting his/her device to work on a BlackBerry Browser have to use an > > EL in the columns attribute each time, checking for the BlackBerry? > > > > If we DO code it in the renderers, though, then the user might get > > frustrated that we are adjusting the columns with no obvious way of > > overriding it. > > > > Where should the balance get struck in this case and in general? > > > > Thanks, > > > > Joey > > >
