Re: [WSG] Free CSS Editor Recomendations?
Artemis wrote: I was wondering if the professionals in here can recommend any free CSS Editors that might possibly be geared towards a newbie to CSS. There are quite a few free CSS and markup editors (including some for Mac) listed on the css-d mailing list wiki -- http://css-discuss.incutio.com/?page=CssEditors -- Best regards, Michael Wilson ** 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] CSS Driven?
Thomas Livingston wrote: The whole basis to my point is that in our little virtual situation, it's too late. The client saw the design. the client wants the design he saw. If you could only do it with a table, you'd say no and/or walk. Just or the record, / I / wouldn't walk; I'd do what I had to do. This decision, of course, is based on certain prerequisites: 1: The design is, in point of fact, / im-friggin-possible / to archive without tables (something I've yet to encounter and find highly unlikely). 2: I've confirmed this fact by having someone, more skilled than myself, take a stab at the layout. I'd just use the table. I wish I didn't have too. I wouldn't _want to_, but in that exact situation, my superiors would not back me up in turning down the client/project because I was gonna have to use a table. And you'd be correct in your decision. If the layout is not achievable without the use of tables, what choice do you have? Personally though, I try to make sure everything I design can be worked out using CSS. I don't paint myself into a corner, so to speak, unless the client leaves me with no alternative. There are always exceptions to the rule, of course. -- Best regards, Michael Wilson ** 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] Browser Resolutions
Jan Brasna wrote: I asked for people to get first-hand data is because it tends to be more reliable. Well, as someone smart said - you have to look at your own data to pick an appropriate solution. Other's data may not neccessarily fit your audience. Hi, I agree, but still it's interesting. I was surprised to see (in the data Brian posted) so few users at a 1280 x 960 setting. We have a large percentage who use this (I suppose because it is a 3:4 resolution). -- Best regards, Michael Wilson ** 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] Browser Resolutions
Brian Cummiskey wrote: Brian posted) so few users at a 1280 x 960 setting. We have a large percentage who use this (I suppose because it is a 3:4 resolution). Isn't 1280x960 mostly on laptops? i don't even have that option on my machine (basic intel built in graphics card) I have 1280x960 available on both of my desktops... one is an ATI 9700Pro and the other a GeForce 6500. And the above should have been 4:3 not 3:4 (I think someone else already caught my goof). 640x480, 800x600, 1024x768, and 1280x960 are all 4:3 ratios I believe. Some of this weird stuff on laptops of recent is really annoying. My CEO is constantly asking why everything looks out of whack on his... -- Best regards, Michael Wilson ** 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] Pipe separated lists (was: CSS foul-up in IE)
Geoff Pack wrote: As for lists, the pipe separated menu list is perfectly clear to most people. What is missing is a clean way to mark it up with HTML. You could use an unordered list, styled inline, but that is overkill in many cases, and not an useable if you want the list to be inline when styles are missing or turned off. Hi, I don't think anyone is arguing whether or not pipe separators are /visually/ clear in meaning--they, of course, are. When I see them, I know exactly what they mean; generally a separator for inline list items: Banana | Apple | Orange | If, however, I see them in an unstyled list (browser default for example), they carry much less meaning visually: * Banana | * Apple | * Orange | The items are already clearly delineated by the UA and the persistence of the pipes adds no semantic meaning--I don't even think it /looks/ proper at this point, but I digress. In either instance pipe separators have little to no meaning outside of a visual context, which by nature makes them presentational. As such it only makes good sense to leverage CSS, either through the use of background images or borders, to present this visual usability enhancement. I will continue to use visual cues like these myself, but will do so as semantically as possible. -- Best regards, Michael Wilson ** 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] Pipe separated lists (was: CSS foul-up in IE)
Geoff Pack wrote: Joshua Street wrote: Can you possibly ditch the un-semantic pipe separators (|) Are the pipe separators really un-semantic? They have a long history of being used in navigation menus, and definitely have meaning. They may be redundant here given that the grandparent marked up the menu as a list, but not un-semantic. I've come to believe pipe separators are non semantic in that they only provide presentational meaning. Technically speaking, adding a pipe to a list item makes the pipe /part of/ the list item rather than a type of semantic delineation. UA's (most if not all) already provide default delineation that clearly defines each list item. Any additional type of visual separation, is purely presentational and is probably best dealt with via CSS. -- Best regards, Michael Wilson ** 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] Casual Friday[Drop-Down Menus]
Chris Kennon wrote: I've adopted the philosophy, drop down menus are a surrogate for detailed Information Architecture. Sub-navigation should be introduced on internal pages to navigate sub-sections. Before passing this along to clients as mantra, I thought seeking the advice of the participants of the list advantageous. Hi, I've used drop down menus on many sites, but in the end I've always wished I hadn't. I no longer use them. They /can/ be useful for return visitors who are familiar with the content of your site because fewer clicks are required to get to specific content, but for first time users or users who are less attentive, they tend to be less productive. Users tend to spend more time searching menus and making guesses, than it would take to simply click through an intuitive top-level navigation. I also prefer a top-level only type navigation because it gives me more opportunities to present content and information to the user. A drop down menu such as the following: Solutions solution 1 solution 2 solution 3 solution 4 is generally less effective and informative than a top level link that leads to a topic page that provides a brief overview of each solution. This is a better overall value for the organization, more informative to the user, and more effective for search engine optimization. As for screen clutter, I haven't found drop down menus to very helpful in this regard either. Generally, the links usually contained in the sub-navigation of a drop down are represented on the topic page as contextual navigation, essentially accomplishing the same clutter control as a drop down menu might. I can't really think of any good reason to use a drop down menu other than a /possible/ reduction in clicks for the user. Best regards, Michael Wilson ** 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] Set min-width using DOM
Al Sparber wrote: Conditional comments only validate in the sense that the validator doesn't recognise them as anything other than comments and hence ignores the content. So, your page will validate against automated checking, but technically you are using invalid code That's a real stretch :-) How about the typical parsing bugs that CSS geeks tend to use - are those better because they eek through da Validator even though they leverage programming bugs in browsers? Howdy, I don't disagree with you often, but I do in this case. I don't see his view as a stretch at all; I think he is bang on. Conditional comments, which I do prefer to the more often used hacks, are not part of any standard, which makes them invalid markup by nature. There is no way to argue that point validation or otherwise. Some hacks that leverage programming bugs in browsers are opportunistic (and perhaps overly optimistic), but they remain valid CSS. Using this method could *possibly* cause problems with browsers of the future, but then again, so could conditional comments. Also, some developers ritually abuse conditional comments by adding invalid CSS or expressions to their IE style sheets because they know the validator won't catch them. True CSS geeks make sure all of their CSS validates; not just the stuff the validator can see. Conditional Comments are a clean and safe way to address IE Windows issues. Those who use them, who have used them, will have minimal or no issues once IE7 is released. You can bank on that. I agree: CC's are /currently/ the cleanest and safest way to deal with IE Win issues, but they are not infallible or 100% future proof. Allot depends on factors we probably haven't even considered yet. For example, (and this really might be a stretch :))there are allot of folks who have fixed an across the board IE issue by isolating specific CSS to all versions of IE using just !--[if IE]. In this case, if IE 7 (assuming whatever bug I was using the CC's to hack has been fixed) gets the primary CSS right, but is still being fed the alternate style sheet, I'd have to go back and break that CSS out somehow or change the expression in my CC's. Depending on how things are set up, that could be allot of work in its own right. In the same scenario as above, if I used the * html hack to achieve my goal and IE 7 doesn't recognize * html (I believe that is the rumor), then I have to change nothing--all should continue to work and be happy. The truth (at least my version of it :)) is, I can't bank on anything yet and I won't know how things are going to actually play out until I have a browser in which to test them. For the most part though, I do believe those of us using CC's will encounter fewer issues. Best regards, Michael Wilson ** 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] Homepage Review: webnetdesignstudios.com
Hi,
I haven't followed this thread completely, but I wanted to comment on
this specific post because some of your comments caught my eye and
another view may come in handy.
However, I think using strong to emphasize the author of the
testimonial is perfectly acceptable.
Because it's not going to bring about the total destruction of mankind,
you are more right than not in the world of living and breathing, but in
the world of standards, it's not acceptable and it's wrong. You might as
well use a hn to ad visual emphasis. You are attempting to visually
draw the readers eye to the name (e.g. bold), not necessarily add a
strong emphasis. If it is visual, it presentation. If it's presentation,
it's not structure.
To create a rule and use span tag is overkill.
I totally agree and, generally, I try not to use spans. Instead I mark
up my document in such a way, limited as they are, the tags are as
semantic as possible, while at the same time, provide me with hooks into
my content without redundancy.
Someone (Josh I suppose) suggested that you use a span for the
testimonial, and while that is allot better (semantically speaking) than
what you are doing now, it wouldn't have been my first choice. I would
use a definition list for this:
dl id=testimonial
dtJoe Coyle, President, www.coylemedical.com/dt
ddMr. Cisneros and his team have an extraordinary talent for customer
communication, market vision, and web page design./dd
dl
And, if you absolutely have to have the commenter's name appear
*visually* beneath their comments, you could use the following (or
similar) CSS:
#testimonial * {
margin: 0;
padding: 0;
}
#testimonial {
width: 400px;
}
#testimonial dt {
margin-top: 80px;
}
#testimonial dd {
float: left;
margin-top: -80px;
}
Of course, you would have to tweak this (margins) per instance and it's
not thoroughly tested, but should work OK in most browsers.
Additionally, the image is to provide a soft visual touch
There is also nothing stopping you from displaying the little person
image as a background on your dt, but you certainly shouldn't be using
an inline image as it is purely presentational and adds nothing to the
content. If it were a photograph of the speaker, I would use the image
within an additional dd.
Similarly the images in your header could be a replaced h1. There are
various methods available to you; most have drawbacks, all are better
than in a non-semantic, inline image.
In terms of how you display an image on the page the rule is simple: If
the is content (as in the speaker photograph in the above example), it
should be in the markup; otherwise, it should not.
I realize the importance of clean, well-written code and content,
but the Internet is also a visual medium.
Ahh, but it is not a visual medium. It is an electronic medium, of
which, some clients such as Web browsers like Firefox and Internet
Explorer can display visual presentation. Not all clients can do so
(screen readers for example) and users can force those that can, to not.
Paper is a visual medium. You can control all of it down to the glossy
UV coating, font size, image placement, and texture. You cannot control
my browser:
CSS off, images, off, font size increased:
http://961media.com/__temp/webnetdesignstudios-1.png
Images off, font size increased:
http://961media.com/__temp/webnetdesignstudios-2.png
I don't agree that every horizontal navbar should be in a list
especially since display:inline isn't supported in IE5, but that's a
personal preference.
There is really no such thing as personal preference when you are
dealing with a standard of any kind. There is the standard and then
there is all the other stuff; follow it or don't. There is allot of gray
in the standard of course, but a list is a list and how IE 5 deals with
your preferred CSS is not a deciding factor.
All of this aside, IE 5 handles horizontal navs derived from lists just
fine:
http://web-graphics.com/mtarchive/inline-mini-tabs.html
Most of the advice you will receive here is very sound and if you want
to learn more about standards design, you'd be wise to heed it. It is
difficult at times, but it's worth it. The first step, though, is
unlearning everything you though was acceptable.
--
Best regards,
M. Wilson
**
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] Homepage Review: webnetdesignstudios.com
Paul Bennett wrote: dl id=testimonial dtJoe Coyle, President, www.coylemedical.com/dt ddMr. Cisneros and his team have an extraordinary talent for customer communication, market vision, and web pageb design./dd dl There seems to be a tendency lately to use definition lists for way more than I think they're supposed to be used for. I've found a couple of descriptions of what a definition list is supposed to be: http://www.w3.org/TR/REC-html40/struct/lists.html#h-10.3 Definition lists vary only slightly from other types of lists in that list items consist of two parts: a term and a description. The term is given by the DT element and is restricted to inline content. The description is given with a DD element that contains block-level content. and http://www.w3.org/TR/html4/struct/lists.html Definition lists, created using the DL element, generally consist of a series of term/definition pairs (although definition lists may have other applications). Thus, when advertising a product, one might use a definition list: I think the some of the confusion stems from the naming and the description of the list type and the list items. In the first example the spec states: list items consist of two parts: a term and a description In the second: (list items) generally consist of a series of term/definition pairs The second description continues with: although definition lists may have other applications What are these other applications? The spec doesn't specifically state, but it does offer the following as an examples: Another application of DL, for example, is for marking up dialogues, with each DT naming a speaker, and each DD containing his or her words. and when advertising a product, one might use a definition list That is a vague and somewhat conflicting guide. The list type is dubbed definition, but at almost every turn, the specification leans more toward the idea of description. Defining a term and describing a term are completely separate concepts at the core, but the lines do blur a bit. If definition lists would have been called description lists, having the exact same specifications, we wouldn't be having this debate and the world would be a happy place. In the above example, is this (semantically) equivalent to saying that the definition of 'Joe Coyle, President, www' In the example I gave, I was following the speaker-dialog path--describing what the speaker said. The content is obviously more accurately described as a quote than a dialog, but that can easily be worked into the dd to add even more semantic meaning. The bottom line is that we have to work with what we have been given, which is not allot, so do the best you can. -- Best regards, M. Wilson ** 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] IFR- what is the latest version?
Drake, Ted C. wrote: Hi All I have a quick question. I am looking for the latest version of using flash to replace header text. Is this the best approach? My feeble mind remembers an improved version out there in standardista-space. http://www.shauninman.com/plete/2004/04/ifr-revisited-and-revised You might be looking for sIFR (Scalable Inman Flash Replacement). http://www.mikeindustries.com/sifr/ -- Best regards, Michael Wilson ** 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] Specifying Web Standards and Accessibility Requirements
David Nicol wrote: 1. Has anyone else created a document of this nature and, if so, would they be willing to share it? Hi, Roger Johansson, of 456 Berea Street, put together a guide he calls Developing With Web Standards: Recommendations and best practices [01]. It's not as detailed as an official coding guideline spec (addressing items like code commenting, class ID naming conventions, and CSS organization), but it does provide an excellent view of standards development and some good examples of semantic markup. This would likely be a good starting point for any spec you put together. [01] http://www.456bereastreet.com/lab/developing_with_web_standards/ -- Best regards, Michael Wilson ** 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 stanards detection - is it possible?
Sam Sherlock wrote: Basic Splash Page that degrades... directing the user to a site more suited to them... a list of known bad browsers and they get put... Since this is a music media site the main user base are expecting glitz n glamour, bells n whisltes a plenty. Not giving them this is against the wishes of the site owner. Did we just hit some kind of crazy-ass time warping worm-hole that landed us in 1995? Splash page... best viewed with... click here if you use... Is this Sliders? I thought they canceled that show. I'd say the only question here is: to standardize or not. I certainly would *not* be trying to figure out how many sites I need to build. I already know the answer to that question: One. If your contract has some kind of thou shalt not abandon 4.0 browsers clause, then you'll have to do what you will to support that requirement. This route may include design and feature constraints or degradation in older browsers and it may include non-standard coding to support older browsers, but there is no way I would build additional sites, unless I was being paid -- fully -- for each. -- Best regards, Michael Wilson ** 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 - lastminute.com
Felix Miata wrote: You might say but the text looks too big if I just leave it like that. Make it smaller then. But *in your browser*. How would you recommend solving the problem? Hi, Font sizing issues are always a heated topic. If we have to get right down to the nitty-gritty of the matter, Felix is absolutely correct--the user's font size should be the default and the designer should not attempt to override that setting. The only way to ensure this happens is to make our font-size: 100%; and let it ride... aesthetics be damned. On the other hand, and in real world situations, expecting too much from our users always proves unwise. Giving users options and users actually being capable of taking advantage of or understanding those options are separate issues. I'd bet I don't know a single non-techie person, with normal vision, that can tell me if it is possible to, and if it is possible how to, change the default font settings in their browser. Font-size is just not an issue people with normal vision concern themselves with. A 80% (I use 76% on the body and 1.0em on my container) font-size is, generally, more than sufficient for online readability for the majority of users. Individuals with vision problems will no doubt disagree, however, because of their situation, those users have had to extend their knowledge of browsers and font sizing capabilities to compensate for the popular 12px fixed font sizing prevalent online. In most cases these users have already set a default font-size larger than normal and are aware of quick and simple ways to increase the font-size further when necessary. These users are also more likely to surf with browsers that are more flexible and customizable in the area of personal preferences and accessibility. Ideally, these users should not be required to do these things, but technology, like all other things in life, is rarely ideal. Because we live in this world and not the all things to all people world we would like, I've made the choice to reduce the default font-size of my pages to a setting the *majority* of users will find acceptable; all without requiring anything further from them--capable or not. Out of respect for those users who do not find those settings to be acceptable, I've ensured they have final control of font-sizing. I find this middle ground to be the most appropriate and flexible approach. Since adopting this method, I've not received a single complaint about readability and don't expect to going forward. Best regards, M. Wilson ** 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] Combination of CSS menu with dhtm/javascript menu button?
tee wrote: I have a horizontal menu done in CSS with set current option. menu 1 || menu 2 || menu 3 || menu 4 || menu 5 || menu 6 || but now my client wants to insert drop-down menu in menu 4 button. This can easily be done with DHTML menu that I have from Project Seven, but I really prefer to stay with css menu as it delivers cleaner code. Hi, PVII recently released Pop Menu Magic [01], which is CSS Text-based, Section 508 and WAI AAA conformant, but if you are after cleaner markup, *minimal JavaScript*, and simple CSS, it doesn't get much better than Sons of Suckerfish Dropdowns (SoS) [02]. The little bit of JavaScript used in SoS is only in place to help IE deal with non-anchor hovers and is extremely simple to work with; the rest is all standards based CSS and markup. Aside from being an overall cleaner solution, SoS isn't tied to any particular editor (Dreamweaver in this case), which also provides a bit more freedom and ease of maintenance. If, however, you like the animated style dropdowns, you'll likely have to stick with PVII. If you take the implementation of your navigation one step further and give your top-level navigation items (menu 4 for example) a home page that also provides the links found in the dropdown, IE users with JavaScript turned off can still easily navigate the site with only one additional click and users with JavaScript and CSS disabled get a standard list. Along with the links, you can also add link descriptions or other content to the pages that normally won't fit into a dropdown. I find this method far more intuitive and search engine friendly than a simple one or two word cue in a dropdown link and even if you still use dropdowns, it's beneficial. [01] http://www.projectseven.com/products/menusystems/pmm/ [02] http://www.htmldog.com/articles/suckerfish/dropdowns/ -- Best regards, Michael Wilson ** 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] Combination of CSS menu with dhtm/javascript menu button?
tee wrote: Thanks! Not trying to discredit the effort of SOS creator, but it doesn't work for IE 5.2 Mac, it's out of question. I don't think SoS not working in Mac IE 5.2 is a discredit even if you were trying. :) Personally, I've never given it too much thought. Regardless, if you use the method I outlined in the previous post, it degrades quite nicely or you can see this Mac IE 5 fix for more possibilities: http://simeons.net/suckerfish_ie5mac_fix.htm -- Best regards, Michael Wilson ** 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] Combination of CSS menu with dhtm/javascript menu button?
Thierry Koblentz wrote: tee wrote: doesn't work for IE 5.2 Mac, it's out of question. I believe it doesn't work in NN6 either. It works in NN6 Win, but I'm not sure about NN on Mac; that fix link I posted earlier has a listing of tested browsers. -- Best regards, M. Wilson ** 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] Combination of CSS menu with dhtm/javascript menu button?
Thierry Koblentz wrote: tee wrote: doesn't work for IE 5.2 Mac, it's out of question. I believe it doesn't work in NN6 either. It works in NN6 Win, but I'm not sure about NN on Mac; that fix link I posted earlier has a listing of tested browsers. -- Best regards, M. Wilson ** 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 extra space; background not showing up; odd links
White Ash wrote: p.s. cited: We all need to listen to the messages the universe has to send us: This page is not Valid XHTML 1.0 Transitional :) I am new to Web Standards. Two basic questions ~ could you share with me _how_ you know it is not valid, and also, _what_ I can do to make it valid? Most likely, the pages were checked with the W3C Validator. The Validator checks HTML documents for conformance to W3C HTML and XHTML Recommendations and other HTML standards. http://validator.w3.org/ http://www.amyarver.com/home.shtml http://validator.w3.org/check?verbose=1uri=http%3A//www.amyarver.com/home.shtml http://www.amyarver.com/aboutamy.shtml http://validator.w3.org/check?verbose=1uri=http%3A//www.amyarver.com/aboutamy.shtml The majority of your errors are easily fixed. For example, in your document you have: div id=nav lia href=home.shtmlhome/a/li lia href=aboutamy.shtmlaboutnbsp;amy/a/li ... /div You are missing either the stating ul or ol tags for your list: div id=nav ul lia href=home.shtmlhome/a/li lia href=aboutamy.shtmlaboutnbsp;amy/a/li ... /ul /div The non SGML character errors mean that you are using using characters such as (quote mark), or ' (apostrophe) within your displayed text. Some user agents may not be able to properly render these types of characters, so you should use SGML character references or entity references to display these characters. In addition to proper rendering, these types of symbols are also used within markup and may have a different meaning than when used in displayed text. For example, when using within displayed text, you would want to use the entity reference lt;, to be sure this character is not confused with the opening bracket of a HTML tag. You are already using some entity references in your navigation markup: nbsp; in used to represent a non breaking space character. http://www.w3.org/TR/REC-html40/charset.html HTH -- Best regards, Michael Wilson ** 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] Voice family box model hack
Stevio wrote:
Yeah but what does each of the following lines actually do?
height: 100%;
voice-family: \}\;
voice-family: inherit;
height: auto;
Hi,
height: 100%;:
This line sets the height for all browsers with CSS support.
voice-family: \}\;
voice-family:inherit;
Due to a CSS parsing bug in IE 5.x Windows and IE 6.0 Windows in quirks
mode (QM) doesn't understand these lines and stops processing this rule
here. Anything that following these lines will not be applied by the
affected browsers. These lines do not serve any other purpose other than
causing IE/Win to choke and to stop processing the rule.
height: auto;
Because IE win stops processing at the 'voice-family' lines, it does not
apply this line, but UAs which support CSS 2 (and the box model) will
read this line normally.
Most often, this hack is used to work around IE 5.x's broken box model
where the first width property provides a value for IE and the second
width value is for browsers that correctly implement the box model.
If I have to use a box model hack (BMH), rather than a conditional
comment, I prefer the following [01]:
foo { /* Selector recognized by all browsers with CSS support. */
height: auto
}
* html foo { /* Selector recognized by IE only */
height: 100%; /* Value for IE5.x/Win and IE6.x/Win QM */
hei\ght: auto; /* Value for IE6/Win */
}
If I don't care about support for Netscape 4, which chokes on escapes
(\) and ignores any style sheet that contains them, or Opera 5, which
completely ignores the rule, I use the following [02]:
foo {
height: auto;
\height: 100%;
hei\ght: auto;
}
Also, I am not clear on which browsers will end up using 100% height and
which will not break but not use 100%.
Visit Dithered [03] for a list of hacks and an overview of which
browsers are affected.
That MSDN article is quite interesting. Basically you can use those
Conditional Comments to add specific code anywhere in your page for IE5,
IE6, IE7 when it comes, and other browsers such as Firefox, Opera etc will
just ignore it all because the code appears commented out to them.
Correct, but one point that some folks miss is that types of conditional
comments can only be used inside of your markup; you cannot use a CC
inside linked style sheets. These are very useful for calling external
style sheets and although I use IE hacks in my CSS while in development,
I tend to move those hacks to individual style sheets and link to them
via CCs when I go into production--it's easier to maintain and it's cleaner.
This in turn makes it easier to develop code specifically to fix IE
problems. Why has that been such a well kept secret?
Conditional comments are a pretty well know and documented technique, so
I wouldn't exactly say it's a well kept secret. The CSS-Discuss Wiki
[04] is also a good place to find additional information on this and
other techniques you may not be familiar with.
[01] http://www.info.com.ph/~etan/w3pantheon/style/modifiedsbmh.html
[02] http://www.doxdesk.com/personal/posts/css/20020212-bmh.html
[03] http://www.dithered.com/css_filters/index.html
[04] http://css-discuss.incutio.com/?page=FrontPage
--
Best regards,
Michael Wilson
**
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] Voice family box model hack
Thierry Koblentz wrote:
Michael Wilson wrote:
If I have to use a box model hack (BMH), rather than a conditional
comment, I prefer the following [01]:
* html foo { /* Selector recognized by IE only */
height: 100%; /* Value for IE5.x/Win and IE6.x/Win QM */
hei\ght: auto; /* Value for IE6/Win */
}
I believe it is worth mentionning that IE5 Mac would also apply that second
declaration.
Hi,
Sorry about that Thierry; I was trying to keep things simple. In fact,
most modern browsers, or at least the ones that properly handle escapes,
will apply it.
http://www.dithered.com/css_filters/css_only/simplified_box_model.html
If for some reason you need to hide this rule from IE5 Mac, you could use
foo {
height: auto
}
/* Hide from IE-mac \*/
* html foo {
height: 100%;
hei\ght: auto;
}
/* End hide from IE-mac */
or if you just need to hide the escaped declaration...
foo {
height: auto
}
* html foo {
height: 100%;
}
/* Hide from IE-mac \*/
* html foo {
hei\ght: auto;
}
/* End hide from IE-mac */
I think... :)
--
Best regards,
Michael Wilson
**
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] IMAGE(was Mystical belief etc)
Collin Davis wrote: I think you misunderstand my point - I'm talking about a very small niche here - design sites where the only purpose is to showcase design - not to be accessible, not to have content, not for any other purpose than showcasing design. I don't think anyone missed your point. It's quite clear that you feel visually impaired--almost can't see nothing or just plain can't see nothing--people have no business concerning themselves with the creation of spaces, barrier-free design, surface stability, textures, *ADA Accessibility Guidelines for Buildings and Facilities* (doh), and safety. If they can't see it and say wow, then their needs must not be worth addressing. You might want to do some research on Universal Design and how designers and architects are working to make products and facilities usable by all people. I'm not saying that there aren't - but I do have insight into this very area. The company I work for does work for the worlds largest architectural and design firms. I can say that there is not one single blind or visually impaired person (and I use visually impaired in the since of can't hardly see anything sense, not in the wears glasses or is colorblind sense) working as either: a. a designer or b. anyone who has any control over design issues. I guess all the blind people who have homes built use a different firm, because they are definitely in control of design issues. You're looking at this from a works in the field perspective, while the majority of this list is going to be looking at it from the perspective of the end user. This is a prime example of a site and organization that attempts to accomplish it's own goals, rather than addressing the goals of its users. Of course, in the end, the designer and architect will still have to address every single usability and safety guideline set forth by the ADA. I'd think output/input from those people these design measures are meant to benefit, would be desired. I can see that you either haven't worked long in the architectural design field, or haven't worked there at all. Go look around at the majority of architectural firm sites - there's a common thread to the majority of them: 1. Flash and 2. Lots of interesting looking stuff, but scant content. Just because everyone else is doing something wrong does not mean you or anyone else has to follow the same path. Regardless of how long a person has been involved with architectural design, the ability to look beyond the common thread is what really defines greatness. Again, I think that you misunderstand the viewpoint I'm coming from - I'm not saying accessibility doesn't matter at all, ever. What I'm saying is that there are times when it doesn't, given the target audience and what the designer is trying to accomplish. The whole idea behind this group is to promote standards and accessibility online without exception, regardless of the type of content being offered. It's fine to give people with great eyesight some wow stuff to look at, but it's also important to give users with visual impairments alternative content. Accessibility always matters, because if it doesn't matter, then it means people don't always matter and that's just a plain ignorant concept. -- Best regards, M. Wilson ** 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 standards as a selling point?
potential clients. Hopefully the contributions made to this thread will change your view and help you address these important issues with your clients. -- Best regards, Michael Wilson ** 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 standards as a selling point?
Jonathan Bloy wrote: I like this approach and it is pretty much the one I take. I should mention that Web Design is more of a hobby for me. So, I've only had a few clients of my own. But I wonder about the need to go into detail with clients about web standards. Hi, I think you have to be able to read your clients to make this decision. Some clients need or want to be heavily involved in a project, while others just want the site up and running and they don't really care how you go about doing that. I think web standards are important to mention and if the client asks more about them you can certainly go into detail. But does your plumber or electrician go into long explanations about the standards they use when they're working for you? When I hire a professional I'm paying them to use their knowledge and expertise to choose the best standards that are right for the job, not to ask me what techniques I think they should use. Plumbers and electricians, are required by law to perform services to certain standards and to work within certain safety guidelines and regulations. Not doing so could jeopardize their business and lead to potential damage claims. Because my expertise in these areas is limited to turning on a light and taking a shower, I have to rely on the *credibility* of the professional I hire. Rather than research the techniques used to install a breaker box or fix a leaky pipe, I am forced to research the professionals reputation and rates and then make a decision based on that information--the task of which standard to use has already been established by persons far more qualified than myself. Unfortunately, the Web is a little less restrictive when it comes to technique and technique can vary greatly. -- Best regards, Michael Wilson ** 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] ID conflicts - span matters
tee wrote:
For example:
The first button link:
#siteOption #homeLink {
background: url(images/bigmenu/big5_home.jpg) no-repeat;
height: 28px; width: 150px;
}
And the span has to be here so that it work in IE but creates 2 pixel white
space.
#siteOption #homeLink span {display: none; }
For what it is worth, this is not a very accessible method of image
replacement. From what I've gathered, most screen readers ignore text
that is styled with display: none;, so it kind of defeats the purpose.
You might want to take a look at http://tinyurl.com/3ksj9 (Malarkey) for
a more useful method that works well with lists. I've been using
basically the same method for some time, but Andy has also added a fix
for IE Mac that I never considered.
This won't solve any images off / CSS on issues, but it really
simplifies the IR method while keeping your markup relatively semantic.
--
Best regards,
Michael Wilson
**
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] ID conflicts
tee wrote:
This is the page I'd working on now. The body and the menu buttons are in id
so it works but doesn't pass the validation of course.
http://www.lotusseeds.com/big5.htm
.div id=siteOption
ul
li id=homea href=traditional.html id=home title=home
accesskey=1 /a/li
/ul
/div
Hi,
The problem is the still the same, but perhaps you missed the answers
earlier.
You can only use id=home once on any page--one time and one time
only--and never twice on the same page. This includes using the same id
on different tags or elements; if you use it on a li tag you cannot
use it on an a tag--even if it is in a separate div or other
element. The same rule applies for all id's--each one must be different
e.g unique, not the same,... the only one of it's kind.
In one instance you have (which is done correctly btw):
div id=navcontainer
ul id=navlist
li id=homea href=http://www.lotusseeds.com;...
In another you have:
div id=siteOption
ul
li id=homea href=traditional.html id=home...
The conflict is that you have 2 li's (the li in navlist and the li
in #siteOption) and 1 a (in #siteOption) all using the same id. To
make this work you will need to give each li and each a a unique or
different id or you simplify your specificity to use the id's already
available to you--you don't have to give every element an id.
For example you could give each a unique id like so:
div id=navcontainer
ul id=navlist
li id=homea href=http://www.lotusseeds.com;...
div id=siteOption
ul
li id=sohomea href=traditional.html id=soLink...
Then you can style li id=sohome based on unique id like so:
#sohome {
rules
}
And the a id=soLink:
#soLink {
rules
}
OR you could simplify your specificity like so:
To style the li within div id=siteOption you could use:
#siteOption li {
rules
}
To style the a within div id=siteOption you could use:
#siteOption li a {
rules
}
Regardless of the approach you choose, you cannot give any id to more
than one element.
The Validator is a great tool for spotting these types of errors, so use
it to identify where you have used an id more than once... there are
allot of instances to correct.
--
Best regards,
Michael Wilson
**
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] ID conflicts
tee wrote:
Yes, I fully aware that ID can only apply one and one ONLY :)
I have to say I didn¹t' think ahead when making the menu. Having the button
set to ID was fine and passed the flying colors with validator. The issue
arise once I decided to have the 'current page' indicator. I did try to
change button ID to class, set the conflict ID to different name, but no
matter what I do, either my button disappears or the indicator won't work.
Hi,
Then why are you still using the same id for both your li's and your
a's in #siteOption ul? If you know this is a no no, then the first
thing you should do is fix it. You don't *have* to use a class and in
this case a class makes less sense (to me at least) than a unique id.
In one instance you have (which is done correctly btw):
div id=navcontainer
ul id=navlist
li id=homea href=http://www.lotusseeds.com;...
This actually is the menu for English page. I hide it in my Chinese page and
will eventually remove it. The problem I am facing now has nothing to do
with this navlist.
It doesn't matter if you hide it... it's still in the document and it
still has a conflict with the other navigation's id's. Take it out,
rework the id's so they are unique to the page, rework your CSS to style
the nav that you *will* use, retest, revalidate, and see if that clears
up the problem...
Set your nav ul up like this:
div id=siteOption
ul
li id=homea href=traditional.html id=homeLink
title=title accesskey=1 /a/li
li id=projectsa href=projects_big5.html
id=projectsLink title=title accesskey=2 /a/li
li id=servicesa href=services_big5.html
id=servicesLink title=title accesskey=3 /a/li
li id=abouta href=about_big5.html id=aboutLink
title=title accesskey=4/a/li
li id=contacta href=contact_big5.html id=contactLink
title=title accesskey=5 /a/li
li id=accessibilitya href=accessibility_big5.html
id=accessibilityLink title=title accesskey=g /a/li
li id=big5a href=simplified.html id=big5Link
title=title accesskey=7/a/li
li id=englisha href=english.html id=englishLink
title=title accesskey=8/a/li
/ul
/div
And your CSS like this (or similar depending on your specificity needs):
/* vertical menu */
#siteOption #homeLink {
background: url(images/bigmenu/big5_home.jpg) no-repeat;
height: 28px; width: 150px;
}
#siteOption #projectsLink {
background: url(images/bigmenu/big5_pro.jpg) no-repeat;
height: 28px; width: 150px;
}
#siteOption li a#servicesLink {
background: url(images/bigmenu/big5-srvs.jpg) no-repeat;
height: 28px; width: 150px;
}
#siteOption #aboutLink {
background: url(images/bigmenu/big5_about.jpg) no-repeat;
height: 28px; width: 150px;
}
#siteOption #contactLink {
background: url(images/bigmenu/big5_contact.jpg) no-repeat;
height: 28px; width: 150px;
}
#siteOption #accessibilityLink {
background: url(images/bigmenu/big5_acs.jpg) no-repeat;
height: 28px; width: 150px;
}
#siteOption #big5Link {
background: url(images/bigmenu/big5_simp.jpg) no-repeat;
height: 28px; width: 150px;
}
#siteOption #englishLink {
background: url(images/bigmenu/big5_eng.jpg) no-repeat;
height: 28px; width: 150px;
}
/* big5 menu hover page ID*/
#siteOption #homeLink:hover,
#homepage #homeLink {
background: url(images/bigmenu/big5_homeH.jpg) no-repeat;
height: 28px; width: 150px;
}
#siteOption #projectsLink:hover,
#projectspage #siteOption #projectsLink {
background: url(images/bigmenu/big5_proH.jpg) no-repeat;
height: 28px; width: 150px;
}
#siteOption #servicesLink:hover,
#servicespage #siteOption #servicesLink {
background: url(images/bigmenu/big5-srvsH.jpg) no-repeat;
height: 28px; width: 150px;
}
#siteOption #aboutLink:hover,
#aboutpage #siteOption #aboutLink {
background: url(images/bigmenu/big5_aboutH.jpg) no-repeat;
height: 28px; width: 150px;
}
#siteOption #contactLink:hover,
#contactpage #siteOption #contactLink {
background: url(images/bigmenu/big5_contactH.jpg) no-repeat;
height: 28px; width: 150px;
}
#siteOption #accessibilityLink:hover,
#accessibilitypage #siteOption #accessibilityLink {
background: url(images/bigmenu/big5_acsH.jpg) no-repeat;
height: 28px; width: 150px;
}
#siteOption #big5Link:hover {
background: url(images/bigmenu/big5_simpH.jpg) no-repeat;
height: 28px; width: 150px;
}
#siteOption #englishLink:hover {
background: url(images/bigmenu/big5_engH.jpg) no-repeat;
height: 28px; width: 150px;
}
--
Best regards,
Michael Wilson
**
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] why, why, why, --firefox glich--
Kvnmcwebn wrote:
--this list is my only hope---
I've been rebuilding the html of this page over and over and cant find why
the container div dosnt resize{height} to accomodate all the content in
firefox.
Below is a link to the css and page.
http://mcmonagle.biz/TESTSITE/
Hi,
*Technically* Firefox is getting the layout right. IE (and probably some
older versions of Opera) will automatically enclose your floats because
you've given your container a stated dimension (width: 550px;). While
that may be the desired behavior in some cases (when we wish a div
behaved like a table cell), it's not the correct behavior according to
the W3C spec.
Take a look at http://www.positioniseverything.net/easyclearing.html.
You'll need to clear the container to get Firefox to enclose the floats.
This probably won't solve all of your issues (e.g. I don't think this
will clear the footer without further tweaking), but it should get you
on the right track.
--
Best regards,
Michael Wilson
**
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] NS4 spacing borders
Carol Doersom wrote:
I can't put
margins in for NS4, because they'll mess up my page layout in the
up-to-date browsers, so I guess I'll use ps or br /s where necessary.
Thanks to all of you for your suggestions!
It's really not all that difficult to compensate for NN4. Just use a
linked stylesheet for NN4 and @import url(styles.css); for stylesheets
designed for more modern browsers. The only caveat being that the styles
you use in your linked CSS will need to be overridden in your @imported
stylesheet or they will bleed over to the modern browsers. I generally
complete my global CSS first and then go back and apply some simple
stying in my NN4 stylesheet for the things I've already addressed in the
global. It usually works out quickly and painlessly and while I'm not
trying to make NN4 look and feel like the more modern version, I can
still give it more than a standard markup face lift.
For example--
In the head of your document you would add something like:
link href=css/nn4.css rel=stylesheet type=text/css /
followed by:
style type=text/css
!--
@import url(css/global.css);
--
/style
Your nn4.css would contain:
div {
margin: 10px 0 10px 0;
}
Your global.css would contain:
div {
margin: 0;
}
...or whatever styling is appropriate. If you do find that you have to
add something to your NN4 stylesheet that you don't already address in
your global stylesheet, just sneak back in and add some defaults to your
global.css compensate.
HTH
--
Best regards,
M. Wilson
**
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] clear:both vs br clear=all
Jamie Mason wrote: I just want to clear some floats to get the background to collect a div area. Can someone help me? Hi, You might want to take a look at the method below. I find this works well for making a div encapsulate it's floats, if of course, that is what you are looking for. http://www.positioniseverything.net/easyclearing.html -- Best regards, Michael Wilson ** 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] Nav Before or After Main Content
by changing systems on different pages. When I visit a site, I expect navigational elements to be clearly positioned and marked in what I consider a normal fashion. I don't want to have to eyeball the page for more than a few seconds to determine where the navigation is and what my options may be. I also want to see the navigation in basically the same place on every page of the site. If I find the navigation, made up of only cryptic symbols or graphics, in the bottom right corner of the page, the first question I would ask myself is: why on earth would anyone considered this a good idea? I assume visually impaired people have the same or similar thought processes and appreciate consistency. * provide visible skip links that allow users to jump to the content (if nav first) or nav (if content first). The wording for skip links has been hotly debated on this list before, so look through WSG mail archives for the best fit for you. I've already made a basic decision on how I might approach this. After digging through as many resources as I could last night and this morning I think the following average layout would work well. [Headings as Necessary] [Skip to Main Navigation Link] [Skip to Site Map Link] [Current Page Navigation as Necessary] [Main Content] [Site Navigation] [Skip to Main Content Link] [Footer Information] I'm sure I will tweak this as I move forward, but now I at least have a somewhat better understanding of how I should proceed. Thanks to everyone for your comments. -- Best regards, Michael Wilson ** 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] Nav Before or After Main Content
Michael Wilson wrote: After doing *allot* of reading last night, both here, on other lists, and in other forums such as Accessify Forum (01), I see that there are indeed valid arguments to support both approaches. Sorry about that... I left off the link for those who might be interested. Accessify Forum: http://www.accessifyforum.com/ -- Best regards, Michael Wilson ** 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] Nav Before or After Main Content
Hi, Over the last year or so, I've been steadily pushing for improved use of standards within one of my organizations sites. I've moved the site away away from table based layouts and implemented CSS for presentation. The initial transition (01) was an improvement; however, there are still issues with font size and zoom, navigation, headings, forms, and the general semantics of the markup that we intend to address. One of the issues I wanted to address first was source order versus screen arrangement of the various pieces of content. In the current version, the content is last in the lineup and I don't feel that is the best option. I've worked things out to the point (02) that I can place the navigation either first (horizontal example after any promo stuff) or after the main content (vertical example at the top of the side-bar). My question at this point is: which is a better approach--nav first with a skip to content link or nav last with a skip to nav link? I'm inclined to think putting the nav last or at least after the main content is better for screen readers and such as well as for SEO, but I don't have any solid research to back up that opinion. Placing the nav in the sidebar also allows for more font scaling than the horizontal option--it won't have fly out menus, but I'd rather have a home page for each main section anyway. So what do you guys think? 01: http://www.iqmax.com/ 02: http://www.iqmax.com/iqmaxcss/ -- Best regards, Michael Wilson ** 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] resizing w/ floats
Alan Trick wrote: The problem is that the containing block, usually another div does not resise to fit the length of the right and left blocks because they are floated. So you get things like this: ___ | | | | | | | | | | | | | | | | | | | | | |stuff | | | float 1 | in | float 2 | | |middle| | | | | | |_|__|_|--bottom of containing block | | |_| | | |_| As everyone else has stated, you need to clear the floats. I use a method that doesn't require a clearing element such as an empty div or br clear=both. Sometimes, and this is a little strange in itself, you'll need to apply this technique to the containing element as well for Netscape v6. http://www.positioniseverything.net/easyclearing.html -- Best regards, Michael Wilson ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Are forms tabular data? (was Re: [WSG] Can I use a table in a form?)
Andy: If forms were meant to be tabular they'd have fr's and fd's. Therefore data output in tabular form is okay but data input is not. Hi, Sorry if I quoted you out of context Andy (I don't have the original message), but I have a question regarding why forms should or should not be considered tabular data. Suppose we are presenting the user with a form where the inputs are pre populated with data; for example a form used to edit an entry in a database. In your opinion (or anyone else's), should this impact whether the form should be considered tabular or not? First Name [Michael] Last Name [Wilson] Age [Old] Although the data is contained within form elements, technically this is data output. I haven't formed an opinion on the subject, so please don't take my comment as some kind of troll. I've avoided the use of tables for forms for some time now--some times it works out, sometimes it does not. It just occurred to me as I was reading the responses here that, within the argument, the question of data input versus data output seemed to be the (or part of the) crux. Is this the case or does the argument hinge on the fact that the input element itself is not data; therefore, not tabular. If this is the premise, then couldn't one argue that the p element is not data; therefore, not tabular? -- Best regards, Michael Wilson ** 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] Connditional Comment / @import Problem in IE 5.0.1
Andrew Krespanis wrote:
This may sound insane, but if the style element is adding whitespace, try
style {
display:none;
}
I've never heard of this before, but my suggestion could be worth a try...
I gave the display and height properties a shit with no luck. I've never
heard of anything like this either and it's really weird that it happens
in IE 5.0.1, but not 5.5.
I'm guessing you're using the @import method to hide styles from NN4?
Yes, and if I can't figure out what the deal is, I suppose I'll @import
within a linked stylesheet--I just hate having to use that kind of system.
Thanks for the reply.
--
Best regards,
Michael Wilson
**
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] Connditional Comment / @import Problem in IE 5.0.1
Kay Smoljak wrote: I've seen something similar when the conditional comment syntax wasn't quite right. The way they handle GT and LT is a little odd... I'd check what you have against MSDN. Hi Kay MSDN calls for !--[if expression] HTML ![endif]--, which is what I am using. And... since I'm just stating [if IE], this really shouldn't be isolated to IE 5.0.1. I did a little more testing and things get stranger. IE 5.0.1 breaks when I use: style type=text/css @import url(css/iqmax.css); /style !--[if IE] link href=css/iqmax.ie.css rel=stylesheet type=text/css / ![endif]-- If I change the method to: style type=text/css @import url(css/iqmax.css); /style !--[if IE] style type=text/css @import url(css/iqmax.ie.css); /style ![endif]-- ...it works like a champ. I suppose this will work just dandy, but I'm still baffled as to why the previous method is causing problems. My only guess is that the problem is tied directly to something in my markup. I've used this same method several times recently (01), with no problems at all. Unless there is something screwy with my link... syntax that I'm missing, I suppose it will have to remain a mystery. 01: http://www.iqmax.com/iqtray/memCardSync.htm -- Best regards, Michael Wilson ** 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] Connditional Comment / @import Problem in IE 5.0.1
David R wrote: MSDN calls for !--[if expression] HTML ![endif]--, which is what I am using. And... since I'm just stating [if IE], this really shouldn't be isolated to IE 5.0.1. Its preferable to use !--[if lt IE7] instead, as there's a pretty strong chance that the real IE7 will obey standards I agree there is a chance that my conditional could mess with IE 7... when we finally see it--*if* we finally see it. At this point though, all MS released versions of IE need the selectors in this particular stylesheet and I don't have any basis to believe IE7 will not. There aren't any hacks in the conditional stylesheet, but it does correct a slight rendering difference between IE and... well, everything else. I think I'll stick with [if IE] for now and see what gives when IE 7 is released--it may not be an issue that gets corrected and if it does, I'll catch it for sure. Oh, and if a website (or user) employs the IE7 JavaScript library, then it will treat conditional comments as though it were the real IE7. I haven't really given much thought to a *user* implementing the IE7 JavaScript hacks. I suppose there is some merit in considering this possibility, but given our users, I'd say the chances of this being the case are extremely remote. I haven't checked to see if this particular issue is evident in any user implementation of IE7, but I will look into it. Thanks for the comments. -- Best regards, Michael Wilson ** 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] Big Name Site Goes Standards
Tom Livingston wrote: Thank GOD! Then *all* it would be is a blog. Felix Miata wrote: Flash, text in images, fixed width that crumbles with zoom. It doesn't come anywhere close to a crumble in my IE at default settings or when zoomed to the max. In Firefox (default 16px font size) I *can* break it, but it zooms up four times without it becoming an issue-that's pretty good. Even at font size set to 22px in Firefox and while zoomed four times, the site is still very usable--it's not as pretty, but I can use it. I would think we should recognize the overall achievements before we scrutinize the details of how it could be improved. -- Best regards, Michael Wilson ** 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] Connditional Comment / @import Problem in IE 5.0.1
Kay Smoljak wrote: Michael Wilson wrote: I did a little more testing and things get stranger. IE 5.0.1 breaks when I use: Hmm... you said you're using the standalone IE versions, right? I'd test in a real IE 5.01 before you write it off completely if I were you... those standalone versions are very, very confused about their identities :) I don't have a test machine with IE 5 loaded, but again, given that I am saying [if IE]--no version specified--I think the chances of it being some kind of standalone quirk are slim. Not impossible though and if I were using some other condition, I might give it a little more weight. The fix I came up with is good enough, but if someone has a full install of IE 5.0.1 on Windows, I'd appreciate a hit to a test page just to see if that's the case. -- Best regards, M. Wilson ** 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] Connditional Comment / @import Problem in IE 5.0.1
Hi all, For quite a while, I've been using my spare time to improve the standards, CSS, usability, and accessibility of one of my projects. In doing so I've also been trying to move away from IE hacks in my CSS in favor of conditional comments, which for the most part has been a fairly seamless process. While making some adjustments to the main template (01) this morning, I noticed IE 5.0.1 would behaving oddly when I added a particular conditional comment. When I included the conditional comment, a rather large gap would appear at the top of the page. At first, I thought something in the IE stylesheet was causing the problem, but after further testing I realized that it was the comment itself that caused the issue, or rather, the comments position in the markup. If I place the comment above the @import (02) of my main stylesheet, everything seems to work fine; however, there is a single selector in the IE specific stylesheet that needs to override a selector in the main stylesheet, so the conditional comment *has* to come after the @import. When I move the comment below the @import, IE 5.0.1 (not 5.5 or 6.0) breaks (03). I can completely remove the CSS from the IE specific stylesheet--saving it as a blank document-- and the problem persists. Furthermore, and this just makes things weirder, if I use a link href=.../, rather than @import, the problem vanishes. I also tested several other import methods, all of which, produce the same results as the method I originally used. I am using the hacked, standalone versions of IE 5.0.1 and 5.5 for testing; however, I am aware of the issues with using conditional comments. This particular conditional uses [if IE], so the version of IE *should be* irrelevant. I only mention this to be sure all my conditions are straight, in case there is any question. Has anyone ever experienced something similar to this issue or know of any documentation that might help explain it? Of course, I could just be doing something stupid or overlooking something simple. I'll leave the comment in the broken position for now, so y'all can check it out if you like. 01: http://www.iqmax.com/iqmaxcss/ 02: http://www.iqmax.com/downloads/mike/beforeimport.gif 03: http://www.iqmax.com/downloads/mike/afterimport.gif @import method used: style type=text/css !-- @import url(css/iqmax.css); -- /style Conditional comment used: !--[if IE] link rel=stylesheet type=text/css href=css/iqmax.ie.css / ![endif]-- -- Best regards, Michael Wilson ** 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] Interesting Doctype: anyone seen something like that before?
Rene Saarsoo wrote: I found a page, I tried to validate it (like I always do 8-) ) and suddenly there appeared an error message I had never seen before, but more interesting then the error message was the code that had caused it: !DOCTYPE HTML generated by Dreamweaver, does not conform to W3C open standards Hi, The error you received is actually the contents of the DOCTYPE in the markup--view the source. I suppose the developer was having some issues. ;) -- Best regards, Michael Wilson ** 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] Gallery markup
Collin Davis wrote:
I just asked for some advice on css-d, regarding gallery pages, very
similar to www.strombergarchitectural.com/products.php
http://www.strombergarchitectural.com/products.php - the same pages I
asked for help on with cleaner, more semantic code on this list not too
long ago. The advice I received from several people, and agreed with,
was to uses lists, which I have done. However, two people on css-d
commented about the incorrect use of lists there one person
suggested it was tabular data, and should use tables.
Hi,
I like lists for stuff like this too; however, I prefer definition lists
over unordered list. While CSS can be used to add presentation to any
list, when CSS is off, unordered lists do little to convey any meaning
or priority. Definition lists, even with CSS off, will continue to
convey a reasonable sense of item grouping and precedence. Combined
with the title attribute, you can easily create lists that are pretty
darned clear.
I would use something like this:
style type=text/css
dl {
border: 1px solid #BDBEC1;
margin: 0;
padding: 5px 15px;
width: 100px;
}
dt {
margin: 0 0 5px 0;
padding: 0;
}
dd {
margin: 5px 0 0 0;
padding: 0;
}
/style
dl title=Digital Image Album
dt title=Album TitleQuoins/dt
dd title=An image of a...img src=quoins.jpg alt= width=100
height=100/dd
dd title=The description of a...Description/dd
/dl
Of course, I'm still trying to figure this out for myself, but I think
this is a good method given what we have to work with.
--
Best regards,
Michael Wilson
**
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] Font size
Henry Tapia wrote: Points about allowing the user as much text size control as possible are well made and I agree, however I don't think I'd have a job as a designer if I relied upon the average user to change their browser's default text-size manually. In my several years working on the web, and as a user prior to that, I've never witnessed that behaviour, even amongst savvy users (text-zooming yes, adjusting browser default text-size, no). hank Hi, I don't believe I have either Hank. I would go so far as to suggest that the average user does not realize the default font size *can* be changed. Additionally, while some users are aware that text can be zoomed using the mouse or keyboard, they are still a minor portion of Web users. Someone who has poor eye sight has likely researched their options, and adjusted their font size accordingly. -- Best regards, Michael Wilson ** 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] Font size
Hi, Felix Miata wrote: It is arrogant to impose it, rather than merely wish it. What you are doing is saying to your visitors I can't actually know what your default is, but regardless what it really is, it's too big for me, and I'm imposing a xx% reduction from whatever you chose as most appropriate for yourself, whether your default is 9px, or 90px or anything in between. Perhaps it is a bit arrogant for a designer or developer to decide for the user which font-size is most suitable, but design requires that choices be made. Otherwise, we should simply abandon all forms of content styling and rely entirely upon the user to assert their styling desires via whatever means are available to them. We consistently make choices for the user that we feel will improve the user's experience. In many cases we specify font-face, line-height, letter-spacing, color, background-color, emphasis, strength, paragraph width, text effects, and heading levels. All of these choices impact readability and they each alter the user's default settings to some extent. For example, the page you provided earlier (http://members.ij.net/mrmazda/auth/defaultsize.html) is a prime example of how the author simultaneously champions and ignores the importance of the user's preferences. To my eyes, the page is far more readable unstyled than when the font-color, background-color, headings, and font-face are altered to suit the authors idea of pleasant. The font-size seems to have the least impact on how easy or difficult the document is to read, but is the main focus of the information. The web is about control, but not the designer's, it is the user's control that is central to the design and philosophy of the web. John Allsopp at http://webstandardsgroup.org/features/john-allsopp.cfm This particular page sets the font-size for paragraphs and list to 80%, so I don't think this is the best supporting argument for your point. In fact, most of the elements on this page are altered to be either larger or smaller than my default settings. I do, however, have control, which is the key factor of the equation. Still, the average user may or may not know how to exercise this control, so it is evident the issue extends beyond designers and developers and ventures into the realm of user interface and education. -- Best regards, Michael Wilson ** 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:
David Laakso wrote: FF Horizontal page shift when h v menu items are clicked, although perhaps not as noticeable as in Opera. Text zooms vertically, breaking horizontal menu rather quickly. IE6 No shift when h v menu items are clicked. Text does *not* zoom. Wouldn't that jump be Firefox drawing the vertical scroll bar on the right? IE's scroll bar is always in place and activates when necessary. I may be missing something else, but that seems to be the case on my box. -- Best regards, Michael Wilson ** 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] pt, em and ex
Iain Harrison wrote:
Eh? That makes no sense to me. Body is a child of html.
Patrick H. Lauke wrote:
I'm not disputing that. What I'm saying is: I use
html { font-size: 100%; }
body { font-size: 0.8em; }
Hi,
First post-- nice to meet you all and thank you for all of the
information you share.
I've been using the opposite with fairly decent results across various
browsers and settings. This seems to give me at least some consistency
in font size without totally taking over the user's preferences or
ability to adjust the size.
html { font-size: 76%; }
body { font-size: 1.0em; }
Actually because most of the time I have a container div, I usually
place the % on the body and the em on the div, but I suppose it's the
same idea in theory.
--
Best regards,
Michael Wilson
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
