I totally confess to getting myself tied in knots with a coding issue and am appealing for help in establishing if my approach is correct or if I have I am off track and missing some really simple solution.
I am not sure if I should be posting here or in the php forum but I have opted for this forum first.
I wish to create a float based layout to display some mysql data. In order to make this dynamic and flexible 'ex' units have been used to size elements with in the layout and this works fine.
So I have built a couple of tables of Aspect Ratios assuming a default dpi of 96 with which I can convert from 'ex' to 'px' and visa versa. This works but it feels clumsy and I can't help thinking that there should be a more elegant approach to this.
The tables assume:
font in pixels = font in pts / 72 * 92
font in ex = font in pixels * aspect ratio
I note also that whilst my tables hold true to provide an approximate conversion for W3C compliant browsers they do not hold true for IE. I am concluding that IE uses a different default dpi or in some other way renders 'ex' units differently. Obviously using an appropriate assumed dpi resolves the problem with in my function but I would still like to understand why 'ex' units behave differently in IE.
I feel sure that relating 'ex' to 'px' must be a common layout issue so I am hoping that someone has a view on this an can guide me appropriately.
Yeah. That's always going to be trouble.
Your problem isn't so much that IE (likely just your copy) is different, but that how a font is displayed and what its relative size is, is heavily influenced by the desktop environment's settings on that machine, as well as browser settings. The font you choose to render must be available on all the platforms you want to reach, and if you look around this forum you'll see a recent thread where someone is exasperated by different rendering of a font at different sizes even. Some fonts may have a size where they are displayed "jaggedly" instead of smoothly.
Many browsers may start with "default px size" at 16, but this in turn is influenced by desktop settings, and may not actually render at 16px at all (such is the case with my machines).
It's a common issue on the front end for sure, but the solutions so far have been lots of math based on shaky default user assumptions.
I think you may have to decide when you want the information to be in a flexible unit relative to user settings (ex, em... btw I have no idea how well supported ex is, have you tried em?) and when the rendered font size is more important. In those cases, you may be simply writing the CSS (if CSS is doing the display) directly into pixels (and not converting but simply stating, "this tag gets displayed at this px size" etc). This still won't be absolutely the same cross-machine (as mentioned above, the font you choose has influence and odd-sized fonts may get slight rounding differences in browsers) but it should be close enough to satisfy.
In which case, you'll be looking at your flexible version and just look at the ratios between your different sizes (if you have a Heading size vs a plain-data size) and the spacing you have between lines and things. When you try a px version, you'd try to make the ratio of sizes look about the same.
I think we'd also need to see the data and the effect you are trying to accomplish. If it's tabular data is should be a table anyway but I'm wondering if you are over-thinking this and whether you need to size all the containers. It all depends on the data of course and the structure that you require.
No-one uses ex (not that I know of anyway) and you should use em for more reliability.
Echoing what Stommey said... Converting units is a bit like adding apples and oranges only worse.
When It comes to web design is not a really wise idea, and whatever methods get you close usually entail some sort of accessibility boondongle.
font in pixels = font in pts / 72 * 92
assumes a monitor setting of 92px/inch which is not always the case ( and I thought 96px /inch for flast screen was more common anyway... I could be wrong about that). In any case EX/ EM are relative to FONTSIZE.
Am not certain on how the entire page would work together... so this is conceptual suggestion. You COULD wrap entire layout in container the width of the sum total of all your EX measurements, and with a padding-left the width of all your PX measurements. Give the outermost (holding element) of your layout a negative margin-left of the sum total of all our PX measurements; this would suck it into the padding area of the wrapper. It's kinda convoluted, but it does work when adding apples and oranges. I hope that helps and I didn't miss what you were trying to say entirely.
Thank you for your input. I do see that mixing and matching these units is fraught with difficulty and prone to error or unexpected/inconsistent results across all browsers. Then when we add in the influence of the rendering attaining consistency appears to be impossible or least hopelessly overly complex.
Yes I agree that outputting the data as a table is robust and consistent but it is also rigid which was not what I was looking for.
I am interested in knowing why em's are favoured over ex's it is not clear to me why one should be more less reliable than the other.
From your input I have indeed applied the same units to the containers thus removing the need to compare ex's to px's I can't think why I didn't see that was the obvious thing to do before. I can of just as easily work in em's but I am not sure why I should be doing so.
It is obviously a whole field of study in its own right and it has been very interesting looking into this.
Apparently browser vendors made ex units even less consistent between each other than with ems. With some not really supporting it at all. zcorpan mentioned in an old thread that specifically IE and Gecko used two different measurements for the unit.
You can see why ex units are not as reliable as ems from the details in the specs:
Equal to the font's x-height. The x-height is so called because it is often equal to the height of the lowercase "x". However, an ‘ex’ is defined even for fonts that do not contain an "x".
The x-height of a font can be found in different ways. Some fonts contain reliable metrics for the x-height. If reliable font metrics are not available, UAs may determine the x-height from the height of a lowercase glyph. One possible heuristic is to look at how far the glyph for the lowercase "o" extends below the baseline, and subtract that value from the top of its bounding box. In the cases where it is impossible or impractical to determine the x-height, a value of 0.5em must be assumed.
There are various ways a UA can determine the x height so even though they all may do it differently and come up with slightly different values they may all still be following the specs.
em on the other hand can be found more easily.
Equal to the computed value of the ‘font-size’ property of the element on which it is used.
Hi Paul O'B
Yes I had seen that specification whilst reading around the subject the piece of the puzzle that I had not understood was that each browser does it's own calculations to establish x-height. One must assume therefore that the same applies for ascender descender and capital heights.
Sorry to keep displaying my ignorance but I thought that the TTF or Postcript or other file held all the Metrics for the given font and that there are various utilities for accessing these Font Metrics.
That being the case I had made the assumption that all the browsers would access and apply this data to achieve a consistent result. I can understand that the resulting displayed font will be function of this data and the method used by the browser to render this on the screen and this will result in minor differences. But now we are saying that we can't even rely on the value of x-height (or ascender or ....) being consistent.
So yes I see the difference in the reliability of ex and em.
This topic is now closed. New replies are no longer allowed.