How to control the predatory actions of different browsers

[Keith]

Hi, I have been testing my NT app using IE10 blissfully unaware of the ogres lurking in the dark corners of the room - Safari and Chrome and probably Firefox if I got around to looking.

My app has worked fine in IE10 but Safari and Chrome look as if they are trying to do smarter things and not doing them very well.  the short comment is that my app works in IE10 but doesn't in the others.

Here are some of the notes:

In Safari and Chrome:
My fields defined as Type = Number get Spinners
These Spinners don't always work right
Spinners are attached even to read only fields
Some fields with spinners refuse to display the value of the field, preferring blank

So, what to do?  As a test I changed a field from Type = Number to String and the spinner vanished in Chrome and the value reliably appeared.  That's good but I thought that defining the field as a string when it always had to be a number would be bad practice (though I have now noticed that you can type an 'a' into a 'number' field (and I can understand why) so maybe it doesn't matter as long as the value is edited?

But the bigger questions are why do these browsers do dumb things and how can they be stopped?

What's going on here and what is the recommended way forward?

Thanks

Keith

[Bruce]

Hi Keith,

The first thing to remember is that browsers from different companies are not the same piece of software. They most certainly do things differently. On the up side it's reasonably uncommon to see the difference in anything that matters.

Chrome and Firefox are a lot faster than IE. And are far ahead in implementing the HTML5 "specification". For development purposes I prefer Firefox with Firebug (www.getfirebug.com) but I also use Chrome a lot for every-day browsing. sorry to say but IE is far behind the pack, and the least compatible of all.

Another big advantage of chrome is that it shares a lot of the basic code-base with the browsers users are likely to encounter on phones and tablets. So you'll get a better compatibility test there as well.

>> But the bigger questions are why do these browsers do dumb things and how can they be stopped?

Each item you encounter can be handled on a case-by-case basis. Most things are just cosmetic (such as IE not supporting something that the others do) but in other cases there are simpler solutions. For example;

>> My fields defined as Type = Number get Spinners

The browser is free to present the number anyway they like. And they are free to format the number anyway they like. If you want to take advantage of the native browser (whatever native browser the user is used to) then use the number field. If you explicitly want a spinner then use the Spinner field. If you explicitly don't want a spinner then use the String field.

Cheers
Bruce

[Keith]

Thanks Bruce, a couple of points and my main follow on questions are in the attached document.

Firstly, if I write an app that will be accessed over the web I cannot dictate which browser is used to access it.  In practice all of them will be used.  This means that I cannot write it assuming Chrome or FireFox - the app has to work under all browsers.    We may have favourites but we have to cater for the pack.

Secondly, in the development environment attributes can be assigned to fields (Spinner number, string etc) but although we may think that we are defining the behaviour of the field (and think that we have explicit control) we don't because the browser makes up its own mind.  So this boils down to 'forget your judicious selection of attributes for your field (justification, read status etc) the browser will ignore them' which means that what you may have to do is to always be fooling the browser - say by using a declaration of String which at the moment appears to cut off the browsers propensity to make (erroneous) decisions.

My basic question here is that while NetTalk through attribute setting gives the impression that the developer has control over that attribute (say, justification) in fact he may not have control at all and is it possible for NetTalk to generate code which forces the browser to comply.

So have a look at the details of my gripes in the document.

I am assuming that for now the only solution is to declare all of these fields as String and that that will allow all of the other attributes to 'stick'.  Would this be a correct assumption?

Thanks

Keith

[attachment deleted by admin]

[Bruce]

Hi Keith,

>> Firstly, if I write an app that will be accessed over the web I cannot dictate which browser is used to access it.  In practice all of them will be used.  This means that I cannot write it assuming Chrome or FireFox - the app has to work under all browsers.    We may have favorites but we have to cater for the pack.

I completely agree. For the minority of folk still using IE, the app has to work. I think you'll find that any difference in the app from browser to browser is cosmetic. It's basically impossible for the app to _look_ exactly the same in all browsers, because they all have a different layout engine.

>> Secondly, in the development environment attributes can be assigned to fields (Spinner number, string etc) but although we may think that we are defining the behavior of the field (and think that we have explicit control) we don't because the browser makes up its own mind. 

yes and no. The NetTalk field types map to the HTML field types. If you know what the HTML fields do then you'll have some idea of what the app might be. Some fields are more "variable" than others. Your example, the NUMBER type, is new in HTML5 and the exact behavior of the field is left up to the browser (in the spec). The browsers have implemented it differently, but a user who uses IE, or Firefox, or Chrome doesn't know this. They just get what they are used to. Functionally the field is the same across all the browsers, but cosmetically it's different.

>> So this boils down to 'forget your judicious selection of attributes for your field (justification, read status etc) the browser will ignore them'

no, that's inaccurate.

>> which means that what you may have to do is to always be fooling the browser - say by using a declaration of String which at the moment appears to cut off the browsers propensity to make (erroneous) decisions.

I think perhaps you're taking your experience of one specific type and applying it to all types.

>> My basic question here is that while NetTalk through attribute setting gives the impression that the developer has control over that attribute (say, justification) in fact he may not have control at all and is it possible for NetTalk to generate code which forces the browser to comply.

