Re: [WSG] Problem with Navigation in IE 6

[Gunlaug Sørtun]

Carolyn Diaz wrote:

Thanks so much! I should have seen that right off. Isn't that also known as
the Holly hack or some such thing?


That's right...

--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Problem with Navigation in IE 6

[Gunlaug Sørtun]

Carolyn Diaz wrote:

http://netprojx.com/STU/facts.htm.

The problem is the left navigation in IE 6. The sub elements or 2nd 
level of

the navigation loses its background, sometimes the color, sometimes the
image...in other words, extremely buggy behavior!


Add...
li {height: 1%;}
...or another suitable 'hasLayout'[1] trigger, to those list-items.

That's one IE/win bug that is fixed in IE7.

regards
Georg

[1]http://www.satzansatz.de/cssd/onhavinglayout.html
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] layout - choices?

[Gunlaug Sørtun]

Designer wrote:
It seems to me that pragmatism can sometimes outbenefit the religion 
of standards - and I'd really like some real world feedback on when 
such a table approach causes real problems.   (Yes, I know it's not 
truly semantic, and I agree that it's a problem because of that).


If web standards is a religion, then I'm out of here :-)

As long as you know - and have gone through - all pros and cons, then it
comes down to "taking the heat" for using that 'HTML table'. No browsers
will ever cause real problems because of it.

The only problem I can see is that one may start feeling so "safe" with
that old 'HTML table' solution that one stop exploring the various "pure
CSS" solutions (with workarounds and all) for a while. Browsers and
standards are improving - albeit slowly, so one may have a bit of
"catching up" to do one day in the future.
Less experienced web designers may also be lead to think that there are
fewer options at hand than there really are, and that won't help on
progress.

I'm pragmatic, and pretty agnostic, when it comes to standards and
"standard-compliant" browsers. I don't think I will fall back to using
'HTML tables' as layout tools though, as I think it is safer to hack
IE/win and other old browsers to pieces in CSS and keep the source-code
relatively free from such hacks, while I'm waiting for standards to work
as intended across the board.

Now, if only I knew the _intentions_ behind the various parts of those
standards, so I knew what to expect ;-)

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] (Georg) equal heights within equal heigh wraper

[Gunlaug Sørtun]

Tee G. Peng wrote:

http://project.lotusseedsdesign.com/tee_test/4col.html

If you click 'open' in the outer left column, it get expanded and you
 can clearly see the inner column couldn't adjust its height


I only had a quick look on the source-code, but the layout seems to
behave as it should - given the relationship between those containers.
You have nested containers - which will behave the same as equivalently
nested HTML tables.

- #left is an independent container, so it will, and should, only affect
height of its parent - #wrap.
- #right is on its own, and will not be affected by, or have an effect
on, #left.
- #right - and all containers inside #right - will of course affect
height of #wrap, since both #left and #right are children of #wrap.
This makes it appear as if #right is affecting the height of #left, but
not the other way around. It's just an illusion though.

Now, if you want #left to affect the height of #right, #left must be a
child of #right.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] position:fixed weirdness IE7 IE5 mac

[Gunlaug Sørtun]

Bob Schwartz wrote:

http://www.fotografics.it/test/


The orange div on the left is where a menu will go (without the 
orange background) and has position:fixed. In IE7 it shifts to the 
right invading the content div instead of resting just outside the 
light yellow content area. (Use any other browser to see it 
correctly).


'Position: fixed' is positioning elements relative to _view-port_ - not
to any other element, so I'm not sure if IE/Mac is doing much worse than
other browsers. You have not given the 'fixed' element any positions, so
browsers drop it "where they think it should be" - which just happens to
also be where you like it to be in most browsers.

- What IE/Mac _does_ wrong is to hide the 'fixed' element when it ends
up outside the edges of #wrapper. This is probably what happens if
IE/Mac does the logical thing and resolves "no positions" to mean
'top:0; left:0;'. Can't see where it is as long as it's 'fixed' from
within the #wrapper.
- Most browsers seem to resolve "no positions" to mean 'drop it right
here'. No problem.
- IE/win usually resolves "no positions" to mean 'vertically: drop it
right here; horizontally: center it'. That's somewhere on top of the
content area in your case.
In short: no "standard" for 'position: fixed' with "no positions".

Again: 'position: fixed' is for positioning relative to the
browser-window, over which you have no real control. See...

...for more on the subject.

If you want an element to adjust horizontally to the #wrapper while
staying 'fixed' vertically - reliable - in all browsers, then you'll
probably need some element-nesting and width-control. It can be done,
but not easily.
Example...

...but I'm not sure if it is worth the hassle.

There are a few alternative solutions based on 'position: absolute' and
overflow-control around. Also some that use Javascript.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Accessibility - display: none v.s. left: -9999px

[Gunlaug Sørtun]

Nick Fitzsimons wrote:
Do screen readers reveal "cover-ups" ? 
Example: 




I don't know.



[...]


So the best people to ask would be the developers from the IE Team 
and at the screen reader vendors :-)


Ok :-)

For the record: I have used the demonstrated "cover up" method for a few
years - just for fun, and a friend (across the web) who is relying on
screen readers says what's covered up comes through just fine.
The problem is: neither she nor I have any idea which screen reader it
is, other than that it is on top of IE/win.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Accessibility - display: none v.s. left: -9999px

[Gunlaug Sørtun]

Nick Fitzsimons wrote:
So any attempt to include markup "just for screen readers" is doomed 
to failure - screen readers don't use markup.


Do screen readers reveal "cover-ups" ?
Example: 

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] web check

[Gunlaug Sørtun]

John 'Max' Maxwell wrote:


I will get on to the 'more' links and add the names.


The names are there already. Just link them to the relevant pages.

"Need some font-resize testing and improvements. Text is overflowing 
containers in the good browsers under certain conditions, and IE6' 
'auto-expansion' bug is not very kind to that layout either."


I spotted this and need to take the height attribute off some divs or
 maybe bring in some kind of auto scroll.


Look at how IE6 does it - before things starts to break too badly. IE6'
'auto-expansion' bug is useful at times, and it can be "replicated" in
less buggy browsers.


"A generous 'min-width' is needed for supporting browsers."

What does this mean? Making the page wider than 850 pixels if the 
space is there?? Why would this help?


I wrote 'min-width', *not* 'max-width'. At the moment that design can be
squeezed down until everything gets out of shape and overlaps. I don't
think many of those pages will work on narrower windows that around 700
pixels - even after some improvements for font-resizing, so I think you
should add a 'min-width: 700px' to save it.

"I don't think you need more than one IE-expression for 
'min/max-width' in that layout - on the outer wrapper, and it 
definitely needs some tuning for trigger/fix-points and smoothness of

 action."

Can you expand on this as I am interested in knowing more about it.


Read about that 'pixel-based min/max-width expression' here...

...and check out how smooth it works in IE6 on that very page.
Those values must be tuned to each layout. There should not be much
difference in how IE6 handles that layout when window is resized, from
how other browsers handle it.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] web check

[Gunlaug Sørtun]

John 'Max' Maxwell wrote:

Just gone live with this and have done all my valid checks etc but if
 anyone has a second I would really appreciate any feedback on 
accessibility and usability:






The 'Maker Search' map isn't accessible without a mouse and some
eyesight - not to mention 'no-image' browsers/browsing conditions. Maybe
an idea to turn 'North', 'South', 'East' and 'West' (Devon) into links.

Those 'more' links are not all that informative out of context -
link-tabbing. I'd put the links on the names (too) and avoid
name-repetitions.

Need some font-resize testing and improvements. Text is overflowing
containers in the good browsers under certain conditions, and IE6'
'auto-expansion' bug is not very kind to that layout either.

A generous 'min-width' is needed for supporting browsers.

I don't think you need more than one IE-expression for 'min/max-width'
in that layout - on the outer wrapper, and it definitely needs some
tuning for trigger/fix-points and smoothness of action.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] blockquote in xhtml strict

[Gunlaug Sørtun]

Tee G. Peng wrote:

"I came because this is one of the best.."
- john doe

  




What am I missing?


  " The BLOCKQUOTE element defines a block quotation. Unlike inline
quotations, block quotations may contain block-level elements such as P
and TABLE, but BLOCKQUOTE may not be contained within a paragraph or
inline element. "

So, the following will do...


"I came because this is one of the best.."
- john doe


Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: Conditional Comments Bad? - was: Re: [WSG] CSS calling methods survey

[Gunlaug Sørtun]

Tony Crockford wrote:

and having caught up with my reading, the use of CC's seems to be 
frowned upon.


I can't see why - as long as CC's are used to serve a minimal number of
fixes to _old_ IE/win versions. Old browsers are "fixed in time".

It is when one starts a design-process by preparing CC's for "fixing"
IE7 (and maybe even later versions) that I feel it is time to stop and
think. It is bad enough that we get new buggers to deal with, but we
should not promote and preserve such a buggy trend, IMO.

since I mostly use the CC's for max width and max height, what's the 
simplest alternative, that would:


a) put "hacks" in separate stylesheets for IE6, IE5 and IE5 on Mac.


/*\*//*/
@import url("macie.css");
/**/

...works for IE5 on Mac, and...


b) the best _valid_ hack to solve max-width and max-height issues.


...the @import hack...

...works for IE/win, and is perfectly valid. It is IE/win that is broken.

Whether it is the "best", or even a "good" hack, or not, is something I
can't answer. I dislike hacks, but I'll continue to use them as long as
I find them necessary for "fixing" old and weak browsers.
The fact that IE7 also "get" the @import hack is an added bonus. Looks
like IE7 needs a bit of help anyway.


and why?


Basically, I want to keep my source-code as free from browser-specific
solutions as I possibly can. That means I also like to avoid having CC's
in there - whenever I can. If I can solve a problem on stylesheet level,
then I'll go for that - even if it's ugly.

could I have an import rule within the CSS that would be conditional 
for the different IE's - do I need to be that specific?


Once you have an IE/win specific stylesheet that the validator can't
see, you can use as many valid or non-valid @imports and/or other hacks
as you need to separate versions.
Some variants here...

...and you don't have to bother about which other browsers a hack may
target, since they are prevented from seeing the first IE/win specific
stylesheet and subsequently can't see any hacks within it.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] CSS calling methods survey

[Gunlaug Sørtun]

Kat wrote:
I'm beginning to think modular css using @imports are actually quite 
smart, not just for re-use reasons but also because if you do need to
support really old and dodgy browsers (sometimes it happens to the 
best of us) you can create stylesheets for those, and then over-rule 
them in the statements contained in the css that you @import.


