Re: [WSG] Problem with Navigation in IE 6
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] Problem with Navigation in IE 6
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.communitymx.com/content/article.cfm?page=2cid=C37E0 -- 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?
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] Accessibility - display: none v.s. left: -9999px
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: http://www.gunlaug.no/contents/wd_chaos_14.html 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
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... http://www.gunlaug.no/contents/wd_additions_14.html ...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: Conditional Comments Bad? - was: Re: [WSG] CSS calling methods survey
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... http://www.gunlaug.no/contents/wd_additions_12.html ...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... http://imfo.ru/csstest/css_hacks/import.php ...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
Barney Carroll wrote: link? style @import? Which do you use, for what, and why? In document: 'link' with relative path. I use 'style' for adding page-specific, and often media-dependent, styles, but do not use @import in documents. - All browsers understand 'link', and some don't understand anything else. - I do not separate browsers on this level. In stylesheets: I use @import to group together a (small) number of stylesheets for a specific layout. - Saves me from having to copy/paste together well-working bits and pieces every time I create a new layout. - Makes it easy to filter/separate browsers on CSS level. - Makes it easy to separate media on CSS level. - I'm lazy ;-) 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
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'... http://www.gunlaug.no/contents/wd_additions_12.html 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] Targeting specific images with overflow:hidden
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 ;)
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?
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
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.
http://www.w3.org/TR/CSS21/selector.html#link-pseudo-classes
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
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] Listamatic Centred horizontal list navbars not working
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...
http://css.maxdesign.com.au/listamatic/horizontal27.htm
...you can add...
#navcontainer ul li a {margin-right: -.2em;}
...and on...
http://css.maxdesign.com.au/listamatic/horizontal16.htm
#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] Firefox stops rendering background when changing .html to .xhtml
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: http://www.gunlaug.no/contents/wd_1_06_03.html 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: http://www.gunlaug.no/contents/wd_1_06_03.xhtml Browsers can tell you what they are being served. In Firefox check 'Tools -- Page Info'. For IE/win, read here... http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_a.asp 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
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...
http://css.maxdesign.com.au/listamatic/horizontal27.htm
...you can add...
#navcontainer ul li a {margin-right: -.2em;}
...and on...
http://css.maxdesign.com.au/listamatic/horizontal16.htm
#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
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... http://www.gunlaug.no/tos/alien/skat-logo.jpg ...regardless of how many pages they had to copy it into :-D http://www.bt.dk/article/20061227/NYHEDER/612270315SearchID=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
Dwain Alford wrote:
1. the menu operates as expected, except that only on the index page
is the sub-li 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)
[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
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] Last letter of a line appearing on next row (IE6...)
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
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?
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] what's causing ie7 to ignore the valid div rules?
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] ie7 does not render page properly
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
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
Tee G. Peng wrote: Example: http://www.gunlaug.no/tos/moa_11.html 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
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
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: http://www.gunlaug.no/tos/moa_11.html ...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)
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] IE Issues (margin/padding)
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...
http://www.gunlaug.no/contents/wd_demo_float_03.html
...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] Forget about Opera and Mac (and Windows Vista) ??
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] a new IE bug? maybe not
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
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
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 p in li
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
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] help with layout postioning
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] Max-width issues
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: http://www.gunlaug.no/contents/wd_additions_14.html 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: http://www.gunlaug.no/contents/wd_1_02_01.html#item2 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
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
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
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
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... http://www.gunlaug.no/contents/toc_7a.html ...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... http://www.w3.org/TR/relations.html 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... http://www.w3.org/Style/CSS/ 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... http://www.456bereastreet.com/archive/200609/css_frames_v2_fullheight/ 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
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]
***
[WSG] Re: [WD]: Rethinking Font Size 76%
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] Re: [WD]: Rethinking Font Size 76%
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] ***
Re: [WSG] XHTML Marquee
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] XHTML Marquee
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] Semantics - (was : class names and IDs (which was p:first-line))
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] p:first-line
Mathew Patterson wrote: You have probably heard this same argument in reference to using strong instead of b . 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 b may be depreciated as an element with purely visual meaning, it isn't deprecated - yet. If purely visual is all we want, then b is as meaningful - although not as versatile - as a span with a class-name. A meaningful element like strong, 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] Trouble with float layout (IE6 versus Firefox)
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] Navs at bottom of pages
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... http://www.gunlaug.no/contents/molly_1_18.html ...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] Navs at bottom of pages
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... http://www.w3.org/TR/relations.html http://www.w3.org/QA/Tips/use-links ...and have done so for a long time. You can turn on the 'navigation bar' in Opera - ToolsAppearanceToolbars... 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] IE7 RC1 oddity
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
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
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] IE Stops page load
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
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... http://www.gunlaug.no/contents/wd_additions_14.html 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... http://dean.edwards.name/IE7/intro/ Just simulating 'min width' is another matter, as it isn't difficult to prevent IE/win from collapsing. http://www.webreference.com/programming/min-width/ 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
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
Mark Harris wrote: p id=lennon imagine there's a heaven, I wonder if you can.../p ;-) 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
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'... http://www.positioniseverything.net/explorer/italicbug-ie.html 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
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=indexcPath=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]
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] correct markup for frames? : was [target=_blank]
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] IE7 standards support very bad according to some
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
[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
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?
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... http://www.quirksmode.org/css/ie6_purecsspopups.html 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] Using Tables w/CSS
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... http://working.bushidodeep.com/table_layout/2Col_layout.html ...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'... http://www.gunlaug.no/tos/alien/test_5400.html ...or served as 'application/xhtml+xml'... http://www.gunlaug.no/tos/alien/test_5400.xhtml 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] Using Tables w/CSS
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... http://www.w3.org/International/articles/serving-xhtml/#quirks Myself, I usually keep IE6 in 'quirks mode'... http://www.gunlaug.no/contents/wd_additions_16.html ...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] Support for IE5/Mac? (was Browser stats)
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] Opera Bug? (Table-displayed, left-floated, min-width content)
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] Site help needed please ... I can't see what i've got wrong
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] table display values - how to
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'...
http://www.w3.org/TR/CSS21/tables.html
Example of a 'CSS table' layout - with 'simulated look' in IE/win.
http://www.gunlaug.no/tos/moa_11.html
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'...
http://www.gunlaug.no/contents/wd_example_01.html
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] w3c inspecting icon factory
[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
Also, in happy times when multiple background images are commonly supported getting rid of one script... 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... http://www.gunlaug.no/homesite/main_6_xv.html ...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] Rounded Corners
Paul Novitski wrote: http://www.gunlaug.no/homesite/main_6_xv.html 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... div class=rob1 rc h4 class=area-br-left19Easy borders/h4 /div ...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... div class=rob1 rc div!-- 7 generated divs here - each with a class --/div div!-- 1 generated wrapper-div -- div!-- 1 generated wrapper-div -- h4Some headline/h4 psome text./p img / psome more text./p /div /div div!-- 7 generated divs here - each with a class --/div /div ...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... http://www.gunlaug.no/index.html ...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
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... http://www.gunlaug.no/homesite/main_6_xv.html ...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] are transitional doctypes quickmode
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: http://gutfeldt.ch/matthias/articles/doctypeswitch/table.html 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
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: http://www.gunlaug.no/contents/wd_additions_13.html
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] Meyer's CSS text popups not working in IE (PC)
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 grin
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
**
Re: [WSG] Meyer's CSS text popups not working in IE (PC)
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 a 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] Thanks Georg, but Mike ... re Meyer's CSS AND ... :)
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 grin 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... http://www.quirksmode.org/css/ie6_purecsspopups.html http://www.tanfa.co.uk/css/articles/pure-css-popups-bug.asp 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] html validation: exactly what is it good for?
Shlomi Asaf wrote: If i open the site and see that it works on my target browsers, why i need the validation for? what do i benefit from it? Well, since you started out with an example of malformed and non-valid xhtml Strict (1.0, I guess/hope), then the answer is simple: if it isn't valid then it isn't xhtml, so at least call it something else. Christian Montoya wrote: - If you serve an XHTML doctype as text/html, well, don't. I can't see why not ;-) ...as long as it also works if/when served as 'application/xhtml+xml'. This means it /has to be/ wellformed and valid - regardless of what /any/ browser makes out of it when getting it served as 'text/html'. - If you serve an XHTML doctype as application/xhtml+xml, then your question would be, why doesn't my page display at all? And the answer would be, validate. Indeed. So if someone intentionally wants to allow for a bit of freedom and some non-valid markup, then they should stay away from xhtml. My own input: http://www.gunlaug.no/contents/wd_1_06_03.html ...and I'm writing xhtml all the time :-) Shlomi Asaf wrote: i refuse to take for grentet everything been told to me. I follow you there :-) There's a lot of weak reasoning around for just about everything in web design - including validation. You yourself linked to one of the best, and strongest, sources... http://www.cs.tut.fi/~jkorpela/html/validation.html It’s useful to write valid markup, in most cases. But it’s hardly useful to make a noise about it. ...I couldn't agree more. i try to look at the positive and negative sided and costs of my webDesign. Writing correct markup is useful - without any known negatives, and there's no known cost related to validation that I know of. Note that correct markup is valid - in most cases, but valid markup doesn't necessarily have to be correct or result in anything useful. I think we have all seen valid markup that looks like, and results in, a complete mess. Thus, validation is just a small step - a check-point - along the road to write correct markup that won't rely on error-recovery and browser-dependent guesswork. Myself, I prefer to avoid spending time, and money, on figuring out all the variables in error-recovery and browser-dependent guesswork, so I find the validator to be a useful tool. I even use it at times, if/when I'm in doubt about something I want to put in my markup. I don't make a lot of noise about the validity of my markup though. 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] A seismic shift in browser usage for me ....
Michael Kear wrote: [...] Now I know that these figures only represent my own audience, and IE is still the most used browser by quite a long chalk, but it does signify a shift of quite large proportions in my traffic. Ever had a quality-check on those figures? I'm not saying your figures are wrong, but as always when I see such figures; I wonder how they are retrieved and if the differences in how UAs engage a site is taken into account. See: http://virtuelvis.com/archives/2005/05/statistics-nonsense ...for more on statistics. Had I not taken a decision a couple of years ago to design for standards first, then to adjust for IE later, i'd be scrambling now to redo a lot of my sites. That decision has saved you a lot of work already, so it sure was a good one. No longer can I say well the vast majority of the users have IE and the rest are basically insignificant.And i suspect the same is true for a great many web sites owners. You're probably right, but that ...users have IE... argument never was a valid argument anyway. Browser-support shouldn't be based on numbers, but on each browser's capability. See: http://www.gunlaug.no/contents/wd_1_02_02.html ...for more on site-specific browser-support. 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] A seismic shift in browser usage for me ....
Michael Kear wrote: In fact, that's what I explicitly stated in my post. [...] And I agreed with you on that, and your decision to go standard. I was just trying to figure out if you had a sound base for making/checking that decision, as figures derived from statistics, IMO, is not a good base for anything - not even when it relates directly/only to a single site. Nowdays, it makes sense to build for a compliant browser, such as Firefox, and then make hacks and allowances for IE's foibles. Sure does - apart from the fact that every single browser has bugs and flaws and shouldn't be relied upon as design-base. Using /a number of/ standard compliant browsers as design-base, and cross-checking with standards when hitting inconsistencies, is somewhat more reliable. Once that turns out well, we can add a bit of help to IE6. What I believe the trend is indicating that in the not-too-distant future, we'll be able to say build for standards and leave it at that. IE6 users are on their own - it's not worth the additional cost to provide for them. That day will be a good one indeed. Indeed :-) However, given the fact that IE won't disappear all that fast since it's the last version to work across window-versions, that not-to-distant future may have to wait quite a bit. 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] Mystery Gap in IE
White Ash wrote:
Essentially, I need to be able to manually have text, forms, etc.
wrap below the image on the left in the #content div. Any light to
shed on this would be greatly appreciated.
http://rortax.com/quorum.shtml
Ok, the 'position: relative' on the paragraph in that particular layout
doesn't work well because the paragraph will then be stacked on top of
everything else.
So, let's move on to the containing-element.
Adding...
#content {zoom: 1;}
...does work in IE/win without any side-effects in other browsers.
Since 'zoom' is a non-standard MSIE property, I suggest you try the
following addition instead...
#content {height: 100%;}
...which will also work without negative side-effects in other browsers.
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] 3 column liquid, source ordered
Darren Wood wrote: I've been trying to find/develop a nicely source ordered 3 column liquid layout...with the right and left columns a fixed width. I'm not having much luck. I couldn't even find an example on the css-list wiki :( Think there has been one listen in the css-d wiki for quite a while. If anyone has achieved this or knows where I can find a working example I'd be most chuffed! :-) My cat has been using one that fits your description, for a long time... http://www.gunlaug.no/contents/molly_1_18.html ...and think it is great for expressing her opinions ;-) Since my cat's preferred source-code is a bit heavy - it is basically an overdone 'negative margin' layout... http://www.alistapart.com/articles/negativemargins/ 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] OT - but really need help
Cole Kuryakin wrote: So, so-far, IE CC is the way I'll go unless someone can say: Hey Cole, this is what you're doing wrong with your css. Do ***this*** and it'll be fixed without the need to use IE CC :-) I just did. Covering up for one of IE's many whitespace bugs is *not* necessary, when you can make the whitespace bug go away. 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] Web site images question
David Dixon wrote: [...] It would be useful to get a few more opinions on what others believe the purpose is... The purpose of 'text' in the alt-attribute it to expand/complete the meaning - in context, (as close to) the same as the visible image itself does. Describing the image is not what the alt-attribute is there for. An image may tell a story, and/or strengthen (parts of) the surrounding content. The alt-text should (ideally speaking) do the same - or be left out. Whatever one puts in that alt-attribute should make optimal sense - in context. If it doesn't, then an alt= is to be preferred in nearly all cases. --- The 'graphical' version should not influence or cross-contaminate the 'text-only' version of a page at the User end. Few 'text-only' Users can, or do, compare. The 'text-only' version should carry _all_ that is relevant - and not much else, while the 'graphical' may provide space for all the relevant, less-relevant and/or non-relevant visual cues one may want to put in. --- Images can, and often do, add value - when visible, as visual cues along with text works well - visually. Text - followed by an image - followed by more text, may work well in most cases - for those of us who can see it all and scan in all directions. --- Providing loss-less alternatives inside alt-attributes is impossible for most images. Providing short alternatives in context is somewhat easier, but most often not necessary, or useful. Very often the only logical alt-text for an image is a repetition, or rewrite, of what's already in the text. Such a logical but repetitive alt-text doesn't add anything of value. Repetitive, rewritten or 'out of context' text adds noise, so it makes little or no sense to have any alt-text. Text - followed by a rewrite of the same or 'an out of context' text (disguised as an accessibility-improving alt-attribute) - followed by more (of the same) text, rarely ever make much sense. 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] Jello variation
http://66.155.251.18/mlinc.com/test/index2.html Designer wrote: How strange - it fits on mine down to 800 by 600, but if I have the font-size set at anything but 'smallest', it doesn't! And once it's 'gone wrong it's hard to get it right again! I'm talking about IE6/winXP, viewed via the 'view in IE' tool in Firefox. There's a screen grab here: [1] http://www.marscovista.fsnet.co.uk/kernow/tom-1.gif Fine in FF, naturally! Am I cracking up? Probably :-) That's the result of using that particular expression in that particular way, as it takes over once it has kicked in. The logic behind the use of an expression to fix IE's lack of 'max-width' when dealing with 'em-width' scaled layouts, should be reversed - like in this test/demo-example... http://www.gunlaug.no/tos/moa_12a.html ...that only has a minor glitch in IE5.0, 5.5, since I haven't bothered to compensate for the effect of a few px border-width in the 'Quirks mode' vs. 'Strict mode' box model. Part of the problem, /and/ solution, is that we need to extract the IE-user's own font-size preference/default, so everything one has learned about font-sizing from body up, has to be left out for the correct logic to work. Not really a problem ;-) 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] Jello variation
Tom Livingston wrote: In IE6, when the page approaches it's intended max-width, there is a weird jump in the width. A minor thing, but would like to fix it if possible. Got any ideas? http://66.155.251.18/mlinc.com/test/index2.html Looks like the old, unreliable, quirks mode expression, and IE6 is in standard mode. You'll have to tweak the expression a bit for IE6, or run it in quirks mode. You may also try my 'dual mode' min/max expression, but my layout takes a different approach towards scaling... http://www.gunlaug.no/tos/moa_12a.html 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] Jello variation
Tom Livingston wrote: Can't recall how to switch it to quirks mode... !-- keep IE in quirks mode -- !DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01//EN http://www.w3.org/TR/html4/strict.dtd; html That comment will keep IE6, and also IE7, in quirks mode. Not a good thing to do IMO, but that's another matter :-) I prefer using an XHTML doctype in such cases, because I can do this... ?xml version=1.0 encoding=utf-8? !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd; ...without throwing IE7 back in time unless I want to. 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] Multiple stylesheets
Paul Bennett wrote: I recall many moons ago a site which had multiple stylesheets (using the link element). In Firefox, a small icon appeared at the bottom pane of the browser and allowed the user to switch between stylesheets. Can anyone point me to a site that uses this technique? I'd like to do a bit of research... I swap and combine more than a dozen alternative stylesheets on my own site... http://www.gunlaug.no ...including for languages. Gecko isn't always too happy about my select-dropdown construction. Opera, IE/win and Safari reacts just fine. Script-solution works well across browser-land... http://www.howtocreate.co.uk/jslibs/htmlhigh/swapstyle.html ...and is probably among the most versatile solutions one can find. 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] Accessibility standards - for commercial consumption
Am I alone in thinking that it's disgraceful that, after years of development, WCAG 2.0 still needs the effort of the community to be made understandable? No. Are WAI fulfilling their mandate by making the guidelines so dense and obscure that they need translation? Not unless that is part of their mandate. One can cover just about everything that way, so maybe it is... Now, reading the drafted guidelines on their own isn't too hard, but transferring them into a successful composite of all standards seems to limit our options a lot. I can't find much room for standard-based progress in there. 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] Accessibility standards - for commercial consumption
Patrick H. Lauke wrote: From their mission statement: WAI develops support materials to help understand and implement Web accessibility http://www.w3.org/WAI/about-links.html And from the requirements of WCAG 2 Design deliverables with ease of use in mind http://www.w3.org/TR/wcag2-req/ So I think they're falling a bit behind on both accounts here... Agreed. What seems to be the problem so far, is the lack of this: 4. Write to a more diverse audience WCAG 2.0 deliverables must address the needs of a variety of readers, including people who wish to: - Create accessible, innovative Web sites. ...[etc]... http://www.w3.org/TR/wcag2-req/ One can hardly say their deliverables are anywhere near to fulfilling that point, since most of us have problems sorting out what we need and how to implement it - mostly because of the language used. OTOH: it's just a draft, and they may actually have a, somewhat flawed, expectation that those who want to 'create accessible, innovative Web sites' are already mastering the language they use to perfection. One can find several indications on the W3C site pointing towards the need for a certain type of correct language in their documentation, in order to avoid misinterpretation. I generally have no problems with that, but it doesn't always meet the needs of 'a variety of readers'. I am slightly against simplification as a mean to improve access, because there's always the risk of oversimplification and loss of meaning. However, the draft we have now sure could do with some language-simplification in order to meet the average reader's needs. As mentioned in an earlier thread: Maybe someone in the right group(s) can improve on the wording before the final arrives, ... If they can't do it themselves then someone else may have to - and do it well, as there's enough confusion spread around the web about what the different Web standards actually say. 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] new site critique - extemely
its just that for 10 years there is nothing that moves regading screen sizes and accesability have to follow the smallest standard size in order to not be refused by visitors. I can't see why, since we can make our designs adapt to available space. We just have to design them that way. I dont think it work like that any longer, and HEY people need to buy screens and upgrade for god sake!!! My 3840 wide screen-view/resolution is wide enough for most sites to fit in, but I design the base for the more average 640 - 1280 window-width. Then I go back and evaluate those same designs for 170 - 600 window-width, so I can keep up with the progress in 'small screen rendering'. There are so many people who buy those small screen devices these days, and I don't want to be left behind :-) Do you all think im wrong... should we all drive around in a VW beetle 1963 because the roads in some countries on this planet arent good enough to drive with a LADA??? some roads will never even be used but they are still on the map!! refffer that to people that will never use their cars as computers never will be boughtNow you might got my point... Yeah, but I prefer an off-road convertible so I can drive where I want whenever I want. And, of course, there are a few more vehicles around - just in case. The same with web designs and screens and window-width... as a convertible site can get get further. Some solutions are of course created for special purposes - just in case. As a former software/hardware developer: I also had to develop for users/clients wants and needs back then - or else it wouldn't sell. There are not all that many more restrictions in web design - it just has to sell. 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] IE glitch
Tom Livingston wrote:
http://66.155.251.18/mlinc.com/test/index.html
Anyone see why the first line in the first paragraph, which is next
to left nav is pushed over a bit?
3px jog.
Add the usual 'hasLayout' trigger...
* html #content{height: 100%;}
...that'll make it look right in IE - even if it isn't :-)
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] Floats not working right in IE6 - can you help me find out why?
Michael Kear wrote:
The content of the page is flowing around the menu (which is inside
the content div and floated left) in Firefox, but isn't flowing in
IE.
So see what I mean, go to http://incheckdb.com
http://incheckdb.com/ The Around the site box at the bottom
should be almost touching the left side underneath the main nav menu
(and it does in Firefox) but doesn't.
http://incheckdb.com http://incheckdb.com/
Adding...
#content {height: auto!important;}
...solves it, so it looks like you have given a 'hasLayout'[1] trigger
to that container, and _it_ is causing the problem in IE. Overriding or
deleting that trigger will make IE behave like the other browsers.
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
**
[WSG] CSS is dead... use markup for presentation.
sarcastic pony Looks like most efforts towards separation of content and presentation may cause severe accessibility-failures[1] in the future. Looks like there will be no need/use for valid markup either - according to the latest WGAC 2.0 draft. Ref: article on ALA[2]. Time to go back to presentational markup - before some /body/ at W3C forces us into doing so? :-) /sarcastic pony Oh, well... it looks like all those W3C /bodies/ are pretty busy trying to make each other, and standard-based web design, irrelevant. Which parts/paths do you think we should choose to follow? Seriously Georg [1]http://www.w3.org/TR/WCAG20-TECHS/#F1 [2]http://www.alistapart.com/articles/tohellwithwcag2 -- 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 **
