Phillip, I appreciate your problem space. The intelligence you want to see in user agents is I think worthy of consideration. The challenges are not quite simple though as you said. I'm not sure whether such a preference setup is advisable or not. I would not want my browser assuming I want to see all values in metric or other standard units of measure. I think I would prefer the author communicate information in his/her preferred units and that if the unit of measure could be marked up so that the user agents know they are measurements that I could right click on and choose another similar unit of measure. That is, if the unit of measure is a length I shouldn't necessarily be able to select Fahrenheit. For metric units it might be nice to also specify engineering vs scientific notation like on a scientific calculator and set the precision, and possibly set the base to use for display (i.e. 2 would show a binary number, 8 octal, 10 decimal, 16 hexadecimal) that would take care of your use case of knowing how to change from m to cm.
Somebody mentioned that a float is just a number with a decimal. Well, yes and not yes. There's the notion of maintaining full significance. If you have a float with ten significant decimal digits you may want to only display two to four of them (rounding up the last digit causing rounding errors if you were to use the value for additional math). However if it were possible to maintain the full precision and display something more readable and if the number were copied through a right-click action and the clipboard be populated with the full precision you would have the ability to transfer complete data while making it visually less complicated. I have some background working on multimedia interfaces for scientific data. We did a lot of that, displaying less precision than we maintained. In fact if you read the documentation for Microsoft's calculator program (I know who does that, right?) you'll see that if you enter values in fraction notation that it maintains the fractional representation of the number until you explicitly perform some operation using a decimal number in order to maintain accuracy and remove floating point errors. So if you entered 1 3/4 the UI may display 1.75 but it is holding 1 3/4 but if you add .5 and it displays 2.25 it holds 2.25. Transferring content for human consumption and transferring it for computational consumption are two different problem spaces, but HTML *could* allow both to happen ... to a degree. The option tags for instance have a label and value attribute which is precisely for this sort of scenario; having a difference between what is displayed and actual value. But, there will be some industry with its own unit of measures or common but avoided units (I work with GIS data, I think lat/lon, geoids, and projections qualify as common but avoided units; if you don't know about them you probably don't want to) and it is not reasonable to expect users to have to set preferences to convert all lat/lon mercator units to lambert conic conformal units unless they are using mapping software in which case that isn't html's concern. I don't know where to draw the line between what units should be supported and which shouldn't and I doubt the team at W3C want to have to make that choice either. And given that I can see the logic of a data tag. I'm not sure the W3C is the channel to try to get something like this implemented though. I think we'd need to inspire a user-agent developer to implement the desired behavior and then the W3C if it deemed ti worthy would add it to the spec. Ian has said on multiple occasions that he is trying to get a spec that the user agents will use. So, that implies new tech be developed and then standardized/specified after the fact. Whether they should add something to the spec or not gets back to the fundamental question of what HTML is and isn't? Do'h! another long email. Art C On Nov 7, 2011, at 5:43 PM, Philip Gladstone wrote: > The situation that I deal with is in the representation of lengths, speed, > temperature etc. Who responsibility is it to get these displayed in the > correct units (for some definition of the word "correct"). Having the web > server generate the values according the first accept-language seems a broken > approach. For example, for language 'en', should Fahrenheit or Centigrade be > used? For lengths in the UK, I would expect younger people to be more > familiar with metric units and older people with imperial units. I don't > think we want the web server to know about the age of the user in order to > generate the correct content. > > This all argues for being able to tag data in such a way that it can be > rendered appropriately by the browser (which presumably has more information > about the user). I admit that there will be challenges in deciding which > units to use for length. Is 0.001 meters to be shown as 0.1 cm, 1mm or even > 0.001 meters? For metric speeds, sometimes m/s is the right unit, sometimes > km/h. > > I suspect that this will all be solved by some (pseudo-standard) JS library > that gets access (somehow) to units preferences for various values. Maybe the > only thing that needs to be standardized is that preferences API. >