Exactly.
OTOH: too many @imported stylesheets may slow things down slightly on
first load on slow connections.

Digressing slightly: This is probably something everyone already 
knew, but I just discovered it this week and it's my cool thing of 
the week:


@import url("style.css") print;


Have you tried that in IE/win? I don't think it will be very cooperative
once you add a media attribute.
I use a version of that - without quotes - to provide IE/win with
separate stylesheets. Not a very nice hack, but it's a working
alternative to 'conditional comments'...


With bits of your modular css, you can import those you have already 
written, for specific media (eg. printing) :)


I do that. I use @media for media-separation though - partly because of
the IE/win bug. @media is also useful for shutting out really old
browsers from (parts of) a stylesheet.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] CSS calling methods survey

[Gunlaug Sørtun]

Barney Carroll wrote:
? 

> 

Re: [WSG] Targeting specific images with overflow:hidden

[Gunlaug Sørtun]

Cole Kuryakin wrote:
[...] To see what's going on, please go here: 
http://www.x7m.us/_problems/index_problem.htm.


Sure would appreciate any advise on how I can get overflow:hidden to 
target just the images on this site.


You can target all images with 'max-width' in the good browsers, and add
an acceptable fix for IE6 through its own bugs.

Add the following...

img {max-width: 100%; height: auto;}

* html #gallery {overflow: hidden; width: 170px;}
* html #gallery img {position: relative; /* overflowing part visible */}
* html #content_main {overflow: hidden;}
* html #content_main img {position: relative;/* overflowing part visible */}

...and then decide whether you want the overflowing part of the images
visible in IE6, or not.
Just delete the '... img {position: relative;}' declarations and the
overflow will be completely hidden.
The layout won't break in IE6 either way.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Art and accessibility - my opinion ;)

[Gunlaug Sørtun]

Milosz A. Lodowski - New Media Designer wrote:
Christian in your opinion - those sites are inaccessible... without 
any argues I cannot agree so that's why I've asked...


I define 'accessible' as "be given access". In normal terms that means
that if one access-point is closed to particular visitors for whatever
reason, then alternatives should be provided.
I find a message like "Instale o Flash Player" to be a closed
access-point, and there's no alternative.

I also define 'accessible' as "be given (at least) a minimum amount of
information", so one can make some kind of informed choice.
Seems to be lacking also, as I wasn't even informed about which Flash
Player version to install on that particular page.
(According to Adobe I have Flash Player installed in all my browsers, so
it would be nice to know why I should install a new one.)

So, I think at least some of those designers should have designed a bit
more accessible. They do have the same tools as the rest of us.

I also think whoever designed and/or authored the "100 the best
E-motional Websites" site should have provided a slightly more
informative alternative text to those link-images, as seeing "The Best
100 of E-motionalDesign.com" repeated that many times isn't very
informative - IMO.

So, yes, I think the experience and accessibility-level can be lifted
quite a bit with some informative text. Seriously - a dozen or so
well-selected and well-placed words might make all the difference on
most of those sites - accessibility-wise. Shouldn't limit the artistic
freedom on any level, so I can't see why not.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] IE7 bug?

[Gunlaug Sørtun]

Rachel May wrote:
In IE6 all of my floated divs disappeared which I have currently 
'patched' with removing the floats until I have guidance from the 
client on how he wants to support IE6.


Keep them floating, and add 'position: relative'.

* html #content div {float: left; position: relative;}
...works fine in IE6.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Can't assign links specific styles

[Gunlaug Sørtun]

Cross-list answer... :-)

You have the class on the anchor itself - *not* the anchor inside an
element with the class.
Also I miss the :link pseudo-class.

You should write...

a.shoplogo:link, a.shoplogo:visited {
stuff
}

a.pagelink:link, a.pagelink:visited {
stuff
}

...etc.



regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Using "cursor:default;" on the whole page but links

[Gunlaug Sørtun]

Mihael Zadravec wrote:
that is rigt. I will stop doing that... But than again... Opera 
displays arrow even when cursor is positiond over the text...


Do you people think that they should change that because users maybe 
don't know if they can grab the text or not?


Might be confusing for a few minutes for an entirely new Opera user -
one that's switching from another browser.
Regular Opera users (like myself) don't become confused by that arrow,
since that's 'the norm' in Opera. We know we can select and grab what we
want.

It's mostly web designers and (would be) geeks that compare these things
across browser-land, and their/our views on "what's best" shouldn't
count all that much since they/we are not typical users.

Might be more confusing - for a little while at least, for any user with
any browser, if a site imposes a change from 'the normal' cursor(s)
across browser-land though.

So, better leave it to each browser to control its basic cursor(s), and
let those behind each browser decide if/when they want to make changes.
You can of course tell them what you think about the issue. I for one am
happy with it as it is now.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Firefox stops rendering background when changing .html to .xhtml

[Gunlaug Sørtun]

Ron Jonk wrote:

I've read it before in this list that backgound rendering on xhtml on
 the body is not always supported for xhtml strict documents.


Background rendering in itself is always supported.

On firefox when I have a background image for my body tag on a xhtml 
strict doctyped document, I still see the background rendered even if

there is no content.


If (correct)...
MIME type from server: text/html

- All browsers should handle it as a regular HTML(4.01) document -
regardless of doctype/extension.

Example: 


But when I only change the extension of the file from .html to .xhtml
 firefox stops background rendering when there is no content. IE 
still renders the background.


If (correct)...
MIME type from server: application/xhtml+xml

- Firefox should handle it as predefined XML where body is just another
container that doesn't take up any space unless you give it one. So, you
may not get any background.
- IE/win shouldn't handle the document at all since it doesn't
understand the MIME type. *If* IE/win does handle the document, then the
MIME type isn't correct (for whatever reason) or it isn't handled
correct, and the document is probably handled as a regular HTML(4.01)
document - regardless of doctype/extension.

Example: 

Browsers can tell you what they are being served.
In Firefox check 'Tools --> Page Info'.
For IE/win, read here...



regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Listamatic Centred horizontal list navbars not working

[Gunlaug Sørtun]

Hrvoje Markovic wrote:
I'm seeing this glitch in Opera 9, IE7, FF 2... On both 
http://css.maxdesign.com.au/listamatic/horizontal16.htm AND 
http://css.maxdesign.com.au/listamatic/horizontal27.htm I see a one 
character wide whitespace (bluespace because of the bg color) before 
every link, except the first one. Is there a way to fix this?


Not pixel-perfect when font-resizing is added into the mix.

On...

...you can add...
#navcontainer ul li a {margin-right: -.2em;}

...and on...

#navcontainer li a {margin-right: -.2em;}
...will pretty much do the trick.

regards
Georg
--
http://www.gunlaug.no


***
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] Listamatic Centred horizontal list navbars not working

[Gunlaug Sørtun]

Hrvoje Markovic wrote:
I'm seeing this glitch in Opera 9, IE7, FF 2... On both 
http://css.maxdesign.com.au/listamatic/horizontal16.htm AND 
http://css.maxdesign.com.au/listamatic/horizontal27.htm I see a one 
character wide whitespace (bluespace because of the bg color) before 
every link, except the first one. Is there a way to fix this?


Not pixel-perfect when font-resizing is added into the mix.

On...

...you can add...
#navcontainer ul li a {margin-right: -.2em;}

...and on...

#navcontainer li a {margin-right: -.2em;}
...will pretty much do the trick.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Danish Ministry of Taxation spend 1.38 million US dollars on just a new logo insert on web site

[Gunlaug Sørtun]

Soren Johannessen wrote:


FYI:  the  Danish Ministry of Taxation has got a new logo 
http://www.skat.dk/SKAT.aspx  First they pay 38 US dollars for

the design of the logo . Then they spend  138 US dollars in
working labour money for inserting the logo manually (SIC!) on every
single web page at the Danish Ministry of Taxation. [...]


Well, for that kind of money they should at least have been able to make
the logo stay in one piece...

...regardless of how many pages they had to copy it into :-D


http://www.bt.dk/article/20061227/NYHEDER/612270315&SearchID=73267347676209
 (sorry only in Danish)


No problem ;-)

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] menu, css, javascript question

[Gunlaug Sørtun]

Dwain Alford wrote:


1.  the menu operates as expected, except that only on the index page
is the sub- background transparent and the copy and the menu gets
all jumbled together in ie 6 and 7 and is unreadable.

http://www.studiokdd.com/sandbox/index.html


The background isn't transparent, but IE (all versions) has stacking
problems.
Try adding...
ul#nav {position: relative;}
...to stack the entire menu on top. Works fine at my end, and shouldn't
disturb other browsers.


2.  since there are those who surf the web with javascript turned
off, would best practices be to make the main link go to a separate
page to access the fly out links?  maybe i have answered my own
question, but i would like to get some feedback, since i haven't
looked closely at thierry's accordion menu yet.


You've got (plans for) a site map. Just make sure it's complete and 
always available, and no one should miss anything.


regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Tissue (valid code) vs shirt sleeves (wysiwyg editors and those who use them and also refuse to use tissues)

[Gunlaug Sørtun]

[EMAIL PROTECTED] wrote:

1. On a scale of 1-10, how important is W3C validation?


XHTML: 10+ (regardless of MIME type)
HTML: 8 (but it depends on what lowers its importance from a 10)
CSS: 10 (until IE/win needs its fixes, and weak standard-support must be
solved by non-standard workarounds)


2. How does one convince folks that it is important?


One just tell them that there _are_ standards. Apart from that one maybe
shouldn't try very hard unless they ask.

Many won't ask until they run into too many problems caused by
non-standard they can't "solve" on their own. Then maybe a 'cleaned-up'
example, one that works, will have most convincing-force.


3. Is valid code important to SE?


Probably not all that important, but I don't think it'll hurt.

4. Does it follow, that those who don't care about validation also 
don't consider accessibility?


Those who don't care, don't care - period.

Many are probably more or less ignorant about both issues, and may, or
may not, bother to do anything about their ignorance until a certain
pressure, or need, is present.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] ie-only hack

[Gunlaug Sørtun]

Geoff Pack wrote:

Gunlaug Sørtun wrote:
So, old hacks like the 'star html' hack for IE6 (and older 
versions) is now "perfectly valid" IMO, while hacks relying on bugs

 that have survived into IE7, are extremely unsafe.


'extremely unsafe'? I'd say they are safe until Microsoft releases 
another IE version. With their track record, that could be *years*.


