[WSG] Safari DOM inspector
Hi all, Very occasionally I get bizarre inconsistencies with Safari display compared to other browsers. Back in the day I'd sit back, take a look at the code, go through archived bug reports and allocate the problem via deduction. Sadly these days I have my developer toolbars and DOM inspectors, and I'm too lazy and out of practice to do that. Today I found this fantastic utility [http://webkit.org/]. WebKit is a terribly vague name, but I suppose 'the WebKit nightly build' about sums it up. I fired it up and went to look at my bug in question and got so distracted by its fantastic inspection frames (metrics! woo!) that it took me a while to notice that the bug in question had disappeared. Can anybody suggest a useful alternative? Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Safari DOM inspector
Barney, I am confused by this - did you download WebKit, or some other utility? If it was just WebKit, then at least you know that the bug will be gone from a future version of Safari ! Mike -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Barney Carroll Sent: Thursday, November 16, 2006 10:49 AM To: Barney Carroll Subject: [WSG] Safari DOM inspector Today I found this fantastic utility [http://webkit.org/]. Can anybody suggest a useful alternative? *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Safari DOM inspector
On Nov 16, 2006, at 7:48 PM, Barney Carroll wrote: Today I found this fantastic utility [http://webkit.org/]. WebKit is a terribly vague name, but I suppose 'the WebKit nightly build' about sums it up. I fired it up and went to look at my bug in question and got so distracted by its fantastic inspection frames (metrics! woo!) that it took me a while to notice that the bug in question had disappeared. WebKit is the rendering engine behind Safari. What you have downloaded is a nightly build of what will be Safari 3.0 in Spring 2007. And yes, Safari 3.0 will have a WebInspector, just as OmniWeb 5.5 already has one - not a surpirse, as it uses the same WebKit rendering engine. And it is very possible that a bug you see in Safari 1.3/2.0 doesn't exist anymore in those nightly WebKit builds. One would hope that some bugs get fixed, after all... Philippe --- Philippe Wittenbergh http://emps.l-c-n.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Safari DOM inspector
[EMAIL PROTECTED] wrote: Barney, I am confused by this - did you download WebKit, or some other utility? If it was just WebKit, then at least you know that the bug will be gone from a future version of Safari ! Mike Yes, I did... And that is kind of a guilty, comforting thought; hopefully by the time the project goes live, everybody using Safari will have updated to a version that doesn't suffer the same problem! However I'm not sure that's how it works... All Apple-made Mac OS html readers use WebKit, and WebKit is open source - are the two instances of WebKit in that sentence referring to exactly the same thing? For one, webkit.org doesn't mention the word 'Apple', nor does it have much in the way of documentation re:release dates. So I'm a little confused. If this is the bona fide, official, endorsed shape of things to come, we're all very lucky people! In the meantime, Safari appears to be completely vanilla, in that it has no extensions, and is utterly opaque. Are these assumptions correct? Or is there some way I can find out what the current release of Safari is reading, other than staring at the source code and the final render? I do know that generally it treats the styling of forms with disdain (plus I'm using javascript on them for display purposes, oo-er). Is there any other significant 'bug' I should know about? Can't divulge urls sadly, but it's a question (as far as I can see) of measurements mis-calculations inside a form element. I know that's vague as anything... ??? Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Safari DOM inspector
Philippe Wittenbergh wrote: WebKit is the rendering engine behind Safari. What you have downloaded is a nightly build of what will be Safari 3.0 in Spring 2007. And yes, Safari 3.0 will have a WebInspector, just as OmniWeb 5.5 already has one - not a surpirse, as it uses the same WebKit rendering engine. And it is very possible that a bug you see in Safari 1.3/2.0 doesn't exist anymore in those nightly WebKit builds. One would hope that some bugs get fixed, after all... Indeed! I'll reserve my bitterness over inconvenient progressions for IE7. Hehehe. Thanks for the info - I downloaded the OmniWeb 5.5.1 trial (gorgeous tabs system, incidentally); and it renders the page in question, with bug, exactly like the current release of Safari. Excellent (for my purposes). However I see no sign of a WebInspector... It's not immediately apparent from OmniWeb's interface, Omni don't seem to think it's worth mentioning in their list of fancy features, and a site search for 'inspector' only finds instances of it in their other products (all irrelevant in this case). Is it a third party plugin? Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Safari DOM inspector
Philippe Wittenbergh wrote: Close Omniweb and type the following (exactly !) in a new terminal window: defaults write com.omnigroup.OmniWeb5 WebKitDeveloperExtras -bool true (one line, watch out for wrapping). And you'll see that it is still missing some panes. Fantastic! This is exactly what I need. Thank you very much. (to keep it ore on topic, aka debugging tools) One feature is sorely missing in WebKits inspector: the ability to live edit properties and values for an element. I use that the whole time with Gecko's DomInspector. IE's toolbar also has this option. It is a very useful (if a little unreliable) feature of Gecko's... I still prefer the dev toolbar live css modifier for the purposes of trial. IE's toolbar infuriates me a bit, but it does at least give some indication of what IE thinks is going on. As far as I can work out, the only dynamic ability is the creation or removal of id or class attributes, which I really can't conceive of as being useful in any but the most specific situations. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Safari DOM inspector
Barney, Have a look at the second link on the left hand side of that site - Surfin' Safari Blog - lots of references to Apple in there. Not 100% sure of the exact relationship between WebKit and Safari releases, but I'm sure you can find out if you look (I could have sworn it was in the 'About Safari' screen, but I don't see it know on my machine! Mike *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Safari DOM inspector
On 11/16/06 5:48 AM, Barney Carroll [EMAIL PROTECTED] wrote: Today I found this fantastic utility [http://webkit.org/]. WebKit is a terribly vague name, but I suppose 'the WebKit nightly build' about sums it up. Although I couldn't tell from your message, you might already have figured out that WebKit _is_ Safari - or rather what's behind Safari. And I am guessing you are talking about the Inspect Element feature in recent WebKit builds. Right-click on any page element and choose Inspect Element. I agree. It's very cool. I have also noticed bugs not being present in Webkit, which is good. The next version of Safari is gonna be great. As far as bug fixing, the best I have come up with is looking for a different way of coding the area in question to get it right. Move padding from this element to that, etc. HTH -- Tom Livingston | Senior Multimedia Artist | Media Logic | ph: 518.456.3015x231 | fx: 518.456.4279 | mlinc.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
WebKit: '-khtml' ?!! (Was: Re: [WSG] Safari DOM inspector)
OmniWeb's inspection kit isn't fully functional yet - the search tool (great idea) doesn't work yet, and the same goes for the metrics and properties tabs. However the style viewer is incredibly useful. It specifies that it is a 'computed style' viewer - an interesting distinction. Gecko happens to be so compliant that such a thing is incredibly rarely useful, and as such its own inspector is great in that it only displays 'read' code. IE has a bastardisation of the two: its inspector reflects the fact that in many cases it digests code and then converts it into 'behaviours', and you often end up with expressions similar in syntax to the notorious hasLayout property. As far as I can see though, WebKit displays what appears to be _every possible relevant property_ along with their values... Very useful for the purposes of allocating bugs. I notice what appears to be WebKit-specific code... Things like -khtml-text-decorations-in-effect ...Which I have seen in effect - proprietary and usually only used in Apple sites since it is naturally not w3 css. There are also more intriguing rules like -khtml-line-break Oddly enough, a right click allows WebKit to search for the clicked term as a Google string - useful enough as Google finds _nothing_. I would love to play around with these, but apparently they are completely undocumented in the public arena (aka the internet)! Regarding my original bug which prompted all this, it reads (by the inspector) as if it shouldn't be (unless, of course, the -khtml comments mean something significant). I may, heaven forbid, resort to hacking Safari to give it uglier specification for the element in question. I seem to remember there is a weird selection method involving seemingly banal child-of-parent-of-child-of etc. specification. Regards, Barney @Mike re:Apple: You're right. It is still a little obscure, isn't it? *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Sliding Door Tabs
Tom Livingston wrote: Hello list, I am about to embark on my first Sliding Doors tab adventure. Just wondering if Doug Bowman¹s ALA articles from 2003 are the best resource for this. Are there newer updated resources? I'd say Doug's article is absolutely fine for what it does. It's entirely possible to get completely bogged down with the notion of sliding corners for more complex specs, but for anchor tabs, I know no better. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] FF understands body:last-child
Anybody know about this?
body:last-child ... {}
I saw this a while back and chuckled, but today I found cause to use it.
It's supposedly a hack for WebKit browsers (I don't understand how there
could be any ambiguity over what the last child of the body could be,
but there you go). I've seen examples of such rules only being picked up
by my Safari, with everything else I've got ignoring it - however when I
applied it myself it was picked up by Safari and my Firefox.
Any idea why this is?
Regards,
Barney
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Safari DOM inspector
On 16 Nov 2006, at 11:41:40, Barney Carroll wrote: I do know that generally it [Safari] treats the styling of forms with disdain (plus I'm using javascript on them for display purposes, oo-er). Is there any other significant 'bug' I should know about? Long, long ago - well, within the last few years - there was a general belief that styling of form controls was a Bad Thing from a usability perspective, as it meant the user got an experience with web form controls that wasn't consistent with the appearance of such controls within their operating system. A number of cutting-edge and utterly horrible examples of over-the-top styling of form controls by too-enthusiastic designers helped to reinforce the idea that it shouldn't be done. In particular, Safari has always enforced the idea that a checkbox (for example) is going to look-and-feel exactly the same in a web page as it does in any other part of the OS user interface. Now that we've all grown up a bit, and (much more importantly) we also know that (with appropriate usability considerations by designers) users don't have a problem with pretty form controls, it is generally accepted that it is an OK thing when done in moderation. Even Apple/the Safari team have accepted this, and the next version of Safari will be much more permissive of widget styling, by providing a mechanism to relax the enforcing of OS conventions through the W3C standard method of providing vendor-specific CSS extensions. Dave Hyatt, who left Mozilla to become lead developer (or something - don't know his actual title) on Safari, has blogged about it: http://webkit.org/blog/?p=17 Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] FF understands body:last-child
Barney Carroll wrote:
Anybody know about this?
body:last-child ... {}
I saw this a while back and chuckled, but today I found cause to use
it. It's supposedly a hack for WebKit browsers (I don't understand how
there could be any ambiguity over what the last child of the body
could be, but there you go). I've seen examples of such rules only
being picked up by my Safari, with everything else I've got ignoring
it - however when I applied it myself it was picked up by Safari and
my Firefox.
Any idea why this is?
Regards,
Barney
It's CSS3, there're loads of cool pseudo classes like this coming along
in the future but Firefox supports a few already. I can't remember which
exactly. Have a look at this article, interesting stuff:
http://www.456bereastreet.com/archive/200601/css_3_selectors_explained/
Rob O
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: WebKit: '-khtml' ?!! (Was: Re: [WSG] Safari DOM inspector)
On 16 Nov 2006, at 14:37:50, Barney Carroll wrote: -khtml-text-decorations-in-effect ...Which I have seen in effect - proprietary and usually only used in Apple sites since it is naturally not w3 css. It depends what you mean by W3C CSS. The CSS spec allows for vendor- specific extension properties of the form shown; so it is in fact fully compliant with W3C CSS: http://www.w3.org/TR/CSS21/syndata.html#q4 although it is, by definition, not one of the CSS properties specified by the W3C (which I assume was what you meant). I'm not sure what the validator does with this kind of by-the-spec extension property but, if it flags it as an error rather than a warning, it's (IMHO) a flaw in the validator: CSS implementations may not recognize such properties and may ignore them according to the rules for handling parsing errors Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Sliding Door Tabs
On 11/16/06 10:30 AM, Tom Livingston [EMAIL PROTECTED] wrote: I am about to embark on my first Sliding Doors tab adventure. And already IE6 pisses me off... http://66.155.251.18/mlinc.com/06/ The left image on the Home tab is transparent in the upper-left corner as shown. IE 6 doesn't like how I am using neg-margin to keep the right hand image from peeking through the corner of the left hand image. Anyone see how to make IE 6 play nice? View in FF for comparison. Thanks -- Tom Livingston | Senior Multimedia Artist | Media Logic | ph: 518.456.3015x231 | fx: 518.456.4279 | mlinc.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
RE: [WSG] Safari DOM inspector
On the other hand, one of the major plusses for Camino is that it is more tightly integrated with the OS than FireFox is, so it also uses the OSX form elements au-naturale. (And pays attention to the proxy settings in the OS, which is rather handy on my laptop.) I think what you really meant to say is that it treats the abuse of its own chrome with disdain... many of us still believe that styling of Chrome is a Bad Thing(tm) Mike -Original Message- From: listdad@webstandardsgroup.org [mailto:[EMAIL PROTECTED] On Behalf Of Nick Fitzsimons Sent: Thursday, November 16, 2006 4:33 PM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Safari DOM inspector On 16 Nov 2006, at 11:41:40, Barney Carroll wrote: I do know that generally it [Safari] treats the styling of forms with disdain (plus I'm using javascript on them for display purposes, oo-er). Is there any other significant 'bug' I should know about? Long, long ago - well, within the last few years - there was a general belief that styling of form controls was a Bad Thing from a usability perspective, as it meant the user got an experience with web form controls that wasn't consistent with the appearance of such controls within their operating system. A number of cutting-edge and utterly horrible examples of over-the-top styling of form controls by too-enthusiastic designers helped to reinforce the idea that it shouldn't be done. In particular, Safari has always enforced the idea that a checkbox (for example) is going to look-and-feel exactly the same in a web page as it does in any other part of the OS user interface. Now that we've all grown up a bit, and (much more importantly) we also know that (with appropriate usability considerations by designers) users don't have a problem with pretty form controls, it is generally accepted that it is an OK thing when done in moderation. Even Apple/the Safari team have accepted this, and the next version of Safari will be much more permissive of widget styling, by providing a mechanism to relax the enforcing of OS conventions through the W3C standard method of providing vendor-specific CSS extensions. Dave Hyatt, who left Mozilla to become lead developer (or something - don't know his actual title) on Safari, has blogged about it: http://webkit.org/blog/?p=17 Regards, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Sliding Door Tabs
Try using negative values on margin-right instead of margin-left On 11/16/06, Tom Livingston [EMAIL PROTECTED] wrote: On 11/16/06 10:30 AM, Tom Livingston [EMAIL PROTECTED] wrote: I am about to embark on my first Sliding Doors tab adventure. And already IE6 pisses me off... http://66.155.251.18/mlinc.com/06/ The left image on the Home tab is transparent in the upper-left corner as shown. IE 6 doesn't like how I am using neg-margin to keep the right hand image from peeking through the corner of the left hand image. Anyone see how to make IE 6 play nice? View in FF for comparison. Thanks -- Tom Livingston | Senior Multimedia Artist | Media Logic | ph: 518.456.3015x231 | fx: 518.456.4279 | mlinc.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** -- Cláudio Dias http://www.mundonu.com http://www.paperinside.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Sliding Door Tabs
Tom Livingston wrote: Hello list, I am about to embark on my first Sliding Doors tab adventure. Just wondering if Doug Bowman¹s ALA articles from 2003 are the best resource for this. Are there newer updated resources? From the same era: http://www.tjkdesign.com/articles/scalable.asp Only if you care for IE5 Mac and NN 6... --- Regards, Thierry | www.TJKDesign.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Safari DOM inspector
On 16 Nov 2006, at 17:16:33, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Bad Thing(tm) Mike And there I was thinking the bt in bt.com stood for British Telecom (tm) ;-) -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Sliding Door Tabs
On 11/16/06 12:25 PM, Claudio Dias [EMAIL PROTECTED] wrote: Try using negative values on margin-right instead of margin-left I may be implementing it wrong, but this doesn¹t seem to do what I am after. Thanks though. -- Tom Livingston | Senior Multimedia Artist | Media Logic | ph: 518.456.3015x231 | fx: 518.456.4279 | mlinc.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Safari DOM inspector
[EMAIL PROTECTED] wrote: On the other hand, one of the major plusses for Camino is that it is more tightly integrated with the OS than FireFox is, so it also uses the OSX form elements au-naturale. (And pays attention to the proxy settings in the OS, which is rather handy on my laptop.) I think what you really meant to say is that it treats the abuse of its own chrome with disdain... many of us still believe that styling of Chrome is a Bad Thing(tm) I think form elements suffered a similar kind of fate as tables (ie branded css-incompatible). The monstrous symptoms of this that I bump into daily are a) form elements styled by html in otherwise valid sites b) forms designed for Safari users that fall apart visually when viewed otherwise c) unbearable amounts of chrome and glowing blue when navigating with Safari. It's not an inevitability, but I'm sure there's a stigma out there in the minds of designers who think that forms mean either give up all hope of a controlled design or make improper use of html. The project I am working on is highly stylised with plenty of circles and rounded edges everywhere - during the design process my co-designer sketched up visions for various templates, and got screen caps off her mac to simulate form elements - this actually chimed very well with our design, and would have been very close to how she would have seen the site on her setup with the forms left vanilla. On PC however, the visuals were horrible. Eventually, Peter Ned saved my life by developing a script that replaced buttons with anchors that retained all the key functionality: http://www.xs4all.nl/~peterned/blog/accessibleform.html For some people this presents a semantic obstacle... But I wouldn't have my site without this. Regards, Barney *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] Gap in FF and Safari
Hello again all, On this page: http://66.155.251.18/mlinc.com/06/index.cfm FF (Mac anyway) and Safari are showing a gap under the header. IE (6 and 7) are looking good. Anyone see what I¹m doing wrong? Any comments on anything in general? Thanks! -- Tom Livingston | Senior Multimedia Artist | Media Logic | ph: 518.456.3015x231 | fx: 518.456.4279 | mlinc.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Gap in FF and Safari
On 16 Nov 2006, at 21:04:40, Tom Livingston wrote: http://66.155.251.18/mlinc.com/06/index.cfm In Firefox's DOM Inspector, I did the following: Remove the br class=clear / from after both navbar and header; Set float: left; on both header and navbar, to make them contain their floated elements. Fixed it, at least on that browser; not sure what IE will do, but it'll probably be something wrong :-) HTH, Nick. -- Nick Fitzsimons http://www.nickfitz.co.uk/ *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Gap in FF and Safari
Tom Livingston wrote: On this page: http://66.155.251.18/mlinc.com/06/index.cfm FF (Mac anyway) and Safari are showing a gap under the header. The break tag may be to blame for that. Try putting a height on .clear in addition to line-height. lr *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Gap in FF and Safari
On 11/16/06 4:32 PM, Nick Fitzsimons [EMAIL PROTECTED] wrote: Remove the br class=clear / from after both navbar and header; Set float: left; on both header and navbar, to make them contain their floated elements. Bingo. Thanks! -- Tom Livingston | Senior Multimedia Artist | Media Logic | ph: 518.456.3015x231 | fx: 518.456.4279 | mlinc.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
[WSG] A little Friday fun
HI people! The week is drawing to an end...many of you have had a week of nightmare code and semantic nightmares...but never fear - have a listen to this song and know that you are not alone... http://www.esanity.co.uk/podcasts/HandsToBoag.mp3 D ps - sorry if this has already been posted. -- darren wood [EMAIL PROTECTED] http://www.dontcom.com *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] A little Friday fun
Makes me wanna throw my laptop on the fire and get down.. Too some seriously accessible content. A - Andy Woznica Actofdesign http://www.actofdesign.com On 11/16/06 7:08 PM, Darren Wood [EMAIL PROTECTED] wrote: HI people! The week is drawing to an end...many of you have had a week of nightmare code and semantic nightmares...but never fear - have a listen to this song and know that you are not alone... http://www.esanity.co.uk/podcasts/HandsToBoag.mp3 D ps - sorry if this has already been posted. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] A little Friday fun
Oh, thank you! Hilarious. Lets play it at next years web directions and all hold hands. - Original Message - From: Andy Woznica [EMAIL PROTECTED] To: wsg@webstandardsgroup.org Sent: Friday, November 17, 2006 12:13 PM Subject: Re: [WSG] A little Friday fun Makes me wanna throw my laptop on the fire and get down.. Too some seriously accessible content. A - Andy Woznica Actofdesign http://www.actofdesign.com On 11/16/06 7:08 PM, Darren Wood [EMAIL PROTECTED] wrote: HI people! The week is drawing to an end...many of you have had a week of nightmare code and semantic nightmares...but never fear - have a listen to this song and know that you are not alone... http://www.esanity.co.uk/podcasts/HandsToBoag.mp3 D ps - sorry if this has already been posted. *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
