RE: [WSG] Not and IE bug?...follow up difference why a difference between IDs and classes?
newbie questions... What is the advantage of the fact that IDs must be unique on a page? I am aware of the circumstance that if you need to repeat an ID, set is as a class, but have still not figured out the advantage of an ID. ¤ devendra ¤ In addition to everything else, as id replaces name, id becomes a means to navigate to parts of a document using the anchor element: a id=main/a. drew ** 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] Not and IE bug?...follow up difference why a difference between IDs and classes?
On Thu, 10 Feb 2005 06:40:49 -0500, Trusz, Andrew [EMAIL PROTECTED] wrote: newbie questions... What is the advantage of the fact that IDs must be unique on a page? 1. getElementById() works. 2. Validation. If you use div id=maincontent, validator will complain when you have two or more such divs (typical copypaste accident :) Additionally IDs have higher priority than class in CSS, so it's easier to make local styles for element with an ID than with a class. -- regards, Kornel Lesiski ** 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] Not and IE bug?...follow up difference why a difference between IDs and classes?
You can address elements from the DOM (Document Object Model) directly via JavaScript. Cheers, Mike Pepper Accessible Web Developer Internet SEO and Marketing Analyst [EMAIL PROTECTED] http://www.visidigm.com Administrator Guild of Accessible Web Designers [EMAIL PROTECTED] http://www.gawds.org -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Trusz, Andrew Sent: 10 February 2005 11:41 To: 'wsg@webstandardsgroup.org' Subject: RE: [WSG] Not and IE bug?...follow up difference why a difference between IDs and classes? newbie questions... What is the advantage of the fact that IDs must be unique on a page? I am aware of the circumstance that if you need to repeat an ID, set is as a class, but have still not figured out the advantage of an ID. ¤ devendra ¤ In addition to everything else, as id replaces name, id becomes a means to navigate to parts of a document using the anchor element: a id=main/a. drew ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.6 - Release Date: 07/02/05 ** 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] Is there any way to set the width of a file input field in Firefox?
Angela,
Your suggestion is for input type=text. It does not work for input
type=file. See shots attached produced by the following style:
div#Attachment {width: 600px;background-color:yellow;border: 1px solid black;}
#txtAttachment {width:400px;background-color:red;text-align: right;}
Cheers, Irina.
On Fri, 4 Feb 2005 10:44:32 +0100, Ricci Angela
[EMAIL PROTECTED] wrote:
Terrence
All you need to do is to give an id to the form field and define its
width on the CSS. It will work for all browers.
input type=text id=ffield /
CSS: #ffield {width: 100px;}
Cheers!
Ge RICCI
-Message d'origine-
De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la
part de Terrence Wood
Envoyé : vendredi 4 février 2005 10:27
À : wsg@webstandardsgroup.org
Objet : Re: [WSG] Is there any way to set the width of a file input
field in Firefox?
Styling file input is inconsistent cross browser and platform here
is a work around:
http://www.quirksmode.org/dom/inputfile.html
Terrence Wood.
Irina Ahrens wrote:
Hello,
Does anybody knows how to set the width of a file input field in Firefox?
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
attachment: InputOfFileType_IE6.gifattachment: InputOfFileType_Firefox.gif
RE: [WSG] Not and IE bug?...follow up difference why a difference between IDs and classes?
-Original Message- From: [EMAIL PROTECTED] On Behalf Of Kornel Lesinski Sent: Thursday, February 10, 2005 7:09 AM To: wsg@webstandardsgroup.org Subject: Re: [WSG] Not and IE bug?...follow up difference why a difference between IDs and classes? newbie questions... What is the advantage of the fact that IDs must be unique on a page? 1. getElementById() works. 2. Validation. If you use div id=maincontent, validator will complain when you have two or more such divs (typical copypaste accident :) Additionally IDs have higher priority than class in CSS, so it's easier to make local styles for element with an ID than with a class. -- regards, Kornel Lesiski * While true all those points had already been mentioned and weren't the point in any case. The point was that you can create links to parts of documents using id: www.mysite.com/mypage.html?id=#myidea drew ** 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] Is there any way to set the width of a file input field in Firefox?
Irina,
Am Freitag, 4. Februar 2005 um 05:50:36 haben Sie geschrieben:
IA Does anybody knows how to set the width of a file input field in Firefox?
Take a look at the form.css in res under your firefox installation
directory. There you will find the following styling:
/* file selector */
input[type=file] {
-moz-appearance: none;
white-space: nowrap;
cursor: default;
-moz-binding: none;
padding: 0 !important;
border-style: none !important;
}
input[type=file] input[type=text] {
border-color: inherit;
background-color: inherit;
color: inherit;
font-size: inherit;
height: inherit;
}
/* button part of file selector */
input[type=file] input[type=button] {
height: inherit;
font-size: inherit;
}
Feel free to override the defaults. :)
Martin.
**
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] Links not working in MAC
Title: Message Hello all, I have a page, http://www.m5i.com/m5hr/test.php, with a scroller but the links do not work in MAC IE 51, anyone have any ideas? Thanks in advance, Paul
Re: [WSG] Links not working in MAC
On Thu, 10 Feb 2005 10:06:04 -0330, Paul [EMAIL PROTECTED] wrote: Hello all, I have a page, http://www.m5i.com/m5hr/test.php, with a scroller but the links do not work in MAC IE 51, anyone have any ideas? Fix these problems first: http://validator.w3.org/check?uri=http://www.m5i.com/m5hr/test.php -- regards, Kornel Lesiski ** 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] Links not working in MAC
G'day Paul wrote: I have a page, http://www.m5i.com/m5hr/test.php, with a scroller but the links do not work in MAC IE 51, anyone have any ideas? Just one idea... Run the page through the W3C validator and fix any errors. Not trying to be a wise-guy, but if you feed the browser broken (x)HTML, the result is unpredictable. The problem may not disappear if the page validates, but it should be the first step in trying to find the cause of the problem. Regards -- Bert Doorn, Better Web Design http://www.betterwebdesign.com.au/ Fast-loading, user-friendly websites ** 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] Not and IE bug?!?
Thanks Peter, I'll check it out! On 9-Feb-05, at 5:12 PM, Peter Asquith wrote: Hi Peter Peter Flaschner wrote: Well, the clearing didn't do it. At least not as I understand it. If you're following the lead of the page you mentioned, you will find removing the overflow: hidden; line from the style sheet should solve your problem. By setting the height to zero and then hiding the overflow you're effectively removing the clearer block from the page layout. Setting visibility to hidden, on the other hand, allows the block to take its specified position and size but not be rendered by the browser. I.e. it still takes up the space it would have. I note, too, that your example page contains multiple elements sharing the same ID. IDs must be unique for a given page. Cheers Peter -- Peter Asquith http://www.wasabicube.com/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** 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] double space after period
Russ, My thought exactly! Depending on the font, there are times when it is difficult to determine, at first glance, where sentences begin and end. By the way, I still use a double space at the end of a period as we were taught this in grammar and writing classes, not typing! ;-) Suzanne [EMAIL PROTECTED] Snip From: russ - maxdesign [EMAIL PROTECTED] Date: Thu, 10 Feb 2005 10:22:58 +1100 Subject: Re: [WSG] double space after period I agree wholeheartedly, one of my pet peeves as well, especially after battling it through the early days of desktop publishing in the 80s. This isn't a matter of grammar or standards, it's a matter of correct use of punctuation. James, I think you and Chris are missing Lachlan's point. Other posts in this thread have covered the double spaces are not relevant now argument, and that they are not official part of punctuation. Those are separate issues that almost everyone has agreed with so far. Lachlan's point was specifically about making content more readable for specific groups of users. If this technique was found to be valuable for some groups, such as those who experience reading difficulties, then it could be useful on certain sites. It could be set up in such a way that it did not interfere with users who did not wish this function. The site could have a customisation tool that included an easy read option - which added space around content and an extra space after sentences. So, in this case, it has nothing to do with grammar, it is about accessibility. Russ Snip ** 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] double space after period
[EMAIL PROTECTED] wrote: Russ, My thought exactly! Depending on the font, there are times when it is difficult to determine, at first glance, where sentences begin and end. By the way, I still use a double space at the end of a period as we were taught this in grammar and writing classes, not typing! ;-) Suzanne [EMAIL PROTECTED] Me too. For the very same reason. Shane Helm sonzeDesignStudio www.sonze.com ** 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] accessibilty and responsibility
Possibly so, but is an architect being given the short straw by being required to include ramps and elevators in the design of a building? It has to be done because of the 'shortcomings of my assistive technology, my wheelchair, that cannot climb stairs or levitate. I agree that better browser features, CSS support, etc. should be demanded. We do that by using better browsers ourselves and telling friends, relatives, etc. to do the same. Enough people switch to Firefox, Opera, or whatever, and Mr. Softy will eventually make improvements in IE. Of course, I'll have my levitating wheelchair before that happens... Christopher M. Kelly, Sr. (GM22) State Farm Insurance Companies - disAbility Support website: http://intranet.opr.statefarm.org/sysdisab/ phone: 309-763-7069 email: [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 11, 2005 1:52 PM To: wsg@webstandardsgroup.org Subject: [WSG] accessibilty and responsibility Hi all, I'm coming to this very much as a newbie, so be gentle with your response: I feel that, in many ways, we as web designers are getting the short straw by being asked to counteract the shortcomings of the browser/PC people, rather than the other way around. For example, Opera has a really great zoom feature (as we know) and I can't help feeling that there should be a push to 'demand' this of all browsers. It even works with Flash of course . .. . I haven't heard anything about work going on from this aspect of things (maybe I just don't know about it) but feel that if there isn't such work in progress there should be! What exactly is the position? I hope this isn't OT - I considered not because accessibility is a part of standards. Thanks for your thoughts, Bob McClelland, Cornwall (U.K.) www.gwelanmor-internet.co.uk ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** 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] accessibilty and responsibility
At 10:37 AM -0600 2/10/05, Christopher M Kelly wrote: Possibly so, but is an architect being given the short straw by being required to include ramps and elevators in the design of a building? The issue is to force companies to make software/hardware better. Something that is physically possible. Your analogy is having architects wanting disabled people to become non-disabled so he/she doesn't have to put in ramps and elevators. Something that is not possible, unfortunately, and not at all the same thing. To have Moz and M$ be part of the W3C, and then turn out browsers (in the past, anyway) that ignore, mess up or reinterpret the standards they help create seems foolish at best. Should we, as part of our jobs, hack and work around these problems for the users, yes. Should it forever be our jobs, no. New versions of browsers should follow/comply with the standards. Period. My 2¢ have now been contributed. Carry on... -- - Tom Livingston Senior Multimedia Artist Media Logic mlinc.com ** 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] accessibilty and responsibility
With respect Christopher, I think you're missing the point. To take your analogy further, it seems to me that making web designers emsolelyem responsible for dealing with accessibility is like telling architects they're off the hook with regard to ramps etc, and getting the decorators to carry the disabled into the buildings. . . Until the ramps are built, we decorators do carry folk in and out, but the ultimate responsibility is with the architects, not us. And that often doesn't seem to be the case. Bob McClelland, Cornwall (U.K.) www.gwelanmor-internet.co.uk Original Message - From: Christopher M Kelly [EMAIL PROTECTED] To: wsg@webstandardsgroup.org Sent: Thursday, February 10, 2005 4:37 PM Subject: RE: [WSG] accessibility and responsibility Possibly so, but is an architect being given the short straw by being required to include ramps and elevators in the design of a building? It has to be done because of the 'shortcomings of my assistive technology, my wheelchair, that cannot climb stairs or levitate. ** 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] Making boxes flow around floats using CSS
I'm looking for feedback regarding a CSS hack I came up with recently. http://www.pupinc.com/files/test/float.html The goal is to force entire boxes, not just their content, to flow around any adjacent floated content. My method works fairly well for the browsers I'm able to test, but I'm having some trouble with IE5Mac and Opera. Any suggestions would be appreciated. Thanks. Pup ** 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] double space after period
Surely, the argument against the double space is only a short step away from it's logical extension: don't have paragraphs either, just have continuous text . . .? The logic behind both is surely the same? Bob McClelland, Cornwall (U.K.) www.gwelanmor-internet.co.uk - Original Message - From: Shane Helm [EMAIL PROTECTED] To: wsg@webstandardsgroup.org Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, February 10, 2005 4:22 PM Subject: Re: [WSG] double space after period [EMAIL PROTECTED] wrote: Russ, My thought exactly! Depending on the font, there are times when it is difficult to determine, at first glance, where sentences begin and end. By the way, I still use a double space at the end of a period as we were taught this in grammar and writing classes, not typing! ;-) Suzanne [EMAIL PROTECTED] Me too. For the very same reason. Shane Helm sonzeDesignStudio www.sonze.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** ** 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] double space after period
On Thu, 10 Feb 2005 18:52:54 -, designer [EMAIL PROTECTED] wrote: Surely, the argument against the double space is only a short step away from it's logical extension: don't have paragraphs either, just have continuous text . . .? The logic behind both is surely the same? No. The logic behind double-spacing after periods was that it was necessary in order to increase legibility during the age of the typewriter. And even during those days, professional typesetters did not use double spaces. Now that the typewriter has mostly gone the way of the dodo it's hard to make an argument for keeping the convention. Paragraphs, meanwhile, are a logical -- not a visual -- device. Just as a sentence is one or more self-contained thoughts, a paragraph is one or more related sentences. Often the first sentence of a paragraph introduces an idea, and the remaining sentences support or elaborate upon it. So it's hard to see an argument for doing away with paragraphs just because we don't double-space after periods any longer; the more logical extension of the argument presented here (as others have already pointed out) would be double-spacing *all* punctuation: colons, semicolons, commas, etc. Which makes no sense as it is completely at odds with existing conventions of English writing. And I stand by my original comment that CSS word-spacing or something like it would be the best practice for increasing space between sentences when necessary; inserting additional hard spaces (via nbsp; or similar) in the content is inflexible and mingles the presentation into the content, while keeping the spacing adjustment in the CSS allows the presentation to be tailored to different classes of users as necessary. Which is really the main accessibility benefit of CSS, as I understand it. -- May the forces of evil become confused on the way to your house. -- George Carlin ** 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] XHTML/CSS Layout - Why text is sliding under DIV below?
Hello - I am very new to this list, but frequent the CSS-Discuss list. Any reason why the text is sliding below the lower DIV on this site? www.fluxxlife.com/ I believe it is because the postion is set to absolute and not relative, but I'm not sure. thanks BJ Cook ** 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] accessibilty and responsibility
designer wrote: What exactly is the position? Opera's zoom-feature is nice - and useful, but comes more as an addition provided in that browser. IE6 can also zoom pages, but not that user-friendly. We may want browsers to have useful features like this, but that's not what we want first and most (I hope). All the real shortcomings are more important to push for improvements on. Like: 'standard code should work predictable in all browsers'. That's what standard [W3C] tools should give us across browser-land, instead of us having to counteract browser-weaknesses and bugs, and hack our way through a maze of non-standard behavior. http://browsehappy.com/, and similar initiatives, is one way we can push (a little) in the right direction. Some accessibility-features are our responsibility as web designers. We also have to follow standard(s). But when we do, then it should at least *work* across browser-land. Of course: I tell everyone that Opera has the greatest features. But I can't rely on that everyone else agrees with me, so I may have to add 'something' for those who choose Firefox too. :-) It's OK, as long as I don't have to /hack/ it in. Giving users a reasonable time to upgrade to the latest-- and hopefully best-- version of the browser of their choice, and then simply forgetting to code for the older versions, is one way we can push (a little) where it matters. Regrettably, that's not what we usually do, so I guess we've asked for status quo and slow progress, by debugging browsers at our end. regards Georg ** 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] accessibilty and responsibility
Giving users a reasonable time to upgrade to the latest-- and hopefully best-- version of the browser of their choice, and then simply forgetting to code for the older versions, is one way we can push (a little) where it matters. Ding, ding, ding... we have a winner! -- - Tom Livingston Senior Multimedia Artist Media Logic mlinc.com ** 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] Peoplesoft and standards
Hi Jesse: I think it depends on which Peoplesoft application you're asking about and what version it is. If you want to write to me offlist, I can put you in touch with a colleague at State Farm that does a lot of their web site accessibility testing of Peoplesoft and all the other apps that they run. Where I work at my day job, we did some preliminary testing a couple of years ago (Financials and HR - I'm sorry I don't recall the version numbers), and it didn't go well. ~ Kathleen Anderson Spider Web Woman Designs web: http://www.spiderwebwoman.com/ blog: http://msmvps.com/spiderwebwoman/category/321.aspx - Original Message - From: J Rodgers [EMAIL PROTECTED] To: wsg@webstandardsgroup.org Sent: Wednesday, February 09, 2005 8:48 AM Subject: [WSG] Peoplesoft and standards Hi, I am not too sure where else to ask about this. I have recently been part of discussions about the Peoplesoft application that we and many Universities use (not my fault) and its adherence to accessibility recommendations, and web standards. Peoplesoft claims to adhere to section 508.. Is this true? Looking at the default framed, JS dependant, table ridden code I don't believe it. Does anyone have any experience with Peoplesoft applications? Thanks, Jesse -- Jesse Rodgers Manager, Web Communications Communications Public Affairs - University of Waterloo [EMAIL PROTECTED] | 519.888.4567 ext. 3874 ** 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] Why DO floats not stretch their containers?
This is more of a philosophical question than a technical question, but here's the background. As we probably all know: * floated elements too big for the enclosing element spill out * except on IE, where they stretch the enclosing element that's a bit simplified, but essentially correct, right? For instance, with this code: div style=width:300px;height:100px;border:1px solid black; DIV A div style=width:100px;height:300px;border:1px solid red;float:left; DIV B /div /div DIV B will overlap DIV A and continue down the page on its own unless you're in IE in which case A will stretch. My question is, *why* is the correct behaviour the first one? It takes a lot of people by surprise and they often see what IE does as the natural and obvious thing to do. I'm not trying to start a flame war, I really want to know! I looked at my copy of the O'Reilly Definitive Guide by Eric Meyer and it just says that it's the correct behaviour, although some browsers don't respect it. It doesn't offer a rationale. Have You Validated Your Code? John Horner(+612 / 02) 9333 3488 Senior Developer, ABC Online http://www.abc.net.au/ ** 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 DO floats not stretch their containers?
I believe that it is because floated elements are removed from the document flow just like absolutely positioned elements are. So the rest of the elements on the page, including the containing element, literally can't see the floated element. If they can't see it, then they can't accommodate its height, width, or any other property of it. That's how I've always understood it, anyway. I'm sure someone will correct me if I'm wrong. :) Cheers, Seona. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of John Horner Sent: Friday, 11 February 2005 10:17 AM To: wsg@webstandardsgroup.org Subject: [WSG] Why DO floats not stretch their containers? This is more of a philosophical question than a technical question, but here's the background. As we probably all know: * floated elements too big for the enclosing element spill out * except on IE, where they stretch the enclosing element that's a bit simplified, but essentially correct, right? For instance, with this code: div style=width:300px;height:100px;border:1px solid black; DIV A div style=width:100px;height:300px;border:1px solid red;float:left; DIV B /div /div DIV B will overlap DIV A and continue down the page on its own unless you're in IE in which case A will stretch. My question is, *why* is the correct behaviour the first one? It takes a lot of people by surprise and they often see what IE does as the natural and obvious thing to do. I'm not trying to start a flame war, I really want to know! I looked at my copy of the O'Reilly Definitive Guide by Eric Meyer and it just says that it's the correct behaviour, although some browsers don't respect it. It doesn't offer a rationale. Have You Validated Your Code? John Horner(+612 / 02) 9333 3488 Senior Developer, ABC Online http://www.abc.net.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** __ ella for Spam Control has removed Spam messages and set aside Later for me You can use it too - and it's FREE! http://www.ellaforspam.com attachment: winmail.dat
Re: [WSG] double space after period
Because there's such a mix of opinions about the value of double-spacing between sentences and its history, I asked my friend John D. Berry, typographer book designer of note, to give me the low-down on double-spacing to post to this list. __ At 01:50 PM 2/10/2005, John D. Berry wrote: Paul -- Double-spacing after periods is a habit that began in the 19th century -- not a period noted for its fine typography! -- and has no justification whatsoever. I don't need to expound on the subject, however; it's already been done succinctly by Robert Bringhurst in The Elements of Typographic Style (2nd ed, pp 2830): 2.1.4 Use a single word space between sentences. In the nineteenth century, which was a dark and inflationary age in typography and type design, many compositors were encouraged to stuff extra space between sentences. Generations of twentieth-century typists were then taught to do the same, by hitting the spacebar twice after every period. Your typing as well as your typesetting will benefit from unlearning this quaint Victorian habit. As a general rule, no more than a single space is required after a period, a colon or any other mark of punctuation. Larger spaces (e.g., en spaces) are themselves punctuation. Being a poet and a scholar, Bringhurst goes on to mention one exception (probably not one that your discussion of text on the web is going to run into very often): The rule is usually altered, however, when setting classical Latin and Greek, romanized Sanskrit, phonetics or other kinds of texts in which sentences begin with lowercase letters. In the absence of a capital, a full en space (M/2) between sentences will generally be welcome. How you accomplish this in justified text, since the en space is a fixed space, is a job for a careful typesetter. In a more general way, and for composition in metal type, Jan Tschichold set very high standards when he took over the re-design of Penguin Books in the late 1940s; he was sending jobs to virtually every typesetter and printer in Britain, and had to standardize the results that would come back. The very first section of his Penguin Composition Rules is titled Text Composition (1947) [with my notes in brackets]: All text composition should be as closely word-spaced as possible. As a rule, the spacing should be about a middle space or the thickness of an 'i' in the type size used. [This would be the width of the piece of type, including the built-in space around it, not just the visual width of the i itself.] Wide spaces should be strictly avoided. Words may be freely broken whenever necessary to avoid wide spacing, as breaking words is less harmful to the appearance of the page than too much space between words. [I usually add: try to avoid misleading word breaks, such as rein-state, which can lead the reader to misread the sentence the first time through.] All major punctuation marks full point, colon, and semicolon should be followed by the same spacing as is used throughout the rest of the line. It's worth noting that Tschichold also set a standard of adding a small space before colons, semicolons, question marks, and exclamation points -- not a full word space, but a slight additional space, so the punctuation doesn't get subsumed into the word shape. I try to do this when I typeset text, and I wish more digital fonts were designed with extra sidebars around (or at least before) those punctuation marks. Obviously this extra space isn't needed before periods or commas, but I often run into automatic kerning pairs that would tuck the period or comma way too far under the overhanging part of a final letter like r or y. Our mania for kerning sometimes creates more visual problems than it solves. In all of these areas, the precise spacing needed to get the most readable text depends on the typeface used, of course. The spacing of the letters affects the spacing of the words affects the spacing of the lines, and so on all the way out to the margins of the page and back again. Typography is all about space. And now we'll see whether the fact that I've used italics and en dashes for clarity in this text rather than the truncated plain text that I usually limit myself to in e-mail breaks the system or not. I hope not. John :: :: :: John D. Berry book design typography: http://home.earthlink.net/~typographer/http://home.earthlink.net/~typographer/ dot-font: http://www.creativepro.com/author/home/951.htmlhttp://www.creativepro.com/author/home/951.html Contemporary Newspaper Design: http://www.markbattypublisher.com/servlet/book_view?number=17http://www.markbattypublisher.com/servlet/book_view?number=17 Language Culture Type: http://www.atypi.org/10_Visitors/70_publications/50_LCT/http://www.atypi.org/10_Visitors/70_publications/50_LCT/ ** The discussion list for http://webstandardsgroup.org/ See
Re: [WSG] double space after period
great comments thus far, but i think we're getting into the area where things are being said twice or getting into wy too fine a point. when exactly does this thread get closed? r - Original Message - From: Paul Novitski [EMAIL PROTECTED] To: wsg@webstandardsgroup.org Sent: Friday, February 11, 2005 10:40 AM Subject: Re: [WSG] double space after period Because there's such a mix of opinions about the value of double-spacing between sentences and its history, I asked my friend John D. Berry, typographer book designer of note, to give me the low-down on double-spacing to post to this list. __ At 01:50 PM 2/10/2005, John D. Berry wrote: Paul -- Double-spacing after periods is a habit that began in the 19th century -- not a period noted for its fine typography! -- and has no justification whatsoever. I don't need to expound on the subject, however; it's already been done succinctly by Robert Bringhurst in The Elements of Typographic Style (2nd ed, pp 28-30): 2.1.4 Use a single word space between sentences. In the nineteenth century, which was a dark and inflationary age in typography and type design, many compositors were encouraged to stuff extra space between sentences. Generations of twentieth-century typists were then taught to do the same, by hitting the spacebar twice after every period. Your typing as well as your typesetting will benefit from unlearning this quaint Victorian habit. As a general rule, no more than a single space is required after a period, a colon or any other mark of punctuation. Larger spaces (e.g., en spaces) are themselves punctuation. Being a poet and a scholar, Bringhurst goes on to mention one exception (probably not one that your discussion of text on the web is going to run into very often): The rule is usually altered, however, when setting classical Latin and Greek, romanized Sanskrit, phonetics or other kinds of texts in which sentences begin with lowercase letters. In the absence of a capital, a full en space (M/2) between sentences will generally be welcome. How you accomplish this in justified text, since the en space is a fixed space, is a job for a careful typesetter. In a more general way, and for composition in metal type, Jan Tschichold set very high standards when he took over the re-design of Penguin Books in the late 1940s; he was sending jobs to virtually every typesetter and printer in Britain, and had to standardize the results that would come back. The very first section of his Penguin Composition Rules is titled Text Composition (1947) [with my notes in brackets]: All text composition should be as closely word-spaced as possible. As a rule, the spacing should be about a middle space or the thickness of an 'i' in the type size used. [This would be the width of the piece of type, including the built-in space around it, not just the visual width of the i itself.] Wide spaces should be strictly avoided. Words may be freely broken whenever necessary to avoid wide spacing, as breaking words is less harmful to the appearance of the page than too much space between words. [I usually add: try to avoid misleading word breaks, such as rein-state, which can lead the reader to misread the sentence the first time through.] All major punctuation marks - full point, colon, and semicolon - should be followed by the same spacing as is used throughout the rest of the line. It's worth noting that Tschichold also set a standard of adding a small space before colons, semicolons, question marks, and exclamation points -- not a full word space, but a slight additional space, so the punctuation doesn't get subsumed into the word shape. I try to do this when I typeset text, and I wish more digital fonts were designed with extra sidebars around (or at least before) those punctuation marks. Obviously this extra space isn't needed before periods or commas, but I often run into automatic kerning pairs that would tuck the period or comma way too far under the overhanging part of a final letter like r or y. Our mania for kerning sometimes creates more visual problems than it solves. In all of these areas, the precise spacing needed to get the most readable text depends on the typeface used, of course. The spacing of the letters affects the spacing of the words affects the spacing of the lines, and so on all the way out to the margins of the page - and back again. Typography is all about space. And now we'll see whether the fact that I've used italics and en dashes for clarity in this text - rather than the truncated plain text that I usually limit myself to in e-mail - breaks the system or not. I hope not. John :: :: :: John D. Berry book design typography: http://home.earthlink.net/~typographer/http://home.earthlink.net/~typograp her/ dot-font: http://www.creativepro.com/author/home/951.htmlhttp://www.creativepro.com/ author/home/951.html Contemporary Newspaper Design:
Re: [WSG] double space after period - ADMIN THREAD CLOSED
THREAD CLOSED Thanks, Paul, for the very detailed information. However, as Richard has said, all opinions will have now been covered. The thread has run a very long and winding course. So, no more on this thread please! Thanks Russ great comments thus far, but i think we're getting into the area where things are being said twice or getting into wy too fine a point. when exactly does this thread get closed? r ** 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] double space after period
Paul Novitski wrote: Because there's such a mix of opinions about the value of double-spacing between sentences and its history, I asked my friend John D. Berry, typographer book designer of note, to give me the low-down on double-spacing to post to this list. __ At 01:50 PM 2/10/2005, John D. Berry wrote: As a general rule, no more than a single space is required after a period, a colon or any other mark of punctuation. Larger spaces (e.g., en spaces) are themselves punctuation. If we combine the comments by John D. Berry (which are in relation to printed media) with the previously mentioned idea that a double-space after a sentence might increase the legibility of text for dislexic users we could now start a whole new discussion: Are printed books accessible? Ooooh, this is going OT though. We need a whole new newsgroup: mediastandardsgroup.org ** 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] Peoplesoft and standards
Hi there, I am not too sure where else to ask about this. I have recently been part of discussions about the Peoplesoft application that we and many Universities use (not my fault) and its adherence to accessibility recommendations, and web standards. Peoplesoft claims to adhere to section 508.. Is this true? Looking at the default framed, JS dependant, table ridden code I don't believe it. Does anyone have any experience with Peoplesoft applications? We have PeopleSoft portal/financial systems deployed at work and my experience matches yours - they claim section 508 compliance but the *reality* is that they do not produce accessible or standards-compliant output. I can only assume the 508 thing was an automated check since no human would ever give it a pass. The key problem as far as I can tell is that most of the interface is *hard coded*, so clients can't actually fix the problems even if they are committed and willing to spend the resources. To make it worse, most organisations quickly realise that any modifications made will have to be redone every time PS issues a new patch or version increment. The result - orgs will lock down and refuse to make any modifications which are not absolutely required for the system to function. In short, I don't know how PS justifies their claims to accessibility; but they don't meet anything which could be described as good practice. The best thing PS clients can do is ensure that PS are aware that they are not meeting requirements in terms of standards/accessibility. This should be one factor included in decisions about whether to pay for upgrades. Big companies only care when they might lost money. All strictly IMHO, not an official stance of my employer ;) -- --- http://cheshrkat.blogspot.com/ --- The future has arrived; it's just not --- evenly distributed. - William Gibson ** 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] accessibilty and responsibility
Hi all, Jumping in on all these architectural analogies... nobody seems to have made this point: ultimately EVERYONE has some level of responsibility, since everyone is and will remain involed. Let's continue the analogy, for a new building: 1) The government sets out physical access requirements for buildings in broad terms (there are also other bodies which produce building standards but we'll keep this simple). Web equivalent is the W3C. Their responsibility is to get the standards right and communicate them in such a manner that people know what to do. They also need to keep things in the realm of possibility - W3C has a checkpoint to ensure that a proposed standard is actually possible, governments do not specify that venues provide levitating wheelchairs. 2) The architects (and possibly structural engineers) have to interpret the standards and apply them correctly in the design for the building. They will have to find the balance between the goals of the building and the many standards the building will have to meet. They also have to make sure the building won't fall down ;) The architect will probably also have to wrangle the interior decorators to ensure their wonderful additions don't contravene critical requirements. The web equivalent is the web developer, who has to sit between the client, the W3C, the graphic designer and the application developers/programmers. Some people might call this the Web Producer, but most of us don't get the lofty title nor the lofty pay ;) 3) Then the builders/tradespeople come into the picture. They are responsible for the actual physical creation of the building according to the plan. If they don't follow the plan they have failed in their own responsibility (ignoring the legal horrors of real-world architecture). Web equivalent is the web/application developer(s) who actually put the whole thing together. 4) The government inspects and enforces the standards. This area is starting to take shape for the web, with test cases appearing in various countries. It is a very weak area, though. 5) Then the public comes into the building. They will be arriving in wheelchairs which don't levitate, shoes with no grip, they might be drunk, who knows. Nobody who built the place can make them all wear decent shoes (so they don't slip on the stairs) nor can they make everyone's wheelchair levitate. Ultimately people should be allowed to choose whatever shoes they wear. But, they also have to accept falling down if they turn up drunk wearing shoes with no grip. The shoe/wheelchair manufacturers might be grossly negligent but they'll get away with it. Just like browser manufacturers get away with failure to comply with standards. No matter how well any one group/individual conforms to the overall goals; they will always have a responsibility since their part of the process must still be done well. Even if wheelchairs do start levitating, buildings will have to be designed and built with enough space allowed for them to fly around. Nobody will ever become free of responsibility. So 1) The W3C will always have to make good standards and update them. 2) Clients will always have to resource projects well enough to facilitate compliance. 3) Web developers will always have to apply standards properly. 4) User Agent manufacturers will always have to conform to standards. 5) Users will always have to maintain a reasonable level of technology to make use of the standards. The problem right now? Only (1) and (3) are currently happening with any level of success; with (3) carrying the hardest tasks. It's unfair but life is not fair. That's why web developers and architects like to go to the pub ;) h -- --- http://cheshrkat.blogspot.com/ --- The future has arrived; it's just not --- evenly distributed. - William Gibson ** 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 DO floats not stretch their containers?
John Horner wrote: * floated elements too big for the enclosing element spill out * except on IE, where they stretch the enclosing element that's a bit simplified, but essentially correct, right? Right. For instance, with this code: div style=width:300px;height:100px;border:1px solid black; DIV A div style=width:100px;height:300px;border:1px solid red;float:left; DIV B /div /div DIV B will overlap DIV A and continue down the page on its own unless you're in IE in which case A will stretch. Why limit it to floats? The same will/should happen to non-floats also. My question is, *why* is the correct behaviour the first one? It takes a lot of people by surprise and they often see what IE does as the natural and obvious thing to do. - div A has dimensions and they should be respected, - no matter the size of the content: div B, - except in IE/win, where we need workarounds. A standard-compliant browser will let us choose if we want the container to expand, or not. No height, or min-height only, on div A, and it will behave as in IE/win across browserland. So, we are given alternatives. IE/win has only one alternative: expand containers until the content fits inside. Logical for a weak browser, but not much for a web designer. Workaround in IE/win: http://www.gunlaug.no/contents/wd_1_02_02.html ... do the calculations that IE/win don't master. regards Georg ** 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] IE/Win Layout Gaps
My site ( http://www.feaverish.com ) looks as it should in Safari, Mozilla/Firefox, and IE 5/Mac. However, IE/Win produces strange gaps in the layout. My entire CSS is at ( http://www.feaverish.com/wp-layout_book.css ), but it is basically 3 divs inside a larger containing div. The three internal divs all have background images, making the page look like a book (with a fixed height/width top image, a fixed-width/variable-height middle image - for the main site content, and a fixed height/width bottom image). The containing div is absolutely positioned at the very right edge of the viewport. In IE/Win all three divs (or at least their background images) are shifted a few pixels to the left, ruining the look (you have to see the site to get it). Worse still, the bottom div, and its image, are spaced 50-75 pixels below the div above them, with a glaring whitespace gap in between! This totally ruins the continuity of the book, as the bottom div's image forms the bottom edge of the book. This is my first website, and the CSS is very amateurish, but it is XHTML 1.0 Strict and the CSS does validate. I've posted this problem in several design and coding forums but haven't received any help so far. Anything would be greatly appreciated. ** 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 DO floats not stretch their containers?
John Horner wrote: * floated elements too big for the enclosing element spill out * except on IE, where they stretch the enclosing element that's a bit simplified, but essentially correct, right? My question is, *why* is the correct behaviour the first one? It takes a lot of people by surprise and they often see what IE does as the natural and obvious thing to do. - div A has dimensions and they should be respected, But even if you don't give Div A a set height it won't expand. - no matter the size of the content: div B, - except in IE/win, where we need workarounds. A standard-compliant browser will let us choose if we want the container to expand, or not. No height, or min-height only, on div A, and it will behave as in IE/win across browserland. Sorry, I can't test my statement here, so if I am wrong please correct me, but as far as I remember taking out the set height (or min-height) of Div B will reduce Div A to 0 height. Floating Div B has got a similar effect to giving position:absolute - Div A will ignore the existance of Div B. ** 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 DO floats not stretch their containers?
Yeah that's true, a float won't expand its container, I've got assloads of div class=clearbothnbsp;/div to get around this. On Thu, 10 Feb 2005 18:07:51 -0800, Andreas Boehmer [EMAIL PROTECTED] wrote: John Horner wrote: * floated elements too big for the enclosing element spill out * except on IE, where they stretch the enclosing element that's a bit simplified, but essentially correct, right? My question is, *why* is the correct behaviour the first one? It takes a lot of people by surprise and they often see what IE does as the natural and obvious thing to do. - div A has dimensions and they should be respected, But even if you don't give Div A a set height it won't expand. - no matter the size of the content: div B, - except in IE/win, where we need workarounds. A standard-compliant browser will let us choose if we want the container to expand, or not. No height, or min-height only, on div A, and it will behave as in IE/win across browserland. Sorry, I can't test my statement here, so if I am wrong please correct me, but as far as I remember taking out the set height (or min-height) of Div B will reduce Div A to 0 height. Floating Div B has got a similar effect to giving position:absolute - Div A will ignore the existance of Div B. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help ** -- So come and join us all you kids for lots of fun and laughter While Roger Ramjet and his men get all the crooks they're after [ Josh 'G-Funk' McDonald ] -- [ Pirion Systems, Brisbane] [ 07 3257 0490 ] -- [ 0437 221 380 ] -- [ http://www.gfunk007.com/ ] ** 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 DO floats not stretch their containers?
At 1:01 PM +1000 11/2/05, Josh McDonald wrote: I've got assloads of div class=clearbothnbsp;/div to get around this. It's not just you! Why is that the (in some quarters) recommended solution, rather than just the break tag, with appropriate CSS to make sure it clears? ...and already we're off-topic. Have You Validated Your Code? John Horner(+612 / 02) 9333 3488 Senior Developer, ABC Online http://www.abc.net.au/ ** 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 DO floats not stretch their containers?
Josh McDonald wrote: Sorry, I can't test my statement here, so if I am wrong please correct me, but as far as I remember taking out the set height (or min-height) of Div B will reduce Div A to 0 height. Floating Div B has got a similar effect to giving position:absolute - Div A will ignore the existance of Div B. You're perfectly right, and I should have expanded my answer to the original question-- instead of the container. ;-) - whether the outer container expands with a float as content, or not, depends on what you define the container as. But that only goes in standard-compliant browsers. You can get what you want in all browsers but IE/win-- without any workarounds. Georg ** 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 DO floats not stretch their containers?
Josh McDonald wrote: Sorry, I can't test my statement here, so if I am wrong please correct me, but as far as I remember taking out the set height (or min-height) of Div B will reduce Div A to 0 height. Floating Div B has got a similar effect to giving position:absolute - Div A will ignore the existance of Div B. You're perfectly right, and I should have expanded my answer to the original question-- instead of the container. ;-) - whether the outer container expands with a float as content, or not, depends on what you define the container as. But that only goes in standard-compliant browsers. Can you give an example of where standard-compliant browsers expand the outer container with a float as content? ** 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] ie INSANITY ... please help me
Hi All, I am having SUCH a bizarre experience with IE. I thought I'd seen it all with that browser, but it still manages to fry my brain anew ... I have developed a site using valid XHTML and CSS, which can be seen here: http://www.manisheriar.com/queenbee/ Everything is working smoothly in FireFox and, with just a bit of tweaking, in IE too - EXCEPT ... The H1 for the first article (at the top left) does not display in IE. It does not show up at all, even though the code is exactly the same as it is for the following two articles. What shows up is just blank white space. As if that weren't enough, EVEN STRANGER ... The icon (small arrow) for the H2 (showing the author's name) shows up when the page first loads, but not after one has scrolled down and then back up. After that it disappears. Huh?!?!?! Once again, the code in this first article div is exactly the same as the following ones. I am baffled and simply at a loss. The code is pretty simple and straightforward and I cannot see anything that could be causing these oddities. What is going on here? Can anyone help me before I need to be put in a padded room? THANKS! Mani Sheriar Sheriar Designs | www.ManiSheriar.com 925|914.0741 ** 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] Fwd: [cfaussie] ANZ Regional User Group Meeting Next Wednesday 16th Feb 6pm for 7pm Star City
Hey Guys It might seem a little presumptuous posting this as its not purely standards related, but Russ was invited to speak on behalf of the WSG at this event last year and I think it really helped us reach a new audience and build some momentum. The WSG founders greatly appreciated this show of support for our fledgling group at the time - now its our turn to return the favour :) For those of you in Sydney, the Macromedia ANZ Regional User Group Meeting is on at Star City next Wednesday night. This is Day 0 of the MXDU conference and is a free/public event. Last year Sean Corfield, Director of Architecture at Macromedia, discussed the challenges of attempting to implement web standards on a site the size of macromedia.com - he is speaking again this year (about something or other) so it's bound to be interesting. Plus you've got two of the main Flash heads in world speaking about all things Flash and ready to answer your most difficult questions. See below for full details. --- Hello All, Another reminder, next Wednesday evening join us at Star City Darling Harbour, venue of MXDU, for the best speaker line up at any Macromedia User Group on earth this year! Mike Downey - Flash Product Manager, Macromedia Mike Chambers - Flash Developer Relations Manager, Macromedia Sean Corfield - Director of Architecture, Macromedia Richard Turner-Jones- Queensland MMUG Manager Join us as we discuss the next Flash player, the most interesting CF ideas blogged in the last year and some very cool Flash applications written for Airservices Australia that show pilots where all the restricted airspaces (and presumably surface to air missile installations) are. Speakers don't interest you? Well needless to say the cash bar opens at 6, so they should be interesting by 7. See you there! Robin Hilliard ANZ Macromedia User Group Coordinator --- -- Mark Stanton Gruden Pty Ltd http://www.gruden.com ** 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 INSANITY ... please help me
On Thu, 10 Feb 2005 22:31:48 -0600, Mani Sheriar [EMAIL PROTECTED] wrote: The H1 for the first article (at the top left) does not display in IE. It does not show up at all, even though the code is exactly the same as it is for the following two articles. What shows up is just blank white space. Under your #mainCol h1 rule, add position:relative; and change the background property to this: background: #d4bf34 url(../img/article.gif) no-repeat left center; Tested -- known to work :) The icon (small arrow) for the H2 (showing the author's name) shows up when the page first loads, but not after one has scrolled down and then back up. After that it disappears. Another case of hasLayout = false -- add height:1%; OR position:relative; both will fix the problem. What is going on here? Can anyone help me before I need to be put in a padded room? These bugs are both caused by IE's hasLayout property. hasLayout owes me 200 hours and a large piece of my sanity. Welcome to the club ;) note to all: IF IN DOUBT, add position:relative; -- it fixes many, many IE bugs :) Andrew. http://leftjustified.net/ ** 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 INSANITY ... please help me
On Feb 10, 2005, at 9:31 PM, Mani Sheriar wrote: The H1 for the first article (at the top left) does not display in IE. It does not show up at all, even though the code is exactly the same as it is for the following two articles. What shows up is just blank white space. The icon (small arrow) for the H2 (showing the author's name) shows up when the page first loads, but not after one has scrolled down and then back up. After that it disappears. Huh?!?!?! Once again, the code in this first article div is exactly the same as the following ones. What is going on here? Can anyone help me before I need to be put in a padded room? At least stay half way out of the padded room. :) All works well in Mac IE. BTW, I'm liking the renditions you have made to the aesthetics of the site since I saw it last. No Windows here to help with the rest. Sorry. Shane Helm sonzeDesignStudio www.sonze.com ** 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 INSANITY ... please help me
-Original Message- From: Mani Sheriar [mailto:[EMAIL PROTECTED] Sent: Friday, 11 February 2005 3:32 PM To: wsg@webstandardsgroup.org Subject: [WSG] ie INSANITY ... please help me Hi All, I am having SUCH a bizarre experience with IE. I thought I'd seen it all with that browser, but it still manages to fry my brain anew ... I have developed a site using valid XHTML and CSS, which can be seen here: http://www.manisheriar.com/queenbee/ Everything is working smoothly in FireFox and, with just a bit of tweaking, in IE too - EXCEPT ... The H1 for the first article (at the top left) does not display in IE. It does not show up at all, even though the code is exactly the same as it is for the following two articles. What shows up is just blank white space. As if that weren't enough, EVEN STRANGER ... The icon (small arrow) for the H2 (showing the author's name) shows up when the page first loads, but not after one has scrolled down and then back up. After that it disappears. Huh?!?!?! Once again, the code in this first article div is exactly the same as the following ones. This sounds a bit like the peekaboo bug to me? Try this: http://www.positioniseverything.net/explorer/peekaboo.html ** 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 DO floats not stretch their containers?
On 11 feb 2005, at 00.17, John Horner wrote: My question is, *why* is the correct behaviour the first one? It takes a lot of people by surprise and they often see what IE does as the natural and obvious thing to do. I'm not trying to start a flame war, I really want to know! Eric Meyer's Containing Floats article explains it pretty well: http://www.complexspiral.com/publications/containing-floats/ /Roger -- http://www.456bereastreet.com/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