Sounds like a reasonable time frame. I seem to remember a suggested time
frame of three years (after the first IE7 beta) before IE8 (or whatever
it's going to be called/numbered) will be released.

Given the choice between littering my html (thousands of pages) with 
conditional comments, or adding couple of hacks to a single CSS file,

I'll take the hacks, thank you very much.


I don't recommend 'conditional comments', so, you're most welcome.

There are some weak spots in your argumentation, as you seem to only
make a division between 'conditional comments' and 'other hacks'.

To me a 'conditional comment' is a "constructed hack", and I see no
reason to litter anything with it, unless there's no other option.
However, those 'conditional comments' won't target any other versions
than they are set up, so they are pretty safe in themselves.

It's when it comes to _what_ we use a particular hack for that it
becomes a bit more diverse. It is always unsafe to use one bug to fix
another - unless both bugs are brought under control in _all_ the latest
browser-versions. 'Conditional comments' can be even worse unless one
adds one for each IE-version/upgrade as they are released, as all
targeted bugs can be fixed in a way that makes "the CC-injected fix"
break the newly "fixed" browser. New browser-versions that are
patched-up versions of old ones - like IE7 - are really unpredictable in
this respect, so at least it's a good thing that the 'star html' hack
won't affect IE7 - unless one wants it to.


I am not "hooked on purity", and couldn't care less about _how many_ (if
any) hacks and/or workarounds there are in stylesheets - as long as they
are really needed in order to make things work. All I'm interested in is
to minimize the chance for such hacks to backfire in future
browser-versions.

I want hacks, _all_ hacks, to break (stop working) in future
browser-versions - preferably along with the bugs they are supposed to
fix, so I can use those very hacks to fix bugs and weaknesses in older
versions as long as those older versions are around in significant numbers.

So, I don't stop using hacks when they stop working in the latest
browser-version. Instead, that is when I really start using them.
The 'multiple-class-selectors' bug/hack is still not safe to use, IMO.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] ie-only hack

[Gunlaug Sørtun]

FWIW: I prefer not to use hacks, *unless* they are already broken in the
latest versions. There may always be exceptions, but the whole idea of
hacking is that one should *only hack the dead*, and do so with hacks
that are not affecting any new browser-versions.

So, old hacks like the 'star html' hack for IE6 (and older versions) is
now "perfectly valid" IMO, while hacks relying on bugs that have
survived into IE7, are extremely unsafe.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Last letter of a line appearing on next row (IE6...)

[Gunlaug Sørtun]

Rob O'Rourke wrote:
I had the last letter of some floated form elements appearing on the 
next line. I've managed to get rid of the letter itself with

position: relative; on the form input but there's still a 'phantom
line' in IE adding a load of 'padding' to the bottom of the label or
fieldset.



http://www.sanchothefat.com/dev/phantom-line.html


Have you tried adding...
* html option {display: none;}
...?
That addition improves things in my IE6 (on win2K).

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] IE Background Position Oops

[Gunlaug Sørtun]

Joseph R. B. Taylor wrote:

All works well in the browsers you'd expect it to, but of course IE6
has an issue.  For some reason its leaves the background image in the
hover statehmmm...and doesn't move it back to its predefined
position!

Here's the url: http://akolsonlimo.com/about.php

If anyone is aware of this, (or if I'm just screwed up somehow) and 
knows what causes it please let me know thanks!


IE6 is screwed up :-)

Add...
a:hover {background-position: 0 0;}
...and it'll probably work as intended.

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] what's causing ie7 to ignore the "valid div rules?"

[Gunlaug Sørtun]

Dwain Alford wrote:
so will ie7 behave without the width and height values now, or just 
width?


IE7 will in many cases behave a bit more like the standard compliant
browsers, when no dimensions are declared. IE7 has plenty of bugs
though, so there are enough exceptions to keep you busy.

IE7 will (at least try to) obey declared dimensions. How it goes about
doing so in every case, is not quite clear.

Declared dimensions will still act as 'hasLayout'[1] triggers in IE7,
and a number of "new" properties that are now being supported by IE7,
will also act as 'hasLayout' triggers.
The result is that there are quite a few new ways for that particular
IE/win bug to enter, and mess up, our designs.

If you need to take advantage of that 'Layout' bug - or to avoid it,
then you're well advised to read up on the latest revision of the
article[1] on the subject. IE7 is pretty well covered.

regards
Georg

[1]http://www.satzansatz.de/cssd/onhavinglayout.html
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] what's causing ie7 to ignore the "valid div rules?"

[Gunlaug Sørtun]

Dwain Alford wrote:

but it's supposed to be up to standards, yes?


Not according to those who have created it.
They have only said that IE7 is "up to _some_ of the standards" :-)

I would start by deleting 'width: 10%' on #valid, and 'width: 100%' on
.wsg, .xhtml, .css.  Those width-values only affects IE/win anyway, and
with the dimensional "fixes" in IE7 they'll probably affect that version
in the wrong way. Once they are gone the problem may be gone too.

Then I would add...
#valid {clear: right;}
...to make sure it stays in place even on really wide windows - in all
browsers.

Disclaimer: I still haven't bothered to download IE7, so I'm only
guessing about its bugs and fixes.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] ie7 does not render page properly

[Gunlaug Sørtun]

Dwain Alford wrote:

ie6, ff 2.0, opera 9.0.2 and mozilla 1.7.12 render the page properly.
 ie 7 sticks some copyright info, which is enclosed in a div with the
 "powered by" info, to the left of the validate buttons.  why?



http://www.alforddesigngroup.com/


IE7 ignores the 'star html' hack.

Changing...
* html .clearfix {height:1%;}
...to...
.clearfix {height:1%;}
...and otherwise keep it as is, should do.

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] how to retain equal height without losing layout integrity when user resizes font size

[Gunlaug Sørtun]

Tee G. Peng wrote:

http://project.lotusseedsdesign.com/SH-new/georg_method.html



My mistake, placing the overflow:hidden in "content' does work for IE
 7, but I still can't figure why the background images  are not 
showing up.


Quite simple, really: they are positioned 3px too low because of the
large padding, and remains hidden down there.

There's no way around that one. You'll have to position the
background-images relative to 'top left' - at least in IE, and just make
it look (somewhat) right.



Another minor addition for IE...

.tabs {height: 1%;}

...as a 'hasLayout' trigger to make those elements expand properly.

regards
Georg
--
http://www.gunlaug.no



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] how to retain equal height without losing layout integrity when user resizes font size

[Gunlaug Sørtun]

Tee G. Peng wrote:

http://project.lotusseedsdesign.com/SH-new/georg_method.html



My mistake, placing the overflow:hidden in "content' does work for IE
 7, but I still can't figure why the background images  are not 
showing up.


Quite simple, really: they are positioned 3px too low because of the
large padding, and remains hidden down there.

There's no way around that one. You'll have to position the
background-images relative to 'top left' - at least in IE, and just make
it look (somewhat) right.



Another minor addition for IE...

.tabs {height: 1%;}

...as a 'hasLayout' trigger to make those elements expand properly.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] how to retain equal height without losing layout integrity when user resizes font size

[Gunlaug Sørtun]

Tee G. Peng wrote:


Example: 


Yeah, Al is right. I see the endless vertical scrolling from IE7. Got  
fix for IE7 -:)


Yes, I think so, but I can't check it since I don't have IE7 installed.

IE7 is reported to react well for similar layouts if the overflow is 
simply hidden, so it shouldn't be too hard to fix that new bugger.

Place 'overflow: hidden' on '.row' I think.

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] how to retain equal height without losing layout integrity when user resizes font size

[Gunlaug Sørtun]

Tee G. Peng wrote:

Hi, I am doing a layout that requires equal height for each column
and row, however the contents inside of each column and row are
different and in some pages, in certain sections, the length of the
content will be decided by end users' data feed.


I suggest you try building it with CSS table, with the usual workaround
for IE/win.

Example: 
...which includes IE fixes.
Study Roger's article (linked in) and demos for the rest.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] IE Issues (margin/padding)

[Gunlaug Sørtun]

Rahul Gonsalves wrote:


http://rahulgonsalves.com/v2/index.html


The only small, niggling thing left is that whenever there is a 
paragraph preceded by a h2, it seems to be adjusted, only by a pixel 
or two, to the right. Any ideas as to how I could fix this? It's a 
small thing, but since the design hangs on a grid, a little 
misalignment looks pretty nasty.


I agree... :-) ...and I should have fixed it the first time around
without mentioning it. Now I have to add a longish explanation.


It's 3px offset in IE6 (and older), and that's why it's called the '3px
jog' bug.

The most stable fix is to "remove" the floating h2 at the left of the
paragraph, so IE/win doesn't add interaction between those two elements
into its buggy calculations.
No interaction = no '3px jog' bug.

"Removing" a float can be done by pulling in one or both of its backside
margins, so the float no longer takes up space in front of another element.
Method described here...



...but since other elements should still interact with the headline in
your page, a smaller and more precise negative backside margin value is
necessary. The idea is to "partly remove" the float from the flow.


A working fix is to put a suitable negative margin-bottom on the
floating headline to...

#content h2 { margin: -.33em 0 -1.1em 125px;}

...and the headline is "partly gone" and does no longer take up space in
front of the paragraph. It's still perfectly aligned and visible though.

There's no need to hack in this IE-fix, since it's perfectly valid and
all browsers will handle negative backside margins the same way - giving
you a cross-browser reliable line-up.
You may however want to add a bit more 'margin-top' on elements
following directly below such a "partly removed" float, as they will end
up 1.1em higher than before.

Hope the above makes sense.


(I wonder if this qualifies as a "rotten" fix using "standards", and if
so if it makes me a "rotten standardista" (or "something") :-P )

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] IE Issues (margin/padding)

[Gunlaug Sørtun]

Rahul Gonsalves wrote:


http://rahulgonsalves.com/v2/columns.html

The page displays as intended in Opera and Firefox 2, but in IE is a 
*mess*. I don't quite know where to start, I wonder whether anybody 
has any solutions?


1. Why is the header (Rahul Gonsalves...) so much lower in IE? Fix?


To fix it, add...
#logo p#access {float: left; width: 100%;}

Note the specificity.

2. The h2s are all out of alignment. Does this have to do with the 
faulty box-model?


No, it's the old 'margin-doubling on floats' bug in IE/win.

#content h2 { margin: -.33em 0 0 125px; float: left; width: 125px;
display: inline /* IE-fix */;}


3. Why is the image so far out to the left? Fix?


