Re: [WSG] Opera Targeting?!
Brett Patterson wrote: [...] Now I realize where most of my problems have stemmed from. Note that nearly all such designer bugs will be caught if you follow WCAG2 recommendations and resize text in a browser to at least 200% of browser default. (Default is 16px on 96dpi screen resolution in nearly all browsers, so 200% will be 32px on that resolution. Numbers grow with higher screen resolutions, but browser do not yet agree on how to deal with / adjust for rising screen resolution.) - If you can't resize text in the browser, then it's probably IE and the font-size unit is the wrong choice. Time to re-think design. - If design/layout breaks in unacceptable ways when subjected to font resizing stress, then the design/layout is at fault. Time to re-think design. Nothing you can do to prevent end-users from stress-testing your creations - because they want to or because they have to, so it is always best to test beyond breaking-point across browser-land before release. In the end you as designer/developer, consciously or unconsciously, decide how much your creation(s) should be able to take before it becomes unacceptable. FWIW: I didn't stress you layout on first load in any browser, but it showed serious shortcomings anyway. Later when I did put it under stress by applying regular browser-options to it... http://www.gunlaug.no/contents/wd_additions_37.html ...it revealed its weaknesses. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
On Feb 4, 2009, at 3:02 AM, Gunlaug Sørtun wrote: Brett Patterson wrote: [...] Now I realize where most of my problems have stemmed from. Note that nearly all such designer bugs will be caught if you follow WCAG2 recommendations and resize text in a browser to at least 200% of browser default. (Default is 16px on 96dpi screen resolution in nearly all browsers, so 200% will be 32px on that resolution. IS 200% one time font size increasement or two? My practise for a good layout is two times increasement, and I try to accommodate one decrement, but sometimes with certain design layout, especially with floated elements that either one or both have background image(s) that the underneath div block has different background color, it's just too much work to take good care and I let it goes without guilt :) tee *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
tee wrote: IS 200% one time font size increasement or two? 200% is twice the default size, and the number of steps to get there varies from browser to browsers. Again: _default_ isn't whatever size you have declared in/for your document, but the browsers' own defaults. This default font size is what you see on your screen(s) when you do not declare font-size at all in your documents. Then, make the letters in the text twice as tall in the browser itself, without zooming the page as a whole. That is 200% font resizing - the kind that actually works for end-users. My practise for a good layout is two times increasement, and I try to accommodate one decrement, but sometimes with certain design layout, especially with floated elements that either one or both have background image(s) that the underneath div block has different background color, it's just too much work to take good care and I let it goes without guilt :) Guilt would be misplaced no matter what, and shouldn't be an issue. No matter what you do you're in good (or good) company :-) It is however your creation that gets broken if it can't take a reasonable amount of the stress it risks getting exposed to when end-users use their browsers as designed, so you can't complain about it being broken either. That foreground and background get somewhat detached here and there is quite normal, and in some cases unavoidable with today's browsers and standards when background-images are used. Resizing of background-images to go with containers is only implemented on an experimental level in one or maybe two browsers - have only seen/tested it in Opera. We have only the tool-set that is available in browsers at any given time to play with, and when that tool-set isn't sufficient we either have to scale back our, or our clients', ambitions and use somewhat safe solutions, or we have to accept that our designs break. Minimizing the problems caused by breakage at the user-end is an important part of web design IMO, and trying now certainly makes it easier to pick up and make use of new design tools as they become available to us. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
On 2009/02/04 09:19 (GMT-0500) Brett Patterson composed: Okay, one quick question. You say 200% is twice the default size, but in browsers like Firefox 3, there is only the (shortcut) Ctrl++ to zoom in, and I cannot find the percentage of that zoom, so is 200% font size increasement one or two clicks? Firefox is a Gecko browser with a minimalistic feature set. Another Gecko browser, SeaMonkey, with a more extensive native feature set, lets you choose directly the % you want. It has selectable presets in its view menu. Among them, the third is 200%, which might lead one to believe it would take 3 successive shortcuts to reach 200% in FF. However, http://hg.mozilla.org/releases/mozilla-1.9.1/rev/1d6410485164 shows that's what it used to be, and what it was changed to (6). A quick look shows current FF3 appears to take 6 steps to reach 200%. Try FF2 or SM release if you wish fewer steps to get there. -- Do not let any unwholesome talk come out of your mouths, but only what is helpful for building others up. Ephesians 4:29 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
Brett Patterson wrote: Okay, one quick question. You say 200% is twice the default size, but in browsers like Firefox 3, there is only the (shortcut) Ctrl++ to zoom in, and I cannot find the percentage of that zoom, so is 200% font size increasement one or two clicks? Much more than that, I'm afraid. Side-by-side comparison and measuring on various OSes (96dpi res. all to avoid any misunderstandings) reveals the following: - Firefox (3.0.5 3.1b2) seems to increment in 10% mouse-wheel steps for both 'text zoom' and 'whole page zoom'. That means 10 steps (or clicks) from default to 200% of default for both zoom variants. - IE8rc1 increments its 'whole page zoom' in 5% mouse-wheel steps, with the usual +/- 2steps a' 25% for 'font resizing'. The latter only allows for 150% of default. - Opera (all versions) increments its 'whole page zoom' in 10% mouse-wheel steps. - Konqueror seems to increment in 10% mouse-wheel steps for both 'text zoom' and 'whole page zoom'. -- Note that 200% resizing means each letter take up 4 times the space compared to on default size, regardless of zoom variant. Simple square calculation. So, calculating in a one or two clicks range while designing, doesn't count for much. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
Not quite right im afraid. Patrick Lauke sent an email about this in December that highlighted the Firefox zoom config as shown below: -- Quote -- toolkit.zoomManager.zoomValues, and this will show the various zoom factors at each step. In my case (which should be the default) these are: .3, .5, .67, .8, .9, 1, 1.1, 1.2, 1.33, 1.5, 1.7, 2, 2.4, 3 So, nominally 200% (which, according to the Understanding... bit for that SC, means 200%, that is, up to twice the width and height - so really a 400% increase in total area) is actually 6 steps, if you want to go purely by numbers. -- End Quote -- David Gunlaug Sørtun wrote: Side-by-side comparison and measuring on various OSes (96dpi res. all to avoid any misunderstandings) reveals the following: - Firefox (3.0.5 3.1b2) seems to increment in 10% mouse-wheel steps for both 'text zoom' and 'whole page zoom'. That means 10 steps (or clicks) from default to 200% of default for both zoom variants. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
Okay, one quick question. You say 200% is twice the default size, but in browsers like Firefox 3, there is only the (shortcut) Ctrl++ to zoom in, and I cannot find the percentage of that zoom, so is 200% font size increasement one or two clicks? -- Brett P. On Wed, Feb 4, 2009 at 7:47 AM, Gunlaug Sørtun gunla...@c2i.net wrote: tee wrote: IS 200% one time font size increasement or two? 200% is twice the default size, and the number of steps to get there varies from browser to browsers. Again: _default_ isn't whatever size you have declared in/for your document, but the browsers' own defaults. This default font size is what you see on your screen(s) when you do not declare font-size at all in your documents. Then, make the letters in the text twice as tall in the browser itself, without zooming the page as a whole. That is 200% font resizing - the kind that actually works for end-users. My practise for a good layout is two times increasement, and I try to accommodate one decrement, but sometimes with certain design layout, especially with floated elements that either one or both have background image(s) that the underneath div block has different background color, it's just too much work to take good care and I let it goes without guilt :) Guilt would be misplaced no matter what, and shouldn't be an issue. No matter what you do you're in good (or good) company :-) It is however your creation that gets broken if it can't take a reasonable amount of the stress it risks getting exposed to when end-users use their browsers as designed, so you can't complain about it being broken either. That foreground and background get somewhat detached here and there is quite normal, and in some cases unavoidable with today's browsers and standards when background-images are used. Resizing of background-images to go with containers is only implemented on an experimental level in one or maybe two browsers - have only seen/tested it in Opera. We have only the tool-set that is available in browsers at any given time to play with, and when that tool-set isn't sufficient we either have to scale back our, or our clients', ambitions and use somewhat safe solutions, or we have to accept that our designs break. Minimizing the problems caused by breakage at the user-end is an important part of web design IMO, and trying now certainly makes it easier to pick up and make use of new design tools as they become available to us. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
David Dixon wrote: Not quite right im afraid. Patrick Lauke sent an email about this in December that highlighted the Firefox zoom config as shown below: -- Quote -- toolkit.zoomManager.zoomValues, and this will show the various zoom factors at each step. In my case (which should be the default) these are: .3, .5, .67, .8, .9, 1, 1.1, 1.2, 1.33, 1.5, 1.7, 2, 2.4, 3 So, nominally 200% (which, according to the Understanding... bit for that SC, means 200%, that is, up to twice the width and height - so really a 400% increase in total area) is actually 6 steps, if you want to go purely by numbers. -- End Quote -- David Ok, but then 200% 'whole page zoom' in Opera and IE8rc1 is _much more_ than 200%, because when I overlay Firefox (3.0.5 3.1b2) with 'text only zoom' on any of these two (Opera and IE) at that 200% 'whole page zoom', I need 10 mouse-wheel steps up from default (100%) to reach the text-size and line-height they're at (at 200%), as shown below. Gunlaug Sørtun wrote: Side-by-side comparison and measuring on various OSes (96dpi res. all to avoid any misunderstandings) reveals the following: - Firefox (3.0.5 3.1b2) seems to increment in 10% mouse-wheel steps for both 'text zoom' and 'whole page zoom'. That means 10 steps (or clicks) from default to 200% of default for both zoom variants. Both Opera and IE8rc1 have 'whole page zoom' selectors showing 200% as a value - seen in the lower-right corner of their chrome, and I can't imagine that these two (competing) browsers agree that 200% means exactly the same and that this same value is then *not* really 200%. I also cross-checked using the same screens (96dpi res.), OSes (win2K, XP, Vista, Ubuntu) and mouse/keyboard (connected via Synergy), and can't find the cause for my errors. Rounding-errors caused by trying to hit the same number of screen pixels at the same resizing levels via different calculation algorithms, become insignificantly small at 200% resizing level. Maybe someone can do a control check, measure the actual sizes on screen for zoom values and mouse-wheel resizing steps for 'text resizing' vs 'full page zoom' set at shown values, and let us know the results. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
Gunlaug Sørtun wrote: Maybe someone can do a control check, measure the actual sizes on screen for zoom values and mouse-wheel resizing steps for 'text resizing' vs 'full page zoom' set at shown values, and let us know the results. Just to make sure we're resizing the same way: notice that I refer to mouse-wheel steps everywhere, and not 'view drop-down options' or keyboard 'ctrl + +'. These non-mouse resizing options have 6 steps from 100% to 200% in Firefox - as Patrick Lauke presented it, for both 'full page zoom' and 'text only zoom'. Guess that accounts for my error :-) regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
On Wed, 4 Feb 2009 03:37:19 -0800, tee wrote: IS 200% one time font size increasement or two? While FF 3 does not tell you, Firebug will show you the calculated font-size in pixels after re-sizing. In the CSS panel, choose Options Show computed style. Hope this helps. Cordially, David -- *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
On Wed, 4 Feb 2009 03:37:19 -0800, tee wrote: IS 200% one time font size increasement or two? While FF 3 does not tell you, Firebug will show you the calculated font-size in pixels after re-sizing. In the CSS panel, choose Options Show computed style. Hope this helps. Cordially, David -- *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
I do not use conditional comments myself as I have coded a css parser to
handle all these differences... but anyhow.. you could try and get Opera
looking correct and then use conditional comments as needed for the
other browsers. Just a suggestion, I am sure others here will know how
to target using conditional comments.
For those that are interested, my parser works like the following:
/* Firefox
h1 {
color: red;
}
*/
/* Opera
h1 {
color: blue
}
*/
So it will render as it detects and finds matches, it can match any
combination of OS, browser and version, for example:
/* Safari p {color: blue;} */
/* Firefox 2 p {color: red;} */
/* Opera 9.10 Win p {color: pink; }*/
No more hacks or conditional statements for me. And no more problems
like Brett is having :)
Brett Patterson wrote:
Hello All,
I am in the process of working on my portfolio. It is not complete
yet, but one problem with my navigation menu on the top exists.
Although it is a minor pixel alignment in Opera, I cannot, for the
life of me, figure out why only Opera is aligning my tabs (which are
the top part of my navigation) 1px above the bottom border. If my site
is visited in Firefox or Internet Explorer first, you can see that
everything aligns perfectly. Is there a way to target Opera
specifically? I have used conditional comments, including !--[if
IE]!-- to !--[if NN]!--.
My site can be seen at
http://ttcharriman.edu/TTCH07/iftprojects/brettpatterson/index.html
Can anyone help, please?
--
Brett P.
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] Opera Targeting?!
Brett Patterson wrote: If my site is visited in Firefox or Internet Explorer first, you can see that everything aligns perfectly. Not if that browser is called IE8, I'm afraid. IE8 agrees with Opera10alpha. http://ttcharriman.edu/TTCH07/iftprojects/brettpatterson/index.html It's a designer-bug. Vertical position of the navigation relies entirely on font size, which means it is all over the place in my browsers on first load. No two browsers calculate font size exactly the same before rendering, so relying on pixel-perfect font size across browser-land is not a good idea. Add in font resizing and other regular options in browsers, and it gets a lot worse - for the whole layout. You should rethink the positioning method, and forget about deviations between browsers until you have stabilized it in one. FWIW: there are no reliable ways to target Opera anymore. You can't even know for sure if Opera is Opera. Besides: one should only target/hack dead browsers, like IE7 and older. Targeting/hacking live browsers like Opera, Firefox, Safari etc. for real, will only create maintenance-problems as new versions arrive. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
On Tue, Feb 3, 2009 at 2:41 PM, Gunlaug Sørtun gunla...@c2i.net wrote: David Dixon wrote: Chomping at the bit to dismiss IE7 a little early aren't we Georg? :) :-) Look at IE7 from a designer/developer's point of view... IE7 is dead - meaning: stable, Ah, well, most people would consider dead and stable to be two entirely different things. Dead is more akin to abandoned or unsupported. And it's still entirely possible that while Microsoft is supporting IE 7, they could release a patch for it, if they ever decide they need to. -- -- Christian Montoya mappdev.com :: christianmontoya.net *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
There are patches for Internet Explorer, though Microsoft calls them several different things, it could be a Security Update for Internet Explorer, a Cumulative Security Update for Internet Explorer, or even a Security Update for Windows (maybe worded differently on the last one). They just update IE differently then all the other browsers update their own. Microsoft does not really use v3.0.8 like Firefox would, 9.26 like Opera would, etc. -- Brett P. On Tue, Feb 3, 2009 at 3:13 PM, Brett Patterson inspiron.patters...@gmail.com wrote: I really don't understand what you mean, when you say: It's a designer-bug. Vertical position of the navigation relies entirely on font size, which means it is all over the place in my browsers on first load. No two browsers calculate font size exactly the same before rendering, so relying on pixel-perfect font size across browser-land is not a good idea. Add in font resizing and other regular options in browsers, and it gets a lot worse - for the whole layout. The problem should not rely on font size, but rather the margin from the top of the item that margin-top is being applied to, to the bottom of the item that is directly above the item that margin-top is being applied to, correct? I mean I do know that font size across browsers does not render the same, but if using pixels for a font size, should the pixels (in relation to size) render the same? I would think they would, but maybe I am wrong. You should rethink the positioning method, and forget about deviations between browsers until you have stabilized it in one. I do not understand this either, unless you are talking about using margin as the positioning method. I have stabilized it one browser. This is why I am worried about the deviations in all the others. FWIW: there are no reliable ways to target Opera anymore. You can't even know for sure if Opera is Opera. I do understand this. But I was hoping there was a way, like using JavaScript. I can understand if there is not one though. Besides: one should only target/hack dead browsers, like IE7 and older. Targeting/hacking live browsers like Opera, Firefox, Safari etc. for real, will only create maintenance-problems as new versions arrive. This is the most confusing part. IE7 is a live browser, if it is not then how can Opera, Firefox, Safari, etc., be? Every new version is then a stable version (dead version, though dead almost sounds as though you would mean like IE3 or Netscape 3). Or, are you saying that there will never be updates for IE7, though upon saying that, it would be incorrectly considered stable? -- Brett P. On Tue, Feb 3, 2009 at 2:41 PM, Gunlaug Sørtun gunla...@c2i.net wrote: David Dixon wrote: Chomping at the bit to dismiss IE7 a little early aren't we Georg? :) :-) Look at IE7 from a designer/developer's point of view... IE7 is dead - meaning: stable, so if it acts up and there isn't a suitable solution that all browsers can see, there's no harm whatsoever in hacking its dead body to pieces. IE7 can't come back to haunt us, no matter how many users it has. No other browser/version will ever see what we feed IE7 only - with the right targeting method, apart from maybe IE8 (and probably its successors if it gets any) when it mimics IE7 in (backwards) compatibility view. Gunlaug Sørtun wrote: Besides: one should only target/hack dead browsers, like IE7 and older. Targeting/hacking live browsers like Opera, Firefox, Safari etc. for real, will only create maintenance-problems as new versions arrive. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
Christian Montoya wrote: On Tue, Feb 3, 2009 at 2:41 PM, Gunlaug Sørtun gunla...@c2i.net IE7 is dead - meaning: stable, Ah, well, most people would consider dead and stable to be two entirely different things. Dead is more akin to abandoned or unsupported. OK, guess my choice of word can easily be misunderstood. I consider software to be dead and stable the moment a real successor is on its way, and the old piece isn't upgraded any more and can be safely separated from all others. IE7 is there now, IMO. I place FF2 in the same category btw, although is is slightly harder to separate it safely from its successor - FF3. And it's still entirely possible that while Microsoft is supporting IE 7, they could release a patch for it, if they ever decide they need to. IE7 is supported in the sense that it gets security patches and alike when there's a need for it. Its rendering engine won't see any major upgrades, simply because of Ms fear of breaking the web. That fear has been sufficiently documented and demonstrated by now. IE8 is the major upgrade of/from IE7, and the only potential problem here is that IE8 will not be able to emulate IE7' rendering perfectly down to the minutest details and combinations - there are simply too many details and combinations to test and tune. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
Brett Patterson wrote: You should rethink the positioning method, and forget about deviations between browsers until you have stabilized it in one. I do not understand this either, unless you are talking about using margin as the positioning method. I have stabilized it one browser. This is why I am worried about the deviations in all the others. Apply font resizing in any browser, and you'll get larger positioning-errors for the menu in _that_ browser than you get between browsers when leaving all at their font size defaults. Same version of same browser (Firefox 3.0.5) with similar settings on different OSes already position the menu with much more that 1px deviation - more like 20px, so I had to check across my entire browser/OS range to see where you really wanted that menu to stay on the page. Sorry, but that doesn't look stabilized to me. My point is that elements are not styled to work well together under even the slightest amount of stress in any browser, which means it is much too early to correct 1px deviations in any of them. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
On 2009/02/03 15:13 (GMT-0500) Brett Patterson composed: On 2009/02/03 19:54 (GMT+0100) Gunlaug Sørtun composed: I really don't understand what you mean, when you say: It's a designer-bug. Vertical position of the navigation relies entirely on font size, which means it is all over the place in my browsers on first load. Users' browser defaults, and minimum text sizes, and zoom levels, vary, mostly upward from the sizes designers prefer. As a consequence, positioning with font size as the base reference usually means unpredictability of results in the wild. ...using pixels for a font size... Px for sizing text is your affirmative design choice that whatever text sizes are acceptable to or preferred by your design's visitors are utterly irrelevant, and not a matter of design consideration. -- Do not let any unwholesome talk come out of your mouths, but only what is helpful for building others up. Ephesians 4:29 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
On 3/2/09 20:13, Brett Patterson wrote:
I really don't understand what you mean, when you say:
It's a designer-bug. Vertical position of the navigation relies entirely
on font size, which means it is all over the place in my browsers on
first load.
No two browsers calculate font size exactly the same before rendering,
so relying on pixel-perfect font size across browser-land is not a
good idea. Add in font resizing and other regular options in browsers,
and it gets a lot worse - for the whole layout.
The problem should not rely on font size, but rather the margin from the
top of the item that margin-top is being applied to, to the bottom of
the item that is directly above the item that margin-top is being
applied to, correct?
I think Gunlaug is referring to this (simplified):
div id=hdr
img alt=Text equivalent src=logo.gif /
div id=pageheader
Title here
div id=tabs
Tabs here
/div
/div
/div
#hdr {
border-bottom: 1px solid #CC9966;
height: 90px;
}
#pageheader {
float: left;
}
You've floated #pageheader out of the normal flow that determines the
height of #hdr, and there's nothing in place to force #hdr to contain
the lowest floated descendant. The logo image is in normal flow but it
is 85px tall, so what determines the height of #hdr is the height:
90px; setting.
Consequently, the alignment of the bottom of #tabs with the bottom
border #hdr depends on #pageheader actually being 90px tall. Since it's
got text inside it, and you can suggest but cannot expect a font height
(and therefore cannot even make a reliable prediction about how many
lines a given string will need), that dependency is brittle in the
extreme. In Firefox 3's Zoom submenu (under the View menu) try ticking
Zoom Text Only and then zooming in twice to watch it break horribly,
with the title text wrapping to the next line forcing the tabs entirely
below the border.
For further reading see:
* http://www.w3.org/TR/CSS21/visudet.html#the-height-property
* http://www.w3.org/TR/CSS21/visudet.html#Computing_heights_and_margins
* http://www.ejeliot.com/blog/59
I mean I do know that font size across browsers does not render the
same, but if using pixels for a font size, should the pixels (in
relation to size) render the same?
I'm not entirely sure I understand the question (in relation to size -
size of what?).
The size of a CSS pixel is intended to be relative to the resolution of
the viewport, and is ultimately up to the user agent:
Pixel units are relative to the resolution of the viewing device, i.e.,
most often a computer display. If the pixel density of the output device
is very different from that of a typical computer display, the user
agent should rescale pixel values. It is recommended that the reference
pixel be the visual angle of one pixel on a device with a pixel density
of 96dpi and a distance from the reader of an arm's length. For a
nominal arm's length of 28 inches, the visual angle is therefore about
0.0213 degrees.
http://www.w3.org/TR/CSS21/syndata.html#length-units
Most desktop browsers make a CSS pixel a monitor pixel, however most
desktop browsers (Opera, IE7, IE8, Firefox 3) also include a zoom
function that changes the effective pixel size up or down. Note that
some zoom functions (Opera, IE8) include fit-to-width reflowing
capabilities that mean that there's no guarantee that a box width in px
will remain proportional to a font height specified in px.
Most desktop browsers (IE, Firefox, Safari) allow users to adjust the
font size up or down in steps. In IE's case, these adjustments do not
affect font sizes specified in pixels.
In addition, most desktop browsers (IE, Opera, Firefox, Safari) enforce
minimum font sizes in real pixels and allow users to change them, and
allow users to disregard publisher suggestions about font size and set
enforce their own preferences.
--
Benjamin Hawkes-Lewis
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] Opera Targeting?!
Oh! I get it. Finally!!! :) It has always been my understanding, from some
books that I have read (like CIW's books, ciwcertified.com, which go into
some detail just not a lot) and a few others, that a pixel (in relation to
size, meaning if you looked at your screen closely the little squares on
your screen are natural pixels but the computer/browser/other settings can
change the default size) was only enlarged meaning that 1px would be one
pixel, but take up so many of the screen's natural pixels if the user
enlarged the screen.
But what you said makes more sense than that. Now I realize where most of my
problems have stemmed from.
--
Brett P.
On Tue, Feb 3, 2009 at 6:27 PM, Benjamin Hawkes-Lewis
bhawkesle...@googlemail.com wrote:
On 3/2/09 20:13, Brett Patterson wrote:
I really don't understand what you mean, when you say:
It's a designer-bug. Vertical position of the navigation relies
entirely
on font size, which means it is all over the place in my browsers on
first load.
No two browsers calculate font size exactly the same before rendering,
so relying on pixel-perfect font size across browser-land is not a
good idea. Add in font resizing and other regular options in browsers,
and it gets a lot worse - for the whole layout.
The problem should not rely on font size, but rather the margin from the
top of the item that margin-top is being applied to, to the bottom of
the item that is directly above the item that margin-top is being
applied to, correct?
I think Gunlaug is referring to this (simplified):
div id=hdr
img alt=Text equivalent src=logo.gif /
div id=pageheader
Title here
div id=tabs
Tabs here
/div
/div
/div
#hdr {
border-bottom: 1px solid #CC9966;
height: 90px;
}
#pageheader {
float: left;
}
You've floated #pageheader out of the normal flow that determines the
height of #hdr, and there's nothing in place to force #hdr to contain the
lowest floated descendant. The logo image is in normal flow but it is 85px
tall, so what determines the height of #hdr is the height: 90px; setting.
Consequently, the alignment of the bottom of #tabs with the bottom border
#hdr depends on #pageheader actually being 90px tall. Since it's got text
inside it, and you can suggest but cannot expect a font height (and
therefore cannot even make a reliable prediction about how many lines a
given string will need), that dependency is brittle in the extreme. In
Firefox 3's Zoom submenu (under the View menu) try ticking Zoom Text Only
and then zooming in twice to watch it break horribly, with the title text
wrapping to the next line forcing the tabs entirely below the border.
For further reading see:
* http://www.w3.org/TR/CSS21/visudet.html#the-height-property
* http://www.w3.org/TR/CSS21/visudet.html#Computing_heights_and_margins
* http://www.ejeliot.com/blog/59
I mean I do know that font size across browsers does not render the
same, but if using pixels for a font size, should the pixels (in
relation to size) render the same?
I'm not entirely sure I understand the question (in relation to size -
size of what?).
The size of a CSS pixel is intended to be relative to the resolution of the
viewport, and is ultimately up to the user agent:
Pixel units are relative to the resolution of the viewing device, i.e.,
most often a computer display. If the pixel density of the output device is
very different from that of a typical computer display, the user agent
should rescale pixel values. It is recommended that the reference pixel be
the visual angle of one pixel on a device with a pixel density of 96dpi and
a distance from the reader of an arm's length. For a nominal arm's length of
28 inches, the visual angle is therefore about 0.0213 degrees.
http://www.w3.org/TR/CSS21/syndata.html#length-units
Most desktop browsers make a CSS pixel a monitor pixel, however most
desktop browsers (Opera, IE7, IE8, Firefox 3) also include a zoom function
that changes the effective pixel size up or down. Note that some zoom
functions (Opera, IE8) include fit-to-width reflowing capabilities that mean
that there's no guarantee that a box width in px will remain proportional to
a font height specified in px.
Most desktop browsers (IE, Firefox, Safari) allow users to adjust the font
size up or down in steps. In IE's case, these adjustments do not affect font
sizes specified in pixels.
In addition, most desktop browsers (IE, Opera, Firefox, Safari) enforce
minimum font sizes in real pixels and allow users to change them, and allow
users to disregard publisher suggestions about font size and set enforce
their own preferences.
--
Benjamin Hawkes-Lewis
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help:
Re: [WSG] Opera Targeting?!
Chomping at the bit to dismiss IE7 a little early aren't we Georg? :) David Gunlaug Sørtun wrote: Besides: one should only target/hack dead browsers, like IE7 and older. Targeting/hacking live browsers like Opera, Firefox, Safari etc. for real, will only create maintenance-problems as new versions arrive. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
I really don't understand what you mean, when you say: It's a designer-bug. Vertical position of the navigation relies entirely on font size, which means it is all over the place in my browsers on first load. No two browsers calculate font size exactly the same before rendering, so relying on pixel-perfect font size across browser-land is not a good idea. Add in font resizing and other regular options in browsers, and it gets a lot worse - for the whole layout. The problem should not rely on font size, but rather the margin from the top of the item that margin-top is being applied to, to the bottom of the item that is directly above the item that margin-top is being applied to, correct? I mean I do know that font size across browsers does not render the same, but if using pixels for a font size, should the pixels (in relation to size) render the same? I would think they would, but maybe I am wrong. You should rethink the positioning method, and forget about deviations between browsers until you have stabilized it in one. I do not understand this either, unless you are talking about using margin as the positioning method. I have stabilized it one browser. This is why I am worried about the deviations in all the others. FWIW: there are no reliable ways to target Opera anymore. You can't even know for sure if Opera is Opera. I do understand this. But I was hoping there was a way, like using JavaScript. I can understand if there is not one though. Besides: one should only target/hack dead browsers, like IE7 and older. Targeting/hacking live browsers like Opera, Firefox, Safari etc. for real, will only create maintenance-problems as new versions arrive. This is the most confusing part. IE7 is a live browser, if it is not then how can Opera, Firefox, Safari, etc., be? Every new version is then a stable version (dead version, though dead almost sounds as though you would mean like IE3 or Netscape 3). Or, are you saying that there will never be updates for IE7, though upon saying that, it would be incorrectly considered stable? -- Brett P. On Tue, Feb 3, 2009 at 2:41 PM, Gunlaug Sørtun gunla...@c2i.net wrote: David Dixon wrote: Chomping at the bit to dismiss IE7 a little early aren't we Georg? :) :-) Look at IE7 from a designer/developer's point of view... IE7 is dead - meaning: stable, so if it acts up and there isn't a suitable solution that all browsers can see, there's no harm whatsoever in hacking its dead body to pieces. IE7 can't come back to haunt us, no matter how many users it has. No other browser/version will ever see what we feed IE7 only - with the right targeting method, apart from maybe IE8 (and probably its successors if it gets any) when it mimics IE7 in (backwards) compatibility view. Gunlaug Sørtun wrote: Besides: one should only target/hack dead browsers, like IE7 and older. Targeting/hacking live browsers like Opera, Firefox, Safari etc. for real, will only create maintenance-problems as new versions arrive. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
David Dixon wrote: Chomping at the bit to dismiss IE7 a little early aren't we Georg? :) :-) Look at IE7 from a designer/developer's point of view... IE7 is dead - meaning: stable, so if it acts up and there isn't a suitable solution that all browsers can see, there's no harm whatsoever in hacking its dead body to pieces. IE7 can't come back to haunt us, no matter how many users it has. No other browser/version will ever see what we feed IE7 only - with the right targeting method, apart from maybe IE8 (and probably its successors if it gets any) when it mimics IE7 in (backwards) compatibility view. Gunlaug Sørtun wrote: Besides: one should only target/hack dead browsers, like IE7 and older. Targeting/hacking live browsers like Opera, Firefox, Safari etc. for real, will only create maintenance-problems as new versions arrive. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
On 2009/02/03 15:18 (GMT-0500) Brett Patterson composed: There are patches for Internet Explorer, though Microsoft calls them several different things, it could be a Security Update for Internet Explorer, a Cumulative Security Update for Internet Explorer, or even a Security Update for Windows (maybe worded differently on the last one). They just update IE differently then all the other browsers update their own. Microsoft does not really use v3.0.8 like Firefox would, 9.26 like Opera would, etc. Fixes to stable released versions of web browsers are virtually always fixes to security flaws. Fixes to rendering engines are nearly always reserved for development versions and applied prior to new/significant a new version release intended to be a replacement for a prior stable release. -- Do not let any unwholesome talk come out of your mouths, but only what is helpful for building others up. Ephesians 4:29 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