I'm not aware of cases where you are being mislead - but browsers are continually changing. I believe the number field is documented specifically as being very much under the browsers control, and the String field is recommended over the Number in most cases.

>> So have a look at the details of my gripes in the document.

will do - reply to that in a different note.

cheers
Bruce

[bshields]

Hi Keith,

I feel your pain.

I also agree with Bruce.

What i can clarify is, using something other than IE as your default testing browser will mean that you will spend less time fixing your site afterward when you though it was already working for other browsers. IE is the most evil browser (frankly all versions) so coding for it by default will often result in a heap of issues.

However, coding for Chrome or Firefox by default often leaves less work to do afterwards to clean up cosmetic issues. NetTalk does allow you to use custom CSS files to address simple layout specific short comings.

Chrome and/or Firefox with Firebug will also help you gain a better understanding of how the browser is working, in terms of ajax and css. I find IE developer tools either non-existent or in newer versions just crap.

For what its worth I personally don't use number field types due to variations in how browsers support it.

Regards
Bill

[Bruce]

regarding the attached doc,
(I've tried to correct your terminology to differentiate between the _number_ type, and the _spinner_ type since they are very different.)

>> Question 1:  Why does Chrome (and Safari looks to have the same issue) blank these two fields?

a) In my test here primed fields appeared as "primed" in chrome. In your screen-shot they are blank.
Although I notice in your (Chrome) screen-shot 2 of the numbers were primed, 2 were not. Which makes me think perhaps the technique for priming them was different. Also I notice the two Flywheel values appear to be right Justified ok there.

>> Question 2: Is it recommended that [Numbers] be used noting the potential loads on the server?

The immediate value sent to server when (Chrome Number) changes. This should not be a problem (and you'll probably notice that "repeat mode" is somewhat deactivated here anyway, unless you re-activate it. It is possible to turn off immediate validation for the field (so nothing is sent to the server) but that's probably not what I'd do.

The "Spinner" field type only generates an event after you complete the field - so if you are concerned about this, use the spinner field instead.

>> Question 2b: Would it be guaranteed that the app would hold together if a spinner control is activated in ‘repeat’ mode?

The app would definitely hold together if it was activated in release mode in the sense that the server can handle much more load than a single number could generate. However the requests from one user are not the problem - ultimately there is a load limit somewhere regardless of whether the number control is being used or not.

>> Next, look at this Chrome display of fields with 2 decimal places:

with regard to the Number granularity - you can find a setting for this on the "Validation" tab for the number type. It defaults to 1, but you can set it to 0.25 if you prefer etc.

>> Question 3: Is it recommended that where it is known that the client side spinner logic is flawed is the only way to avoid it to declare the field as Type = String?

I'm not sure I'd describe it as flawed, but if you don't like the Number behavior in one or other browser then by all means use the String, or Spinner field types. Bear in mind that the Number field type is new to browsers, so it's likely you'll see browses change a fair bit on how they treat this field until it settles down.

>> Note also that if you declare the field as Type = Spinner then the browser behaviour is, yet again, different.  Here is Chrome displaying ‘Weight Kg’ (defined as Spinner). See that the spinner controls are outside of the field...

That's a CSS issue related to your choice of theme. I've improved the themes for the next build so you don't see this "field inside a field".

>> the number is left justified (even though in NT it is explicitly right justified)

well actually, there's no "Right Justify" setting for a spinner. That's an oversight though - I've added one for the 7.26 build.
ditto "read only" for the Spinner field.

>> Look also at these read-only fields defiantly sporting spinners which can’t be clicked!

That again is the number field - and is up to the browser how it wants to display the field in read-only mode.

>> Question 4: Has NetTalk any control over what the browsers do in order to enforce the properties defined in the field settings?

NetTalk is just the framework - so in that sense it controls nothing. What controls the browser is the HTML and CSS. And there are all sorts of things that HTML and CSS can control. But fundamentally browsers are different, so there will be differences.

You're thinking in a very "windows centric" way, partly because we've traditionally only made programs for a single platform - ie Windows. With the web you are making programs that will be displayed on multiple platforms - with different browsers available on each platform. Your user has chosen their browser on that platform presumably because they like the way that browser works. You can certainly give hints to the browser via CSS and HTML (and NetTalk does a fair bit of this for you) but ultimately the browser still has some control.

>>  It appears not to have now but could the browsers be forced by NetTalk to cooperate?

As you get more experienced in this you'll discover how you can more accurately describe to the browser what you want. There will still be areas outside your control, but you'll also discover the things that are in your control.

cheers
Bruce

[Keith]

Thanks Bill for those useful comments.  I will stick to 'String' for now and between you and Bruce I know why.

Bruce, also thanks for your voluminous notes.  I will do some more testing on the question of why some fields are blanked in Chrome but not in IE10.  I have eye-balled the properties of the blank ones and the non-blank and they look identical so there is something weird going on.  I will let you know if I find out what.

I will also do some more testing of the use of the Spinner control (Question 2) and report back - I feel there is more to this. 

I've got a lot more to digest now.

Cheers

Keith