Working version...
#content img.m { clear: both; margin: 2em 0 0 125px; float: left;}
...and add a clearing below the image...
#content .caption {clear: both;}


4. How does one fix the paragraph alignment?


If I have understood you correctly, then I've already included a fix for
it under problem 2, with a negative margin-top on h2 - making it line up
with the paragraph.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] height issue

[Gunlaug Sørtun]

Taco Fleur wrote:

http://www.eureka-forklifts.com.au/about-us.cfm


All the text is within #body-text and both divs are set to 100% 
height, but in Firefox the background color does not complete go to 
the end of the text, it puzzles me... The page validates BTW.


100% height is limited to 100% of window-height - regardless of what
height that window has. Only IE/win with its auto-expansion,
'hasLayout'[1] related, bug will expand elements beyond that.

The wanted expansion can be achieved by adding...

#bd2 {display: table;)
#body-text {display; table-cell;}

...making standard compliant browsers render the elements as if they
were HTML tables - which is pretty much what IE does anyway.
What you get is elements that act as if they have 'min-height: 100%',
that will expand to make room for content.

regards
Georg

[1]http://www.satzansatz.de/cssd/onhavinglayout.html
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Forget about Opera and Mac (and Windows Vista) ??

[Gunlaug Sørtun]

Taco Fleur wrote:

Ahh I see, better undo all those fixes that weren't fixes ;-)



How about giving it a height of 100%?


If it's still Opera 9 you're trying to fix, then 'height: 100%' will
work - at least in the window-version.

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Forget about Opera and Mac (and Windows Vista) ??

[Gunlaug Sørtun]

Taco Fleur wrote:

OK, so opera isn't playing by the rules...


No browser yet released plays perfectly by the rules, so that shouldn't
come as a surprise.
You're not making use of all the rules either, or else you would have
provoked some nasty bugs in all browsers.

NOTE: I'm only testing in Opera's Window versions, and can only assume
that the same bug is present in Opera 9 on other OSes.


Can I change "padding: 0" to "padding: 0 0"?

I've gone like a madman through the site and changed all occurrences 
of padding: 0 to padding: 0 0 And I assume padding: 4px would become 
padding: 4px 4px, correct?


Wrong assumption. No need for, or use in, going mad and add a lot of
unnecessary fixes padding-fixes. Opera's weakness has nothing to do with
'padding' as such, and it will do just fine with one value.

Opera only need a few,'no-space' container-elements to start taking up
space of their own, in order to handle them correctly ... *not* all of
them.

In that page (www.pacificfox.com.au) it is only #container that Opera
"seems to" position incorrectly. I say "seems to" because it is
impossible to see exactly where that #container is since it doesn't take
up space and can't even be given a visible background to see where it
is. Only the elements inside #container give visible indications of
what's going on. Once the #container becomes visible, then the bug is gone.

That #container is collapsing to zero height originally, because _all_
elements inside it are positioned absolutely. That much reliance on
absolute positioning creates a rare combination, which is why I haven't
observed this bug in Opera 9 before. This bug doesn't exist in earlier
versions as far back as I can test.


Now, the suggested correction...
#container {padding: 1px 0;}
...makes #container 2px high all on its own. That's what Opera needs.


Alternatively: giving #container a 'height: 1px' or adding a border to
it, will have exactly the same effect. So will the addition of a normal
in-flow element of some non-zero size inside it, or even a non-breaking
space.
Any height larger than zero will be enough, and it simply doesn't matter
how high that #container is made in your page since the element is only
a base for absolute positioned elements.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Forget about Opera and Mac (and Windows Vista) ??

[Gunlaug Sørtun]

Taco Fleur wrote:

Sounds fair, I would say "Tough luck!" then, since the pages validate
 and the browsers choose not to display it properly. If the users 
complain I'll tell them "sorry, but we did everything by the books, 
look at your browser, get rid of it and change to PC ;-)".


Would be more or less the same as throwing all standards overboard IMO,
as "valid" doesn't mean "functional".

I think you should rather check again, and see if getting one more
browser on board isn't worth the effort of making minor CSS changes.

FYI: changing from...
#container {padding: 0;}
...to...
#container {padding: 1px 0;}
...is enough to get Opera 9 on board.
It's still perfectly valid with this change, and doesn't affect other
browsers.

Opera 9 needs that element to take up space (for whatever reason), which
it doesn't in your page at the moment. Any method will do.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] a new IE bug? maybe not

[Gunlaug Sørtun]

Tee G. Peng wrote:

Both methods work well except with Georg's method, there are slight
 shortcomings.


You've changed/added more from the original than I did :-)

I tested my suggested additions/changes on a copy of your original page
in Firefox from -6 to +20 font-steps, without any column-drops.

Retested just now with -6 to +40 steps. Same flawless result (no drops),
but I had to use my entire screen-width of 3800px in order to keep the
page in view at +40 font-steps.

--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] a new IE bug? maybe not

[Gunlaug Sørtun]

Tee G. Peng wrote:

http://new.marinersq.com/html/aerobics-3.html

The only thing I see that the right column drops to the bottom is
when I resize the text to smaller. Is there a way to fix?


Basically: don't mix em and px on side-by-side containers/columns.
Instead; leave the tricky calculations to those browsers.

The following addition will let the layout self-adjust and keep
everything lined up - regardless of font resizing...

#content {width: auto; margin-right: 230px;}

#right {margin-left: -216px;}

...and it'll still be an em-sized layout.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Lists and DIR=RTL

[Gunlaug Sørtun]

Thierry Koblentz wrote:
I just found the issue and put something together: 
http://www.tjkdesign.com/test/whitespace_and_rtl_direction.asp


Just an observation: whitespace doesn't matter in Opera 9 (from prev1
onwards).
So, whitespace may be important to browsers when dealing with such
cases, but it shouldn't be.

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] different spacing across browser & in

[Gunlaug Sørtun]

Taco Fleur wrote:
Thanks, any suggestions on how to solve that? I can't remove the 
clear:left


You can hack in a...

form {margin-top: -15px}

...(or another value) for IE/win only - using your favorite hack.

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] help with layout postioning

[Gunlaug Sørtun]

Kevin McMonagle wrote:
-im relieved that you say that the negative margins are ok. I had a 
proggrammer at work complain about them and a couple posts here made 
me wonder if it was ok.


I've heard/read complaints about every single CSS-based method in use
for laying out web pages. Yet, most methods work just fine, and can be
combined, when the designer/coder know when, where and how to use them.
The rest is a question about browser-support and personal preferences.

Im planning on replacing those underscore hacks with the star 
selector method, is that still the way to go with ie 7 on the 
horizon?


* html selector {}
...will work just fine to target IE6 and older, so that's a good
replacement for the 'leading underscore' hack. IE7 will ignore both.

IE7 shouldn't need any hacks, but I'm pretty sure it will for many
layouts. So far only this hack seems to work...
*:first-child+html selector {}
...but I have no idea if that will last even into the final release, so
I won't recommend its use.

I'll give the fonts a room for a couple resizes-forgot about that 
one.


Give IE6 a chance while you're at it, without the user having to 'ignore
font-sizes', although it should ideally work then too - up to 'largest'.
Remember also that some out here (like me) has a 'minimum font-size' set
since we won't bother with resizing when we surf around. (It's amazing
to see how many sites that can't even take 'minimum font size: 14px'
well, because of the font sizing methods used.)
Advice: test a bit across browser-land, so you know what your design can
take.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] help with layout postioning

[Gunlaug Sørtun]

Kevin McMonagle wrote:
[...] I was worried that negative margin usage was becoming out of 
control.


It was suggested that I use absolute positioning on one of the 
columns(navigations) to rely less on negative margins. This caused 
the column to vanish in ie pc.



Heres is the negative margin version http://208.106.188.137/index.htm


Didn't find the absolute positioned version, but I recreated it with
your other stylesheet as base. Yes, IE has serious problems getting the
stacking right.


Now, I can understand that it is easy to lose control over negative
margins and floats, but I think it's the best option, with best
browser-support, at the moment. Even IE understands negative margins
(with a bit of help).
So, I'd say you had it right the first time, and should continue from
there.

Details:
- There are a couple of CSS errors that are *not* caused by the
underscore hack. They should be fixed.
- Page shows some weaknesses when subjected to font-resizing -
especially in IE-win. Those should be dealt with.
- Some text is unreadable because of low contrast.

Other than that I can't see any real problems.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Max-width issues

[Gunlaug Sørtun]

John 'Max' Maxwell wrote:

Is my syntax or something incorrect or is there just no way of adding
 this fix without going 'invalid'?? Does the above code even belong 
in a style sheet as it doesn't look like standard CSS to me.


Your syntax is correct, and if you've got the values right it'll work
fine in IE6 (and IE5+ win).
Ref: 

An IE-expression is by definition: proprietary, non-valid, CSS - you
can't make it valid. Nevertheless; IE-expressions belong in CSS, and
nowhere else.

You can hide it - and other non-valid workarounds for old IE-win - from
the validator by putting them in a separate stylesheet, linked to from
inside a 'conditional comment'.
Ref: 

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Accessible Map with UL Problem

[Gunlaug Sørtun]

Micky Mourelo wrote:

1. No, you can't. (I love this game)


 :-)
(I never play games, so have fun then)

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Accessible Map with UL Problem

[Gunlaug Sørtun]

Micky Mourelo wrote:
I wouldn't call the map accessible since you can't access the map 
without css ;o).


Yes, you can.
You should have tested first.

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Accessible Map with UL Problem

[Gunlaug Sørtun]

Elle Meredith wrote:
In IE6 my map is pushed down and to the left. 
http://waznelle.com/td/v1.php?page=divesitesmap


Add a suitable 'hasLayout'[1] trigger so IE gets something "solid" to
position in relation to - like...

#content {height: 100%;}

...and it'll work just fine.

regards
Georg

[1]http://www.satzansatz.de/cssd/onhavinglayout.html
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] The usability of a frame-style layout

[Gunlaug Sørtun]

Opera has a "navigation bar" that users can turn on or off. It sits
 across the top of a page, and is populated by LINK elements in the
 HEAD section of a document.



Do you happen to know any sites that work with this concept? So any 
sites that have LINK elements in the HEAD section that would show up 
in Opera?


Mine does...

...with a few shortcomings:
1: Opera doesn't support hierarchical links all that well, so I haven't
added any 'child' links.
2: Mozilla's support is better, but it is slightly complex to use with
its many dropdowns, so I have not used its support as base.
3: Lynx is superior in its support for link-relations, but that browser
isn't widespread enough to add the extra link relations for.

