[WSG] Starting with HTML and CSS
Gday WSGers! I am lucky enough to be a tutor for a web course at the local uni, and I love to point students towards Starting with HTML + CSS http://www.w3.org/Style/Examples/011/firstcss However, it uses absolute positioning. I would like to use a *huge* favour. Anyone want to write a simple blog post on how to take the HTML file already present in the link and convert it a 2-column design with a footer (most likely using floats OR even display:table!!)) That'd be excellent :) Sort of a Starting with HTML + CSS the sequel :) Many many thanks Kat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Starting with HTML and CSS
That tutorial seems pretty detailed. Why not have them follow that tutorial, then introduce them to the float property and point them to a tutorial like: http://www.456bereastreet.com/lab/developing_with_web_standards/csslayout/2-col/ - James On Tue, Feb 3, 2009 at 7:32 PM, Katrina k...@t-tec.com.au wrote: Gday WSGers! I am lucky enough to be a tutor for a web course at the local uni, and I love to point students towards Starting with HTML + CSS http://www.w3.org/Style/Examples/011/firstcss However, it uses absolute positioning. I would like to use a *huge* favour. Anyone want to write a simple blog post on how to take the HTML file already present in the link and convert it a 2-column design with a footer (most likely using floats OR even display:table!!)) That'd be excellent :) Sort of a Starting with HTML + CSS the sequel :) Many many thanks Kat *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** -- James Ducker Web Developer http://www.studioj.net.au *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
[WSG] Opera Targeting?!
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 ***
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] label:hover - more harm than good?!
Thanks Rob, and David. If the label and the checkbox or select have matching 'for' and 'id' attributes they should be getting focus when clicked. As far as the value label:hover goes I tend not to make labels change colour on hover as they may be misinterpreted as links. If you want people to know that they can click on the label text use 'cursor: pointer;'. It communicates that something can be clicked, and if it doesn't change colour it should communicate that it won't take you away from the current page. Good point! I didn't give it a good thought about hover suggets that it's a link. tee *** 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 ***