More about link relations here...



You may also be interested in PPK's revamped site. See for example
 the "Blogs" page, and activate the "show site navigation" link on
 the left. Is this what you had in mind? -



Exactly. Well, I think there must be a better way to design it, so it
 doesn't overlap important content, but in the long run this is what 
I was thinking about. I guess I shouldn't have titled it 
"frame-style" - it took people off track with the discussion. But 
this is exactly the idea - why not provide navigation at all times to

 the user (in a standards compliant way of course)?


I think this page present what you want...

It's as standard compliant as you may wish for, and I think even IE7 can
handle it now.

I use the same 'position: fixed' on my page (linked above), but the
"sidebar" isn't populated with links since it's on a menu page.
The difference is that even IE6 is "apparently" able to support it on my
page, but that doesn't make IE6 "standard compliant", I'm afraid.

More about CSS frames here...


regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Problem with css dropdown menus

[Gunlaug Sørtun]

Andreas Boehmer [Addictive Media] wrote:


http://www.addictivemedia.com.au/clients/test/test.php

You will see that if youo move the mosue over the "Services" item, 
the dropdown that appears lies behind the "Useful links" item. I 
would rather have it infront of the "Useful links" item.


I actually thought that the z-index would allow me to move the 
dropdown to the top, but that doesn't work.


Yes, it does, but you're adding 'position: relative; z-index: 1;' to all
states, so it has no effect on the stacking.

Restyle it so only the hovered state is positioned and stacked...

#primaryNav li{position: static /*default*/;}

#primaryNav li.Over,#primaryNav li:hover {position: relative; z-index: 1;}

...and the dropdown is automatically stacked in front when it appears.

It won't look much different though, since the dropdown "drop down"
below the two top-links. If you want the dropdown to *cover* the
top-links, then you also have to move it up.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] How do I set a css-value for Safari alone?

[Gunlaug Sørtun]

morten fjellman wrote:

Great tips, guys! Your suggestions are somewhat easier to understand
than the aformentioned article :D


No wonder. That article was last updated 2 years ago, and is therefore
also in part pretty outdated.

I suggest you read this instead...

...and - if you _must_ use hacks - look at the recently updated
stylesheet I use for practical testing...


The bottom line is that all hacks should fail eventually, so I wouldn't
seriously use CSS hacks to separate browsers.

Progressive enhancement is another matter.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Re: [WD]: Rethinking Font Size 76%

[Gunlaug Sørtun]

Ignore this thread. I sent a response to the wrong list :-)

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

[WSG] Re: [WD]: Rethinking Font Size 76%

[Gunlaug Sørtun]

Rimantas Liubertas wrote:

I am still waiting for the research, showing how many of "majority of
 the planet's web users" have an idea where they can change "their" 
defaults...


I'm waiting too, but I'd like such a research to cover _all_ web users,
and I'd like to reverse the question. I have no idea what the result
would be or what to use it for, but it would be interesting.

Somehow I got the feeling that web designers know best what is suits 
majority of the users -- it's their job, after all.


I hope they know what they're doing - regardless of what title they use.
After all: knowledge is more important than titles - regardless of what
field one's working in. I think that's why we discuss these things.


And, yes, it's ok to size text in pixels.


Of course it is, since all browsers can change or ignore text size -
regardless of unit. Being ok doesn't mean it's a good idea though.

---

My position is that everything starts at 100% - whatever that might be.
Thus, I usually declare 'font-size: 100%' on the first, outer, element
that can take font-size - which depends on what type of layout I'm
creating. This means: it isn't necessarily html and/or body I declare
font-size base on, since some layouts require that I can pick up the
browser's own default for those elements.

An occasional downsizing further into a document is ok - I think, but it
shouldn't matter significantly if a user overrides any font size I
declare - anywhere.

regards
Georg
--
http://www.gunlaug.no



***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] XHTML Marquee

[Gunlaug Sørtun]

Richard Czeiger wrote:
poor old me I still have opera 7.5 and it's fine there. I might try 
and download opera 9, though I'm tempted to give up on it. Logs for 
most of my clients show ALL versions of opera total a massive 0.8% of

 users. I don't think I can waste my time on that


No problem. Developer tools in Opera show that the script seems to be
working, but I didn't dig any further.

And for the record: if Marquee were in regular use, then I would
probably block it anyway. Maybe I already have - I'm to lazy to check.

Such blocking-mechanisms exist in many browsers, so that should be taken
into account on regular sites. Probably not a problem on more targeted
sites.

Anyone else finding this to be the case? At what point do you throw 
them the print style sheet instead?


:-)
Many sites might gain on something like that - in all browsers. Should
be a regular 'progressive enhancement' alternative.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Semantics - (was : class names and IDs (which was p:first-line))

[Gunlaug Sørtun]

Designer wrote:

OK, so how far do we take this thinking on semantics etc.  For
example, many people use a div called 'header'. Suppose I decide to
put this at the bottom?!!!  Taking this to the extreme, it suggests
that 'header' is presentational/positional.


Well, I regularly put parts of what end up as visual header, below
everything else in the source-code. Wonder what I should call that
"thing" now :-)


I'm calling this the 'standards contradiction syndrome'. :-)


Indeed, but quite interesting. Guess I like problems that have no clear
solutions. Maybe it'll clear up one day.

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] XHTML Marquee

[Gunlaug Sørtun]

Richard Czeiger wrote:
I'd appreciate any comments/suggestions/criticisms... 
http://www.grafx.com.au/wip/marquee.html


Resulting in a blank page with no Marquee in my Opera 9.
Unreadable even with font-resizing to largest in IE6, because of too
high contrast.
Quite a few steps font-resizing needed in Firefox to make it readable,
because of too high contrast.

Generally: high-contrast light on dark should have bold text to reach
the same readability-level as dark on light when small font-size is used
- especially on high-intensity/high-contrast lcd screens.

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Trouble with float layout (IE6 versus Firefox)

[Gunlaug Sørtun]

Doug Wigginton wrote:
[...] The idea is that when the browser resizes, the second 
left-floated div will drop down below the first enabling all the 
content to display in an 600 x 800 resolution. This works in IE6 
(win) but not in Firefox, therefore my css is probably 
wrong/incomplete. In FireFox, the whole right-floated div drops down 
below the left div.


Haven't studied float-behavior lately, so I can't say what's right or
wrong. Can only say that all my non-IE browsers agree with Firefox on
how those floats shall drop, leaving IE6 on its own with its interpretation.

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] p:first-line

[Gunlaug Sørtun]

Mathew Patterson wrote:
You have probably heard this same argument in reference to using 
 instead of  . The idea is that the class name you use 
should reflect the semantic *meaning* of what it does, not 
necessarily the physical way it achieves that meaning.


The idea is fine and recommendable. However, while  may be
depreciated as an element with purely visual "meaning", it isn't
deprecated - yet. If "purely visual" is all we want, then  is as
"meaningful" - although not as versatile - as a  with a
class-name. A meaningful element like , with or without added
styles, may after all not be what we want in all cases.



Personally, when IDs and classes has to stay "movable", which they
should be in most cases, then I tend to fall back to "easy to find but
otherwise not semantically loaded" names.

While 'header' and 'footer' tend to be called just that (for no obvious
reason), content-containers and other major containers are often named
'content', 'add1', 'add2' and so on depending on where they are in the
source-code and what they are meant to carry.

Similarly: if I add a class to an element in a single page, then I may
either name that class something like 'int01' and add the style in the
page-head, or name it 'extXX' (where XX is a suitable number) and keep
the style in a reserved section of my stylesheet. Such names carry no
meaning, but they are easy to keep track of between source-code and
stylesheets.

One can go overboard with semantics, and regardless of how one organize
and reorganize and add semantics into source-code and stylesheets, the
"meaningful" ID and class names may become "completely meaningless"
under certain condition. Linking them in a purely "where is your
counterpart" way won't be affected though, since there is no other
meaning implied.



Probably someone who might like to tell an old programmer that he has
lost track when it comes to semantics, but I think a certain form of
semantics should be applied where it has "a meaningful place", and
another one where needed. I think "semantics" has to make sense ;-)

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Navs at bottom of pages

[Gunlaug Sørtun]

TuteC wrote:
Beautiful!! I´ve never seen link-relations working, it should really 
be a built-in spec for browsers... easy to get used to. A way to let 
anybody, in any site, know where they are standing.


W3C seems to recommend them...


...and have done so for a long time.

You can turn on the 'navigation bar' in Opera - Tools>Appearance>Toolbars...
Mozilla support them too, and Firefox could get an extension last time I
looked.
IE doesn't support them, and I haven't tested in others.

It should have also something like "sitemap"; "Content" plays that 
role?


On my pages, yes. Some use 'index', but I find 'content' the most
correct (and supported) term the way I have organized that section.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Navs at bottom of pages

[Gunlaug Sørtun]

Kenny Graham wrote:

I've noticed many people from this list stil put text-and-broken-pipe
 navs at the bottom of their pages.  Is this still needed?


I replicate link-relations as ordinary links in the page-footer, since
there are so many browsers that can't make use of, or don't default to
presenting, visible link-relations.

A simple-styled short-list of basic navigation is a 'nice-to-have' thing
IMO, so I'll probably keep adding them until all browsers present
link-relations by default.

Typical example found on...

...and the rest of that site-section.

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Help with Flowchart & Min/Max Width IE Win

[Gunlaug Sørtun]

Sarah Peeke (XERT) wrote:


PROBLEM A






The main problem appears to be the left margin when adjusting the 
browser size (I'm particularly interested in 800x600 and larger 
resolutions).


The whole construction depends on font-size, so it is rather weak across
the entire browser-land. Should be reworked with less em-values.

IE/win needs a 'hasLayout' trigger on main parts, or else it'll lose
track of the entire page.


PROBLEM B

I have also incorporated some min-width, max-width stylesheets for 
IE:





 (corrected the link-address)

That's an expression for quirks mode only, so it'll work in IE5.x but
not in IE6 in "standard compliant" mode.
You'll have more success with one of these 'dual mode' "beauties"...


In your page it doesn't matter which mode IE6 is in, so you may as well
run IE6 in quirks mode and make the present expression work.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] IE7 RC1 oddity

[Gunlaug Sørtun]

Tony Crockford wrote:
it is driving every page on the site from the one stylesheet and 
there are a lot of list menus, hence the need to specifically 
identify them.


Makes sense, but how many #maprolloverlist are there? I can only find one.

Example:

#maprolloverlist li#rollover1{position: absolute; bottom: 18px; left:
173px;}
.
#maprolloverlist li#rollover115{position: absolute; bottom: 335px;  left:
646px;}

...should work and become a bit leaner as:

#maprolloverlist li {position: absolute;}
#maprolloverlist li#rollover1{bottom: 18px;left: 173px;}
.
#maprolloverlist li#rollover115{bottom: 335px;left: 646px;}

And...

/*active squares*/
body#map1 #maprolloverlist li#rollover1 a,

body#map47 #maprolloverlist li#rollover47 a{
   color: #000;
   background-color: #000;
}

...should work as...

body #maprolloverlist li a{
   color: #000;
   background-color: #000;
}

...since all #maprolloverlist seem to use exactly the same styling, but
maybe I'm missing something really !important here - wouldn't be the
first time :-)

the one thing that I think is making a lot of problems is my attempt 
to use Dan Cederholms bulletproof font sizing technique using 
keywords...


Well, I never use it (and probably never will), and what you have there
is a bit old and outdated. I can't see that as a source for major
problems though.

Anyway, I would use...

body {font-size: 100%;}
...and size down (if seen as necessary) on text-carrying elements
further in. Much more reliable in today's browsers, and prevents
oversized text when subjected  to "small amounts" of 'minimum font-size'
in Firefox and Opera.

I would also add...

#maprolloverlist li a {width: 8px; height: 8px;}

...(or whatever dimension you like) to overcome the 'minimum font-size'
issue in some browsers. Won't help on IE6' 'ignore font-size' though,
but I think you'll just have to ignore that since there aren't any
/perfectly good/ solutions around.
That is, unless you ignore the number in those links (which I can't read
anyway). Then the previously suggested...

#maprolloverlist li a {width: 8px; height: 8px; overflow: hidden;
position: relative;}

...works just fine in IE6 and all other browsers.

If I had the time, then I would also create a pop-up instead of relying
on the browsers own tool-tip. There are a few, working, alternatives around.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] IE7 RC1 oddity

[Gunlaug Sørtun]

Tony Crockford wrote:
Opera 9 makes big "little" boxes unless you allow the minimum 
font-size to be smaller than the default 9px, so that's an issue I 
need to address.


So does Firefox.
IE6 does the same when 'ignore font-size' is applied.

My preference is 'minimum font-size = 14px" during regular surfing -
which I usually perform using Opera. That's why I noticed it.
Using 'minimum font-size' is a nice "site-breaker" err... "-tester" ;-)

It's been nine months since I wrote the CSS for that site and I'm 
doing things slightly differently now, maybe I need to refresh the 
CSS with my current "best practices" in mind...


Some of the general workarounds don't seem to make an impression on my
browsers anymore, like: no scrollbar forced upon my Opera 9.

Probably could do with slightly simpler CSS here and there, like less
use of the entire ID/class chain to target a type of elements inside a
container. Didn't look deep since that's not the real problem this time,
but unless that stylesheet is also behind other pages, it seems to be a
bit "over-specified" and complex.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] IE7 RC1 oddity

[Gunlaug Sørtun]

Tony Crockford wrote:

http://www.bclm.co.uk/map.htm


Would be nice to know which browsers are rendered this page "correctly"
at the moment, as IE6, Firefox 1.5.0.6 and Opera 9.01 don't seem to
agree on much.

The addition of this...

#maprolloverlist{width: 767px; /* needed for IE7 it seems */}

...but it is also needed by Opera 9, and this...

#maprolloverlist li a {width: 8px; height: 8px;
overflow: hidden; position: relative;}

...apparently help a bit across browser-land, but it's just a guess and
it isn't complete. So, what is it supposed to look, and behave, like?


Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] IE7 RC1 oddity

[Gunlaug Sørtun]

Tony Crockford wrote:

should an undimensioned div stretch to the full width of its
container or only to the width of its content?


If it's a float, or controlled by the behavior of an undimensioned
wrapping float, then I think it should all shrink to the width of the
non-positioned content.

Anyway, it's a construction full of conflicts, so I wouldn't leave it to
the browsers to sort out what the standards say about it. I'd rather
solve the conflicts myself, and declare everything.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] IE Stops page load

[Gunlaug Sørtun]

Darren Wood wrote:
http://www.dontcom.com works / displays as expected in FF/Safari but 
it goes mental in IE.


Someone will probably say that I'm a mental case myself, but anyway.
I changed the order of the two first script-links in a local copy, and
IE6 started to behave just fine.

Can't see any difference in behavior/rendering in any of the other browsers.

< nuts! />
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] witdh:expression

[Gunlaug Sørtun]

TuteC wrote:
What do you think? I don´t like it, I´m not comfortable using it. 
This site is not using a special IE stylesheet and I don´t want to 
start using one! Shall I leave it? Testing in different browsers 
works as I want, but I just want to make things the best I can.


I don't like it either, but if you want IE6 to behave like it can handle
'min *and* max width', then there are not all that many solutions -
'IE-expression' or regular Javascript.

Don't know when you picked up that "full-blown" solution, but a few more
options - also 'expression-based' - are added to this page...

I prefer the "full-blown" solution myself.

Of course an 'IE-expression' is non-valid CSS, so if that's the
border-line you don't want to cross, then 'IE-expression' is not an
option without 'conditional comments' or other hiding-methods.
Maybe you'll like this better...



Just simulating 'min width' is another matter, as it isn't difficult to
prevent IE/win from collapsing.
 is as good as any.

regards
Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Site check [Dineen and Westcott] and IE bug

[Gunlaug Sørtun]

Mark Harris wrote:

 imagine there's a heaven, I wonder if you can...

;-)


Sure I can! I use Opera - but I don't challenge that
inline-style-comment bug all that often.


PS Thunderbird spellchecks "Gunlaug" as "Onslaught"  heheh


Your Thunderbird didn't do too bad, really. "Gunlaug" means "dedicated
for war" in old Norse ;-)
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Site check [Dineen and Westcott] and IE bug

[Gunlaug Sørtun]

Saviour on a stick! Every time I think I've heard of the weirdest 
thing, along comes Internet Exploder...


Yeah, isn't it fun? :-)

You know, the tech guys at Microsoft can't have a lot of fun with 
this, bolting stuff on in order to make the pig fly. I wonder why 
they haven't just built a new one from scratch and according to 
specs?  (I know, I know - marketdroid requirements)


They're just providing us with "more fun" - the "-soft" way.
They have fixed around 200 bugs and weak spots in IE7 - on paper at
least, so there's only a few thousand left. That's not so bad.

If they built a new browser from scratch then most of the bugs and
weaknesses might disappear all of a sudden, and all the fun would be
gone too. Just imagine what the web would look like then...
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] Site check [Dineen and Westcott] and IE bug

[Gunlaug Sørtun]

James Oppenheim wrote:

http://dineenandwestcott.com.au/about.php

The floated content seems to drop under the sub-nav on the left when
you resize the browser to different resolutions in IE on the PC. This
 problem does not happen in firefox, netscape, mozzila, advent and
opera on the PC or firefox, safari and IE on the MAC.


Looks like you have met the 'italic bug'...


That bug will make make the float drop whenever a word in the italic
text touches the right edge and makes the float expand ever so slightly
- only in IE/win.

Georg
--
http://www.gunlaug.no


***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***

Re: [WSG] GRR IE Help Please

[Gunlaug Sørtun]

Tina Starnes wrote:
Now this is working perfect in FF - but for the life of me IE will 
not display proper.



http://heavenly.crsdesignsinc.com/index.php?main_page=index&cPath=6


As mentioned by others: you're using "the wrong overflow".

Firefox is getting the 'overflow' wrong, and IE is expanding the
container when it gets the correct 'overflow'.

Add...

.centerColumn {
position: relative;
overflow: auto;
}

...and you'll see where the scrollbar ends up in IE - outside the
container, so you can fix that.
The general 'overflow' will also work more consistent across
browser-land, as not all browsers support 'overflow-x/-y' yet.

Comment: how much empty space do you want under the scrolling container?
Now it's relying on font-size - which isn't always your default in any
browser.

regards
Georg
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] correct markup for frames? : was [target=_blank]

[Gunlaug Sørtun]

Designer wrote:

I'm getting fed up with this. You still haven't told me WHY it makes 
perfect sense! Why, that is, the W3C have decided that using a target

is undesirable, ultimately.


I have no idea why W3C decide anything, but they have made some
decisions and written the standards accordingly.

I may suggest:

1: Target has been misused to such a degree that some browser-makers
have added defenses against it. Most browser-makers are members of W3C.

2: Target isn't working too well on all of today's (and tomorrow's)
software and devices. Plenty of confusion around on that subject.

If you are using a frameset, it's highly likely that you'll want to 
make use of the target facility.  Yes, you can do it using 
transitional, but the very name 'transitional' implies that it's OK 
for now, but it won't be when you 'do it properly'. When you 'do it 
properly' you can't use target, even though you can use a frameset.


A frameset _is_ a 'transitional' solution, so it _is_ only OK for now.
Same with 'Transitional', so Frames and Transitional suits each others
like hand and glove. There are no 'Strict Frames'.


What is it about targetting that is so bad?


I never called targeting bad, although I "kill" all targeting at my end
(as a user). Targeting is a left-over from yesterday, so I guess it
depends on where you want your designs to go is what matters when you
decide whether to use targeting or not. And then you should use the
proper doctype/standard. That's what those standards are there for.

There will come other standards, and some may even be implemented across
browser-land - one day. Maybe you'll get a suitable, and working,
'target' back in one of them.

regards
Georg
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] correct markup for frames? : was [target=_blank]

[Gunlaug Sørtun]

Designer wrote:
The 'problem' is that you can use a strict xhtml frameset AND xhtml 
files and that's OK with the W3C recommendations - so why on earth 
have they done away with one of frames main uses/advantages, i.e., 
targetting one or more of the frames.  No matter which way you look 
at it, it doesn't make sense.


Sorry, but it makes perfect sense to keep Strict out of Frames. W3C
haven't done away with anything since you still can use Transitional.
They are just telling you (quite clearly) that you can't use a
"transitional solution": Frames and 'target', in combination with Strict.
You are given a choice between standards: Transitional /or/ Strict. No
need to mess them up and make them one and the same.

regards
Georg
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] IE7 standards support very bad according to some

[Gunlaug Sørtun]

Bruce wrote:
Looks to me like he's blaming ie for his design problems. On 
www.newscloud.com there is 226 errors returned by the validator. 
Scrollbars at 800px in all browsers, image distortion and odd text 
sizes...


Since I always add a bit of user-preference on any site (minimum font
size = 14px), www.newscloud.com looks slightly broken in Firefox 1.5 and
Opera 9 - worst in Firefox, and shows the usual weaknesses in IE6 - with
text that (mostly) cannot be resized and so on.
HTML validation: 207 errors (at the moment).

Pretty much a case of designer/coder problems rather than weak browsers,
IMO. The upgrade-banner looks rather counter-productive.
That site: www.newscloud.com certainly shouldn't have any problems with
neither IE6 nor IE7.

---

When it comes to IE7 and its "improved standard-support": well,
Microsoft have added some standard-support in IE7, but not much compared
to IE6.
Mostly they have fixed bugs, so most of the "claimed" standard-support
in IE6 looks like (more or less) _real_ standard-support in IE7. That's
better than nothing, but not much.

IE7 should be given a chance in "standard compliant mode" so one can
take advantage of the few improvements it has, but it can't do much as
long as we're talking standards. IE7 will still need a few "corrections"
when given anything but the simplest layouts, but the number of
"corrections" will be much smaller than for IE6.

Georg
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] htaccess, help please

[Gunlaug Sørtun]

[EMAIL PROTECTED] wrote:
[...] it just hit me.  opera was obeying the css and firefox ignored 
it.  strange, huh?


:-)
Not at all... ;-)

Seriously, it isn't the first time I've experienced such behavior in
Gecko. Although CSS should rule, Gecko often ignores it and use what's
given in HTML. Gecko is getting better at it with each new version, but
isn't quite there yet so you better feed it correct HTML attributes.

Georg
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] on P & H1-H6 "Block" Elements

[Gunlaug Sørtun]

Shlomi Asaf wrote:
i just been informed that P & Hn Elements are Inline Element. How 
Come? how can those elements be inline, and the user-agent render 
them as Block-level elements?


http://www.w3.org/TR/html401/struct/global.html#edef-H1 
http://www.w3.org/TR/html4/struct/text.html#edef-P



can anyone plz explain to me how come a P & Hn tags can be inlines???


They are *not*. Paragraphs and headings are block-elements, but they can
only have inline-elements as content. That's actually what W3C says.

And from another page...
  "Block-level elements are those elements of the source document that
are formatted visually as blocks (e.g., paragraphs)."[1]

---

I think the following list is still pretty good...

The following are defined as block-level elements in HTML 4.0:
[Strict only]

ADDRESS - Address
BLOCKQUOTE - Block quotation
DIV - Generic block-level container
DL - Definition list
FIELDSET - Form control group
FORM - Interactive form
H1 - Level-one heading
H2 - Level-two heading
H3 - Level-three heading
H4 - Level-four heading
H5 - Level-five heading
H6 - Level-six heading
HR - Horizontal rule
NOSCRIPT - Alternate script content
OL - Ordered list
P - Paragraph
PRE - Preformatted text
TABLE - Table
UL - Unordered list

The following elements may also be considered block-level elements since
they may contain block-level elements:

DD - Definition description
DT - Definition term
LI - List item
TBODY - Table body
TD - Table data cell
TFOOT - Table foot
TH - Table header cell
THEAD - Table head
TR - Table row

The following elements may be used as either block-level elements or
inline elements. If used as inline elements (e.g., within another inline
element or a P), these elements should not contain any block-level elements.

BUTTON - Button
DEL - Deleted text
INS - Inserted text
MAP - Image map
OBJECT - Object
SCRIPT - Client-side script

---

regards
Georg

[1]http://www.w3.org/TR/CSS21/visuren.html#q5
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] IE7 bug?

[Gunlaug Sørtun]

Andrew Ingram wrote:
So I added in another rule that changed the background color of the 
element with the drop-down hover and suddenly everything started 
working, take the rule out and it stopped.


I think you have hit the old IE-bug on CSS popups...

Don't think that's fixed in IE7.

Georg
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] Support for IE5/Mac? (was Browser stats)

[Gunlaug Sørtun]

SunUp wrote:


I know how to prevent v.4 browsers from getting my styles, but how do
 I stop IE5/Mac from getting them?? All I know how to do is to give 
them something different, not how to exclude them entirely.


Wrap all styles you don't want IE/Mac to see in an @media rule.

Georg
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] Using Tables w/CSS

[Gunlaug Sørtun]

CK wrote:
Your attention is greatly appreciated. Would you expand, off-list as 
to not to cause clutter, on the quoted text?


Some more CSS-tuning needed, and you'll have to decide what mode 
IE6 should run in.


Don't think the following "causes clutter", as there certainly are some
who may welcome, or need, an update.

About IE6' mode...


Myself, I usually keep IE6 in 'quirks mode'...

...but that's not everyone's preference :-)

About CSS-tuning...
...just compare the result in the latest Opera, Firefox, Safari, and of
course IE6/7 and whatever other browser you want to support, and make
sure they all render your page as you want them to. Some differences at
the moment.
Table-designs are no more cross-browser reliable than CSS-layouts ;-)

regards
Georg
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] Using Tables w/CSS

[Gunlaug Sørtun]

CK wrote:
The problem is solved, but the question lingers is this the most 
streamline solution?


Don't know since it is a bit minimal at the moment.

If this is what you're working on...

...then it may at least pass as a valid and conforming xhtml document
once it is cleaned up by a well-instructed HTMLTidy.

Cleaned up and served as 'text/html'...

...or served as 'application/xhtml+xml'...


I guess you want the former :-)
Some more CSS-tuning needed, and you'll have to decide what mode IE6
should run in.

regards
Georg
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] Opera Bug? (Table-displayed, left-floated, min-width content)

[Gunlaug Sørtun]

Joe D'Andrea wrote:


The latest iteration might be the winner though [2]. We'll see.



[2] http://test.joesapt.net/cf/opera-ul-table


Just to state the (more or less) obvious: 'width' = 'min-width' and
'height' = 'min-height' when we're dealing with CSS table elements that
take dimensions. Same as for HTML table.

Georg
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] table display values - how to

[Gunlaug Sørtun]

Tee G. Peng wrote:
Hi, can you please tell me how to use these table display values in 
non-table layout, better yet if you can show me examples. I 
understand the concept but I don't know how and when to use them in 
CSS layout with selectors.


CSS 2.1 about 'CSS tables'...


Example of a 'CSS table' layout - with 'simulated look' in IE/win.


My curiosity derives from examples I see here an there, for example, 
Georg made an example



#preview_pic {margin: 10px auto; float: none; display: table; width: 
1%;}


on Centering an image thread.


The example isn't a complete solution, as it contains only the styles
needed to correct and override existing styles in a non-working page
presented on [css-d], IIRC.
It was all about centering a complete div-container set with a
shadow-effect around a replaceable image.

To dissect it...

margin: 10px auto; = normal block-centering.

float: none; = overriding existing float-declaration (used in the
non-working page).

display: table; = making the element shrink to size of inner-element,
and auto-expand if the inner-element - and the size of it - is changed.
That's how a normal HTML table would behave, so the example is just
replicating that behavior.

width:  1%; = giving IE/win a 'hasLayout' trigger, and providing a
"non-disturbing" min-width for the #preview_pic element.



One time I saw a

#id { display: table-row}


From CSS 2.1...
"table-row (In HTML: TR)
 Specifies that an element is a row of cells."

The examples I see from CSS, the definitive guide,  these values are 
in chapter 11, table layout with XML examples.


Also, are they supported by IE 6 and below?


No, and IE7 doesn't support any part of 'CSS table' either. Maybe IE8
will :-)

We can use the proprietary 'hasLayout'[1] behavior to simulate some 'CSS
table' behavior, and we can "fake" some other parts in IE/win.
We can *not* simulate all parts of a standard 'CSS table' in any IE/win
version.

Despite the lack of support in IE/win, parts of 'CSS table' are useful
for getting specific behavior/line-up in standard-compliant browsers.
I have some examples of workarounds for cases when we can't avoid
triggering 'hasLayout'[1] in IE/win - a kind of 'reverse engineering'...



regards
Georg

[1]http://www.satzansatz.de/cssd/onhavinglayout.html
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] Site help needed please ... I can't see what i've got wrong

[Gunlaug Sørtun]

Michael Kear wrote:

http://beyondharvest.com.au.thecoolserver.com/contact-us.cfm



Loads below the menu structure in IE6 (it's ok in Firefox)


Given the fact that you're using a doctype that isn't valid when served
as 'text/html', and that the page is styled so it can't take any
font-resizing properly in any browser, I think the following should do
for "fixing" IE6...

* html div.content {overflow-x: hidden;}

It will prevent IE from auto-expanding the container, which causes the drop.

Georg
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] Suckerfish Dropdown problem - IE

[Gunlaug Sørtun]

Christian Fagan wrote:

Don't know what you mean by IE6 running in "quirks" mode.


The basics about *'standards' vs. 'quirks' modes* are described here:


Georg
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] w3c inspecting icon factory

[Gunlaug Sørtun]

[EMAIL PROTECTED] wrote:


but georg, isn't that what standards are for?


Sure! :-)

Now, how about the support for standards around browser-land?
Not too good - yet.

Also, how about standards being created in such a way that they provide
means for delivering content of all kinds across the web?
Not all that good either - yet.

Wrap the above together and... no, I don't think we're off the
gray-scale - yet.

Georg
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] w3c inspecting icon factory

[Gunlaug Sørtun]

[EMAIL PROTECTED] wrote:

is there then no difference in wanting to serve the visitors to your
web site(s) what you think is best for them?


...and what if you're wrong in your thinking? :-)

To stay within the 'food-analogy':
- good food can kill someone who isn't used to it. Good web-solutions
may not be supported, and can even "kill" a browser in rare cases.

Same with everything else on the gray-scale - which is where _all_ food
and _all_ web-solutions are anyway.

Choices, choices ;-)

Georg
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] Rounded Corners

[Gunlaug Sørtun]

Paul Novitski wrote:






Your basic structure looks like it would be easy to implement in
JavaScript or PHP.


Good. I'm almost completely lost when it comes to both Javascript and
PHP, so I couldn't get any further on my own ;-)
In short: I need help.


If every element that needs the t#s and b#s inserted has a common
flag, say an additional class name (such as "rc" above), JavaScript
could walk the DOM and insert the extra divs where needed.

Are "brdr-field bgnd1" and "hdl-field" part of the original page
markup, or can they be generated too?


It's an old page-design and not very well styled. I've stopped using it,
so I can rethink everything.
In new designs I think I can reduce it down to something like...


Easy borders


...and get the same style-effects, as long as a given number of divs can
be generated above, around and below the h4 in this case.

Something like...





Some headline
some text.

some more text.





...is a likely scenario.

If those elements can be generated, then there's nothing stopping me
from making it work. All I need to do is to use the first class on the
outer wrapper so I can style the generated elements inside to suit my
wish for "strange shapes" on a particular container.
In case of javascript and lack of support, I'll let it fall back to a
basic style on the outer wrapper.

More difficult still: how to integrate it all with a real 
background-image on the box.



Tell me how you envision the background image looking.  Would the 
background image itself appear to have rounded corners as well?


Any image that provides a good background for regular, dark, text and
whatever, and yes, I want such a background-image to appear within the
"shaped corner" areas as well.

Regular pages might be given a simple background like the "frosty"
semi-transparent one I use on my old home-page...

...which isn't hard to position onto each element in the "shaped corner"
areas so it looks as one.

More figurative images will make it necessary to calculate the exact
height of the box continuously, and adjust image-positions in the
"shaped corner" bottom-area. I always work fluid, so no box-dimensions
are known before they arrive at the user-end and are affected by
ordinary browser-options. Makes it all a bit harder to pull off, me
thinks, so I can avoid the most demanding backgrounds - for now.

regards
Georg
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] Rounded Corners

[Gunlaug Sørtun]

Also, in happy times when multiple background images are commonly 
supported getting rid of one  is easier than fishing out 
all extra divs, spans, etc.


Looks to me like the CSS3 working draft for border-radius and multiple
background-images won't solve much beyond the ordinary "round box"
illusions. "Shaped borders" will not be possible to create without extra
elements - generated or hard-coded.

The hard-coded approach is not all that easy to maintain across larger
sites - and it does look ugly, and only transparent background-images
will go with any page-background and they can't be applied over/outside
the edges of the box - even in CSS3 AFAICS.

Is there a standard-compliant and 'semantically clean' way to generate
the extra elements/style-hooks needed for something like what's in this
test-page...

...that'll work in most browsers?

Needless to say that I have looked around for alternatives with at least
the same design-flexibility, or ways to improve what I have, since I
finished that test-page a couple of years ago, but I have yet to find
one that works. Lots of "conditionals" but no "can go anywhere"
solutions around, AFAIK.

More difficult still: how to integrate it all with a real
background-image on the box.

Any real solutions around?

regards
Georg
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] site check and code review

[Gunlaug Sørtun]

TuteC wrote:
Thank you very much, Georg. That´s exactly what I want: that the 
content overflows or the div expands but mantaining the same 
position. You say that if we "grow"enough the text, the sidebar will 
fall anyway down, but isn´t there a technique to make it "borrow" 
some of the space the container uses?


Yes, but there's always a limit - somewhere :-)

Defining some width and margins in 'em' will make those columns adjust
to each other when subjected to font-resizing.

The following...

#container {
width: 100%;
float: right;
margin-left: -15em /* corrected */;
}

#content {
margin-left: 11em /* corrected */;
margin-right: 20px;
position: relative;
}

#sidebar {
width: 10em /* corrected */;
padding: 0 0 1em 0;
margin-bottom: 1em;
padding: 0px;
color: #333;
float: left;
clear: left;
}

...will allow for at least 500% font-resizing in Firefox without
float-drop, but the end-User should then have at least a 1600px wide
window to avoid getting a very narrow main-column.

I tested it up to 1000% (100 steps) font-resizing in Firefox - just to
make sure it worked, on a 3800px wide window. Quite readable ;-)
You shouldn't push Firefox much further than that, as it may actually crash.

regards
Georg
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] Rounded Corners

[Gunlaug Sørtun]

Scott Swabey wrote:
Seems like the use of semantically neutral elements to create 
imageless rounded corners is more than acceptable. Am I missing 
something?


Apart from "bloated source-code"(?), no, I don't think you have missed
anything :-)

Personally, I think "bloated source-code" should be avoided, but it may
turn out reasonably well...

...even with a few "style-only" elements in there.

regards
Georg
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] site check and code review

[Gunlaug Sørtun]

TuteC wrote:
Hello, I´ve got a similar problem with the left sidebar in 
http://www.fanus.com.ar/Dev/. When in Firefox I use big font size, 
the left bar falls under the right container. And I can not make this

 right container occupy its 100% of possible width, don´t know why.


Use more suitable and stable values.

Replacing relevant CSS rules with the following will make your page work...

#container {
width: 100% /* corrected */;
float: right;
margin-left: -300px /* corrected */;
}

#content {
margin-left: 130px;
margin-right: 20px;
position: relative /* added */;
}

#sidebar {
width: 125px;
padding: 0 0 1em 0;
margin-bottom: 1em;
padding: 0px;
color: #333;
float: left;
clear: left /* added */;
}

#LeftTop div {
background-image:url("LeftTop0.gif");
background-repeat:no-repeat /* corrected */;
height:103px;
}

...but float-drops _will_ occur if font-size is bumped *high enough*,
since content on the left side will continue to grow in width. In
Firefox that means the content will overflow, and in IE/win the
containers will expand.
All I have done above is to give more "play-room" for the elements on
the left, and base the width of the main column on full page-width. I've
also made sure the main column stays on top.

regards
Georg
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] Link spacing in UL

[Gunlaug Sørtun]

Paul Bennett wrote:

I'm trying to achieve the following:
-
* list item - loads of text here. loads of text here.loads of text here.
  loads of text here.loads of text here.loads of text here.loads of text here.

  http://link.here
--

(note the line break between the link and the list item text)



Can anyone think of a pure CSS & structural html way of achieving this?




Whatever you want to write on the subject.

some text


ul li p {margin: 3px 0 2em 0;}

...you'll get the idea.

Georg
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] are transitional doctypes quickmode

[Gunlaug Sørtun]

Tee G.Peng wrote:

I always thought transitional doctypes are quirkmode but today I  was
 told it's not, the quirkmode is when a page has no doctype declared.


All 'doctype vs. modes' are listed here:


Georg
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] site check and code review

[Gunlaug Sørtun]

Elle Meredith wrote:


page: http:waznelle.com/td/ css: http://waznelle.com/td/css/base.css




1. unless I declare * {margin:0; padding: 0;} many objects do not fit
in the layout and get pushed down. Now, I tried to limit my paddings
and margins so I don't know where they come from.


Will have to rip the entire layout apart to see what's bugging it -
something I don't have time for.

Generally: Many elements have default-values for margins/paddings other
than zero, and they are not the same values across browser-land.
You have to declare your own values if you want them to line up
cross-browser wise.

Also, in IE5/win and IE6/win my #sidecol gets pushed below as well 
even though (I think anyway) it should have enough space.


It's the margin-doubling bug in IE/win.

Add...

#maincol {display: inline;}

...to "kill" that bug and make the columns line up.


2. My blockquote area, I pushed it out of its nesting div#maincol and
 IE5 and IE6 do not show what's out of the div area.


Add...

/* hide from IE mac \*/
* html blockquote {position: relative;}
/* end hiding from IE5 mac */

...and IE/win will "paint" what's outside the column-edge. It's a bit
further out than in other browsers though, so you may also want to give
IE/win its own margins while you're at it.

3. One last thing, I wanted to control my main image in CSS so I 
could replace it in every page using my CSS document. But as a 
result, I think it loads very slow. Would you think so too? and if 
so, any ideas?


Images take time to load, and a new, large, one for each page will slow
them down a little. Not much you can do about it other than to optimize
file-size for those images.

---

You have also triggered the 'em font-resizing bug' in IE/win.
see: 

Add...

html {font-size: 100%;}

...to "kill" that bug.

---

Generally: the header/navigation part of your page isn't designed to
take any degree of font-resizing in any browser. Navigation and
text-line starts overlapping other elements.
You should test font-resizing options in all major browsers, and redo
that part so it works a bit better.

regards
Georg
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] Thanks Georg, but Mike ... re Meyer's CSS AND ... :)

[Gunlaug Sørtun]

Susie Gardner-Brown wrote:

Thank you Georg. That worked! I didn¹t realise ... Really, the more I do
this, the more I discover I don't know! I'm at a loss to know how to hold
all this info in my head  Any clues on sites that have these sorts of
things listed?!?!!


Bug-lists with good descriptions and reliable fixes are few and far 
between :-)


In case someone still can't get those popups to "pop up" in IE6, a 
couple of links...





Georg
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] Meyer's CSS text popups not working in IE (PC)

[Gunlaug Sørtun]

Susie Gardner-Brown wrote:

It does have a background! [...]


No, it doesn't.
You have styled the span alright, but that doesn't affect the
LINK-element, the a, so IE/win isn't "getting it".

This will get IE's attention...


div#content li a:hover {background: #edb;}


Remember, you're dealing with a weak and buggy browser, so just add the
style for a:hover and get it working in IE. *Then* you can start
fine-tuning the background-color to make it look good in that bugger.


(based on the Meyer one but with a few additions/changes. For
example, his used absolute positioning, but I wanted to use
relative.)


You have made a few more changes than 'positioning'. Eric's example
*does* create a change on the link-element on hover (intentionally or
not), so it is working in IE.

Any changes in background or border on the  will make IE "repaint"
the link-element and open for the span inside it to be displayed.
No such changes, like your stylesheet says now, means the span will
never be displayed in IE6 - regardless of how many styles/changes you
add to the span.

regards
Georg
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**

Re: [WSG] Meyer's CSS text popups not working in IE (PC)

[Gunlaug Sørtun]

Susie Gardner-Brown wrote:
My ones work fine on my Mac in Firefox, but in IE (PC) they don't. 
I'm assuming that something is conflicting from the rest of my 
stylesheet, but I can't work out what. If anyone had any clues, I'd 
be very happy 



http://crunchie.tedi.uq.edu.au/trials/UIMED/Professionalism/standards1.html


Add a background to the link on :hover, and it will work in IE/win.
This will do...

div#content  li a:hover {background: #edb;}

...or use a background color that's closer to, but /not/ identical with
the existing a:link/a:visited background color.

The reason is that IE needs for something *to change* on that link-cell
itself on :hover in order to repaint it and open up for the span.

Georg
--
http://www.gunlaug.no


**
The discussion list for  http://webstandardsgroup.org/

See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list & getting help
**