Re: [WSG] working with line-height
Ben Lau wrote: http://www.hellobenlau.net/wsg/index.html I'm wondering if there was a way to top align the text to its line-height. So say, with text size 20px, could the top of the 'T' be aligned to the top of the pink box? Is this what you want? http://www.gunlaug.no/tos/alien/bl/test_09_0702.html Note that you can't really get pixel perfect alignment across browser-land, as there will always be some em-to-pixel rounding deviation. Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] working with line-height
Ben Lau wrote: This is what I'm trying to achieve: http://hellobenlau.net/wsg/eg.gif So there'll be a div with padding top and bottom of 20px, and with text inside. If I do: div style=padding:20px 0 psome text/p /div The gap would include both the padding and the anonymous inline boxes (thanks Russ), which works out to be 20px. Could there perhaps be a way to calculate the amount of white-space for these anonymous inline boxes? Set the line-height in em, and approximate apparent whitespace for the chosen font family - also in em, and you'll get something like this... http://www.gunlaug.no/tos/alien/bl/test_09_0702-b.html ...with the same amount of whitespace (only the pixel-sized div-padding) on top and bottom of div, regardless of font-size. I have broken one paragraph in two, but you can use separate paragraphs if you give the top and bottom one classes and only subtract the apparent whitespace from top and bottom respectively. I'm not trying to achieve exact look across all browsers, I understand it's impossible. But I'm trying to achieve to make it look like the design at least.. in 1 browser (just so my designers are happy). Visual designers don't care much about reality on the web, so they should be easy to please ;-) FWIW: I often pull paragraphs and headlines this way, and most browsers handle it quite well. I usually don't bother to count pixels though, as in most cases it just has to look right. Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] a bizzare background image disappearing bug in IE
tee wrote: Two divs wrap - background image not showed up in iE6/7 http://lotusfromthemud.com/gbtv/products.html Old IE usually doesn't render an absolute positioned element when it is next to a float in the markup. In that particular case: move the div class=tvimg below the div class=clear in the markup, and old IE will render it. See: http://www.brunildo.org/test/IE_raf3.html for more on the issue. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE8 compatibility mode
Eyemax Studios wrote:
You can have a look, it's www.studiojunkyard.com I would be more
inclined to fix it, when have time hehe.
Well, it definitely isn't what Microsoft believes the Standards should
be. All KHTML/WebKit and Presto browsers agree with IE8 (in Standards
mode), and only Gecko browsers and older IE are missing the
points/standards.
Neither IE's old 'hasLayout' bug nor the particular margin-collapse
behavior in Gecko can be relied on in IE8 and the other browsers. The
'hasLayout' bug is gone in IE8 (in Standards mode).
Try adding/changing to...
.content1, .content2{margin-bottom: 0;}
.home{padding-top:110px;margin-left:90px;background:transparent;}
* html .home{margin-top:110px; /* IE6 */}
*:first-child+htmlbody .home{margin-top:110px; /* IE7 */}
...for that particular page, and all browsers will line up - in
accordance with standards.
Doesn't prevent your page from looking a bit broken when subjected to
font resizing in all browsers though, I'm afraid.
regards
Georg
--
http://www.gunlaug.no
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] IE7 CSS fix
James Ducker wrote: Can you not use a conditional? Of course one can. It's far more reliable than CSS hacks, which may cause problems in future browsers. I don't agree with that assessment, providing one work a bit on selecting the right CSS hack and don't just use any hack because it seems to work. However, I have problems seeing why one would want/need to serve IE7 a different padding anyway - regardless of method, so I won't discuss hacking-method without seeing the case it is supposed to solve. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE7 CSS fix
michael.brocking...@bt.com wrote: To my mind, that is the definition of a CSS hack - it is abuse of a bug that is believed to only apply to the required browser(s) Mmm. One exploits a bug to kill/fix another bug, and triggers an unknown number of bugs in various browsers - present and future versions - in the process. Before one knows it one has a complete bug-house :-) There is almost never a direct correlation between the bug and the 'fix' that is being applied. True. Not a problem if the hack is proven to only work in the browser/version that needs the fix, but few test and study progress in standards and implementations in browsers well enough to make sure a hack can't misfire and end up serving the fix to the wrong browser/version. Even many CC for IE are made universal, and end up serving bogus fixes to the wrong versions. Regarding future editors: in my experience there's more of a chance that they'll break the entire work while tidying up, than that they'll break just a hack or two. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE7 CSS fix
Alex wrote: I dont understand why anyone needs to hack anything. If you design to web standards and use a logical structure/layout with good use of floats or positioning, you can develop a page/layout that works in all browsers. It usually takes a bit of tweaking but it can be done. Sure, but such tweaking often ends up on level with what the weakest browser can handle, and thereby holds back better browsers. No progress in that, IMO. When one wants more, one has to aim for what works in better browsers and correct/nudge/fix weaker browsers until they appear to do reasonably well - without disturbing better browsers in the process. Simple tweaking usually falls short then, and one may have to look at other options. I thought this group was discussions of all things relating to standards and not support of people using non-standard ways i.e. hacking/conditional comments. There's nothing much to discuss about existing standards apart from obvious unclear and/or incomplete passages and the occasional typo in same documents. Anyone can read the relevant documents on standards for themselves. Browser-support, or lack of same, for standards, is what most often triggers discussions, and I believe that's the case in this thread too. (Of course: this thread may have been initiated by a designer bug, but there's no proof of that yet.) regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE7 CSS fix
Prashant wrote: I have tried the following but for some reason IE7 is picking IE6 hacks only - Which means IE7 is in Quirks Mode - on level with IE5.5. Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE7 CSS fix
Alex wrote: Blimey, you norwegians are a tad opinionated. Nah, we just just like to be given a valid reason for changing our minds. Comes with the territory - we never take the easy way out since there isn't any in this country :-) What does 'one' actually think 'one' is going to acheive in developing for modern browsers over the older ones? Progress. It may be slow, but it is inevitable and sure better than nothing. You make it sound like modern browsers have a host of features that are going to turn your website/s into an all dancing and singing awe inspiring experience that the older browser is just going to merely mimick after you have bodged it up with hacks and tweaks. Oh, old browsers can't do much dancing and singing no matter what, so 'one' (or another) may as well stop trying so hard. Yes, modern browsers do, obviously, provide a more complete and bug free standard support platform. Dancing and singing is slowly edging its way into standards too, so those who like that kind of stuff may have a go at it - but of course only in the very latest and more experimental browser versions... http://www.css3.info/four-new-w3c-modules/ Broader support may be provided tomorrow, if there's a demand for it. The majority of businesses use typically older versions of ie that are typically on XP builds and they 'typically' couldnt give a monkies or even have any knowledge about better or newer browsers. Thanks for presenting the (very well known) state of the business world - stagnation and regression everywhere. (No wonder the world as a whole is in such a mess right now.) Sorry, but this Norwegian can't see the point in being stuck in the past just because someone else thinks that's good enough. Life's too short, and after having worked in front of these screens for nearly thirty years I'm getting a bit bored and impatient. Anyway...thought I would give Gunlaug something to chew on...(cheer up son). Yummy :-) Got more? regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE7 CSS fix
Prashant wrote:
I need to implement a padding-left:65px in IE7.
Which mode is IE7 in for your document?
Hacks like...
*:first-child+html #foo .bar {...}
...will only work in IE7 Strict Mode. If it doesn't work in Strict
Mode, then something is overruling it.
Georg
--
http://www.gunlaug.no
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] IE8 compatibility mode
michael.brocking...@bt.com wrote: http://www.calcresult.com/reference/text/unicode-reference.html The rendering of that page is slightly broken (at the moment) in IE6 and IE7 in that the right-hand column overlaps some of the content. What confused me though, was that IE8 insisted on rendering in 'compatibility mode' otherwise known as IE7 mode, even though the rendering is correct when I worked out how to force it into IE8 mode. That page is clearly rendered in IE8 standard mode by default at my end. Check internal settings in IE8 at your end, and make sure you don't mix those two modes. If in doubt, place this meta in page head... meta http-equiv=X-UA-Compatible content=IE=edge / ...and the Compatibility view button will disappear in IE8. The start html tag is missing in your page - you have doctype directly followed by head. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE8 compatibility mode
tee wrote: Sorry for my ignorant, is IE8 out? Yes, as of March 19th. Keep an eye on a site like this... http://www.upsdell.com/BrowserNews/ ...and you'll at most only be a few days off regarding new releases. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] IE8 compatibility mode
James Leslie wrote: Using meta http-equiv=X-UA-Compatible content=IE=8 / will also have the same effect (getting rid of the compatibility view button and forcing standards mode), but may be a bit more stable against future releases of IE. But, may also lock documents to IE8's rendering capabilities even if future IE releases can handle more, better - which they should. Not very wise, IMO. You wouldn't choose/advice such a safeguard strategy for any of the other browsers, would you? IE8 does have a few dozen irritating bugs and weaknesses, and is (pretty much) limited to CSS2.1. However, IE8 final is pretty stable and works quite well for all properly built sites, so one can say Microsoft has done an acceptable job. No signs they'll jump off the standards path either now that they've finally got on it, even if they're a little behind the others. What's holding IE8 back now is all those sites that has been safeguarded and tailored to work in earlier IE versions as if there was no tomorrow, and it is about time we stop treating IE as a browser that will be in need of special solutions forever. Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Safari Beta 4
tee wrote: By the way, Google Chorme behaves as Safari does. Not during my testing, but that may be conditional. Conditional is problematic since that mean behavior may change with factors like OS and connection speed = highly unreliable. Tested Chrome, OmniWeb and Arora - all complete WebKit with unique script engines. All behaved more or less like the latest versions of Firefox, Opera and IE8 - not like any Safari version on any OS. Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Chrome now higher traffic than IE
Mike Kear wrote: For the first time since I started building web sites, IE is not the most prominent browser on my two highest traffic sites. Of course other sites will have a different pattern, depending on the audience. Not entirely new, but much broader... http://www.xitimonitor.com/en-us/browsers-barometer/browsers-barometer-november-2008/index-1-2-3-153.html regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Safari Beta 4
tee wrote: Thanks for checking. Adding the above rule makes the thumbnail unclickable when no thumbnail shows up. If I refresh the browser to make thumbnail shows up, then it's clickable. Yeah, the various Safari versions show very different behavior for the script. - Safari 3.2.x indeed behaves as you describe, but doesn't behave in a stable manner. Extra rule fixes distortion, but Safari's script-engine fails on that script quite often. - New script-engine in Safari 4, and in that version the thumbnail isn't clickable even when the image shows up just fine. The new script-engine seems to fail on that script every time, but very different from the older version. - More as a curiosity: Safari 2 fails in ways more like Safari 4 than like Safari 3. - Other WebKit based browser - those that are not just shells, got their own script-engines and behave just fine. So, Safari is a moving target for scripts, each script-engine version with its own unique failures in your case. Need an expert on jquery and script-engines to work around the problems in that browser, but the extra CSS rule does fix the distortion problem in all Safari versions. Without that rule, empty thumbnail box is still clickable. Not quite so easy, it seems. Note that what you see as empty thumbnail boxes in Safari (without the extra CSS rule) aren't necessarily empty. Those images are just blown up so large, and only the middle-left portion is shown, that the objects end up hidden outside the list-item box. Thus, the image is often there in Safari too, and therefore clickable, even if you can't see the object. Safari fails to load the image just as often with and without the extra CSS rule, so that rule doesn't seem to have any negative effects. Find someone who can fix Safari's various script-engines, and once the loading and layering works in all Safari versions you can find out if the extra CSS rule is necessary to fix the distortion problem. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Safari Beta 4
tee wrote:
On this site, in Safari (PC and Mac) you will see that the
thumbnail(s) in the gallery (jquery galleria) is either not showing
up or the image gets distorted (should be 80px). You may not see it
from the first visit, should this be the case, please click on other
page, then come back to the same page.
http://citicomm.net/bluetooth-accessories/plantronics-discovery-925.html
I can only test so far on a snapshot, but it looks like Safari 3.2.1 and
Safari 4 beta1 behaves well when image-dimensions are styled on class
gallery - not just galleria. Also seem to improve transition in
Firefox 3, which otherwise flashes terrible IMO.
Try adding...
.gallery li img {width: 80px!important; height: 80px!important;}
...which will calm down the script a bit without ruining its operations.
regards
Georg
--
http://www.gunlaug.no
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: memberh...@webstandardsgroup.org
***
Re: [WSG] Safari Beta 4
daniel wrote: it would be much more interesting to discuss IE8's compliance again. All compliant sites that I've made render fine in Safari 3 4 and FIrefox 3 but always fail to work 100% on IE... It isn't about standard compliance for your sites, but which standard IE8 is limited to - CSS 2.1 pretty much... http://msdn.microsoft.com/en-us/library/cc351024(VS.85).aspx Trying to do anything more advanced in IE8, is doomed to failure. Add a few bugs - surprisingly few for the average site, and you may as well roll your design back a bit. Test in earlier Gecko and WebKit versions too, as many browsers in regular use use those older engines. side note: I've been using Safari 4 for a couple of days and I absolutely love it - it loads and renders pages much faster than FF and JS intensive pages are faster then ever - besides, who really uses Opera anyway?! :-) Nothing but! I'll leave further commenting to someone who knows more... http://www.gunlaug.no/contents/molly_1_25.html ...and Safari 4 beta will be put through a round of thorough tests too... http://www.gunlaug.no/contents/molly_1_26.html ...while we're waiting for the finals. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Accessibility testing
Jon Gunderson wrote: http://faetest.dres.uiuc.edu Please let me know what you think of it. First impression: good. Informative page reports. A few points... 1: i and b can in many cases not be replaced by h1..h6 or em and strong. Both i and b are valid - span-like (no implied semantics) - elements in HTML4/XHTML1, and are (so far) kept that way in (X)HTML5. The existence of b and i should not be called a failure. 2: according to specs (and browsers) a character encoding stated in an xml declaration is good, and further stating unnecessary. No warning should be given in such a case. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Accessibility testing
David Dorward wrote: Gunlaug Sørtun wrote: 2: according to specs (and browsers) a character encoding stated in an xml declaration is good, and further stating unnecessary. No warning should be given in such a case. An ?xml ? declaration (or anything else before the Doctype) will trigger Quirks mode in IE6 [...] IE6 works best in quirks mode... http://www.gunlaug.no/contents/wd_additions_16.html ...IMO, so that's a very welcome side-effect. so should be avoided. FWIW: anything other than an xml declaration before doctype will make _all_ IE/win versions stay in quirks mode. The prolog is optional if the defaults (XML 1.0 and UTF-8 or UTF-16) are used. Which means one can deliberately choose to put the xml declaration in, and its 'encoding' is valid and honored. That's my point. It is forbidden if HTML 4.01 is used. Indeed. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] a Div tag won't pick up the height of a floated image?
Brett Patterson wrote: Will a div tag pick up the height of an image that is floated left? Only if the div is styled to contain floats... http://www.gunlaug.no/contents/wd_example_01.html Lots of options linked in on that page. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Implication of empty divs
Ben Lau wrote: But as far as i know, screen readers do not pick up IDs or classes? So even by declaring a div ID=mainNav, it's still not enough to describe what's inside the div? I'm starting to get awfully confused... A div is an element primarily intended for grouping blocks of content - hence it defaults to block with no further default styling or meaning in most UAs. The meaning of IDs and classes is mostly on your (designer/developer) side of the fence, when you work on the markup. Normally not enough artificial intelligence at the other side (user-end) to interpret the meaning of IDs and classes. Well-chosen headlines with suitable text at or near the beginning of each area make more sense there. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Implication of empty divs
Ben Lau wrote: Are there any (seriously) bad implications of having empty DIVs around your HTML document? I understand from that that you mean nested divs, for multiple backgrounds etc. A few extra divs means nothing other than extra weight, but I have managed to break a few older browsers by going to the extreme. This is extreme nesting... http://www.gunlaug.no/contents/wd_demo_float_03.html ...where not only the regular layout has deep nesting, but where there's also a demo consisting of deeply nested divs in the middle of the main content area. IE5.01 usually gives up on it - freezes during load, and this is caused by the demo. Later IE-versions don't seem to have real problems with it. Some older Opera versions tended to slow down and/or freeze up when the completely loaded page was scrolled, also caused by the demo. Haven't noticed any problems in 9.5+ versions. All browsers work ever so slightly harder than usual to get all pieces of the demo lined up during scrolling. So, it is possible to go too far :-) regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
Brett Patterson wrote: [...] Now I realize where most of my problems have stemmed from. Note that nearly all such designer bugs will be caught if you follow WCAG2 recommendations and resize text in a browser to at least 200% of browser default. (Default is 16px on 96dpi screen resolution in nearly all browsers, so 200% will be 32px on that resolution. Numbers grow with higher screen resolutions, but browser do not yet agree on how to deal with / adjust for rising screen resolution.) - If you can't resize text in the browser, then it's probably IE and the font-size unit is the wrong choice. Time to re-think design. - If design/layout breaks in unacceptable ways when subjected to font resizing stress, then the design/layout is at fault. Time to re-think design. Nothing you can do to prevent end-users from stress-testing your creations - because they want to or because they have to, so it is always best to test beyond breaking-point across browser-land before release. In the end you as designer/developer, consciously or unconsciously, decide how much your creation(s) should be able to take before it becomes unacceptable. FWIW: I didn't stress you layout on first load in any browser, but it showed serious shortcomings anyway. Later when I did put it under stress by applying regular browser-options to it... http://www.gunlaug.no/contents/wd_additions_37.html ...it revealed its weaknesses. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
tee wrote: IS 200% one time font size increasement or two? 200% is twice the default size, and the number of steps to get there varies from browser to browsers. Again: _default_ isn't whatever size you have declared in/for your document, but the browsers' own defaults. This default font size is what you see on your screen(s) when you do not declare font-size at all in your documents. Then, make the letters in the text twice as tall in the browser itself, without zooming the page as a whole. That is 200% font resizing - the kind that actually works for end-users. My practise for a good layout is two times increasement, and I try to accommodate one decrement, but sometimes with certain design layout, especially with floated elements that either one or both have background image(s) that the underneath div block has different background color, it's just too much work to take good care and I let it goes without guilt :) Guilt would be misplaced no matter what, and shouldn't be an issue. No matter what you do you're in good (or good) company :-) It is however your creation that gets broken if it can't take a reasonable amount of the stress it risks getting exposed to when end-users use their browsers as designed, so you can't complain about it being broken either. That foreground and background get somewhat detached here and there is quite normal, and in some cases unavoidable with today's browsers and standards when background-images are used. Resizing of background-images to go with containers is only implemented on an experimental level in one or maybe two browsers - have only seen/tested it in Opera. We have only the tool-set that is available in browsers at any given time to play with, and when that tool-set isn't sufficient we either have to scale back our, or our clients', ambitions and use somewhat safe solutions, or we have to accept that our designs break. Minimizing the problems caused by breakage at the user-end is an important part of web design IMO, and trying now certainly makes it easier to pick up and make use of new design tools as they become available to us. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
Brett Patterson wrote: Okay, one quick question. You say 200% is twice the default size, but in browsers like Firefox 3, there is only the (shortcut) Ctrl++ to zoom in, and I cannot find the percentage of that zoom, so is 200% font size increasement one or two clicks? Much more than that, I'm afraid. Side-by-side comparison and measuring on various OSes (96dpi res. all to avoid any misunderstandings) reveals the following: - Firefox (3.0.5 3.1b2) seems to increment in 10% mouse-wheel steps for both 'text zoom' and 'whole page zoom'. That means 10 steps (or clicks) from default to 200% of default for both zoom variants. - IE8rc1 increments its 'whole page zoom' in 5% mouse-wheel steps, with the usual +/- 2steps a' 25% for 'font resizing'. The latter only allows for 150% of default. - Opera (all versions) increments its 'whole page zoom' in 10% mouse-wheel steps. - Konqueror seems to increment in 10% mouse-wheel steps for both 'text zoom' and 'whole page zoom'. -- Note that 200% resizing means each letter take up 4 times the space compared to on default size, regardless of zoom variant. Simple square calculation. So, calculating in a one or two clicks range while designing, doesn't count for much. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
David Dixon wrote: Not quite right im afraid. Patrick Lauke sent an email about this in December that highlighted the Firefox zoom config as shown below: -- Quote -- toolkit.zoomManager.zoomValues, and this will show the various zoom factors at each step. In my case (which should be the default) these are: .3, .5, .67, .8, .9, 1, 1.1, 1.2, 1.33, 1.5, 1.7, 2, 2.4, 3 So, nominally 200% (which, according to the Understanding... bit for that SC, means 200%, that is, up to twice the width and height - so really a 400% increase in total area) is actually 6 steps, if you want to go purely by numbers. -- End Quote -- David Ok, but then 200% 'whole page zoom' in Opera and IE8rc1 is _much more_ than 200%, because when I overlay Firefox (3.0.5 3.1b2) with 'text only zoom' on any of these two (Opera and IE) at that 200% 'whole page zoom', I need 10 mouse-wheel steps up from default (100%) to reach the text-size and line-height they're at (at 200%), as shown below. Gunlaug Sørtun wrote: Side-by-side comparison and measuring on various OSes (96dpi res. all to avoid any misunderstandings) reveals the following: - Firefox (3.0.5 3.1b2) seems to increment in 10% mouse-wheel steps for both 'text zoom' and 'whole page zoom'. That means 10 steps (or clicks) from default to 200% of default for both zoom variants. Both Opera and IE8rc1 have 'whole page zoom' selectors showing 200% as a value - seen in the lower-right corner of their chrome, and I can't imagine that these two (competing) browsers agree that 200% means exactly the same and that this same value is then *not* really 200%. I also cross-checked using the same screens (96dpi res.), OSes (win2K, XP, Vista, Ubuntu) and mouse/keyboard (connected via Synergy), and can't find the cause for my errors. Rounding-errors caused by trying to hit the same number of screen pixels at the same resizing levels via different calculation algorithms, become insignificantly small at 200% resizing level. Maybe someone can do a control check, measure the actual sizes on screen for zoom values and mouse-wheel resizing steps for 'text resizing' vs 'full page zoom' set at shown values, and let us know the results. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
Gunlaug Sørtun wrote: Maybe someone can do a control check, measure the actual sizes on screen for zoom values and mouse-wheel resizing steps for 'text resizing' vs 'full page zoom' set at shown values, and let us know the results. Just to make sure we're resizing the same way: notice that I refer to mouse-wheel steps everywhere, and not 'view drop-down options' or keyboard 'ctrl + +'. These non-mouse resizing options have 6 steps from 100% to 200% in Firefox - as Patrick Lauke presented it, for both 'full page zoom' and 'text only zoom'. Guess that accounts for my error :-) regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
Brett Patterson wrote: If my site is visited in Firefox or Internet Explorer first, you can see that everything aligns perfectly. Not if that browser is called IE8, I'm afraid. IE8 agrees with Opera10alpha. http://ttcharriman.edu/TTCH07/iftprojects/brettpatterson/index.html It's a designer-bug. Vertical position of the navigation relies entirely on font size, which means it is all over the place in my browsers on first load. No two browsers calculate font size exactly the same before rendering, so relying on pixel-perfect font size across browser-land is not a good idea. Add in font resizing and other regular options in browsers, and it gets a lot worse - for the whole layout. You should rethink the positioning method, and forget about deviations between browsers until you have stabilized it in one. FWIW: there are no reliable ways to target Opera anymore. You can't even know for sure if Opera is Opera. Besides: one should only target/hack dead browsers, like IE7 and older. Targeting/hacking live browsers like Opera, Firefox, Safari etc. for real, will only create maintenance-problems as new versions arrive. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
Christian Montoya wrote: On Tue, Feb 3, 2009 at 2:41 PM, Gunlaug Sørtun gunla...@c2i.net IE7 is dead - meaning: stable, Ah, well, most people would consider dead and stable to be two entirely different things. Dead is more akin to abandoned or unsupported. OK, guess my choice of word can easily be misunderstood. I consider software to be dead and stable the moment a real successor is on its way, and the old piece isn't upgraded any more and can be safely separated from all others. IE7 is there now, IMO. I place FF2 in the same category btw, although is is slightly harder to separate it safely from its successor - FF3. And it's still entirely possible that while Microsoft is supporting IE 7, they could release a patch for it, if they ever decide they need to. IE7 is supported in the sense that it gets security patches and alike when there's a need for it. Its rendering engine won't see any major upgrades, simply because of Ms fear of breaking the web. That fear has been sufficiently documented and demonstrated by now. IE8 is the major upgrade of/from IE7, and the only potential problem here is that IE8 will not be able to emulate IE7' rendering perfectly down to the minutest details and combinations - there are simply too many details and combinations to test and tune. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
Brett Patterson wrote: You should rethink the positioning method, and forget about deviations between browsers until you have stabilized it in one. I do not understand this either, unless you are talking about using margin as the positioning method. I have stabilized it one browser. This is why I am worried about the deviations in all the others. Apply font resizing in any browser, and you'll get larger positioning-errors for the menu in _that_ browser than you get between browsers when leaving all at their font size defaults. Same version of same browser (Firefox 3.0.5) with similar settings on different OSes already position the menu with much more that 1px deviation - more like 20px, so I had to check across my entire browser/OS range to see where you really wanted that menu to stay on the page. Sorry, but that doesn't look stabilized to me. My point is that elements are not styled to work well together under even the slightest amount of stress in any browser, which means it is much too early to correct 1px deviations in any of them. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Opera Targeting?!
David Dixon wrote: Chomping at the bit to dismiss IE7 a little early aren't we Georg? :) :-) Look at IE7 from a designer/developer's point of view... IE7 is dead - meaning: stable, so if it acts up and there isn't a suitable solution that all browsers can see, there's no harm whatsoever in hacking its dead body to pieces. IE7 can't come back to haunt us, no matter how many users it has. No other browser/version will ever see what we feed IE7 only - with the right targeting method, apart from maybe IE8 (and probably its successors if it gets any) when it mimics IE7 in (backwards) compatibility view. Gunlaug Sørtun wrote: Besides: one should only target/hack dead browsers, like IE7 and older. Targeting/hacking live browsers like Opera, Firefox, Safari etc. for real, will only create maintenance-problems as new versions arrive. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Clearing a row with floated list li
Paul Collins wrote: I can add a class of clear to every third list item, which is great, but I'm still having troubles in getting them to behave in IE. Has anyone got a solution, or seen on online lately?! Didn't check for the actual case, but it's usually safer to declare 'clear: left' than 'clear: both' when trying to clear left-floats in IE. IE has quite a few 'clear' related bugs, and I think this is one of them. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Parenthesis around list counters
James O'Neill wrote: We are a small county displaying our ordinances and parens are important for legal notations and references. If such details are important, they should be written in plain text. Regardless of whether a method is found or not, one can not rely on browsers support for HTML/CSS to replicate importance at such a level. Simplest way to test if a method is acceptable or not for a particular case, is to observe the outcome with CSS and script support off - in Lynx for instance. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Re: Users who deliberately disable JavaScript
Paul Hudson wrote: Doesn't ie6's highest security setting turn js off? Yes, and all that goes with it - like IE-expressions. I haven't looked at ie7 but would assume similar. IE7 same as IE6. From the look of it - brief testing - IE8b2 also turns off script-support in high security mode. Statistics are as unreliable as they ever were, but one can deduct from crawling around in stats and reading various stat-based conclusions that 5 to 10% of web surfers have javascript support disabled - at least on some sites, or use browsers with no script-support - not many of those. Don't think one can get any closer. No real indication that javascript support disabled is on the rise, but not that it falls either. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] Chrome and Safari render the same...or do they?
Jens-Uwe Korff wrote: I'm running into big rendering differences between Google Chrome and Safari 3.1/PC. They are said to render pages the same, given that they're using the same Webkit engine. They're using the WebKit engine, not necessarily the same version. Safari is at version 3.2.1 last I looked BTW. The differences seem to be mainly due to the different font rendering. Safari's fonts are way smaller, hence my boxes are smaller and shift up, breaking the layout. All my testing concludes that Safari's fonts show up ever so slightly larger than Chrome's and other browsers' on same OS (XP Vista), but these differences are insignificant and may only occasionally cause earlier line-breaks in Safari. Would be interesting to see your example page to see if your way of styling can cause the differences you experience, or if they're caused by you setting those browsers different locally. --- No, there are no Safari vs. Chrome CSS hacks, and I hope no-one ever find or at least not use any since it'll probably do more harm than good and hit a number of other WebKit based browsers. It'll probably also target designer-bugs that are counteracted in the next versions of WebKit based browsers, and create problems that way. One should never hack live browsers. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] pos- relative or margin?
Naveen Bhaskar wrote: I have seen a page where all the divs are positioned with position relative and with top , bottom attributes instead of margin.. Is this a good method? Depends entirely on the actual layout. I often use both relative offset and margin push/pull on the same elements. Position relative doesn't move the element, only offset it visually - the element still takes up space in its original, non-positioned, position. Margins affects the element's actual position. When used on floats margins can remove the element-space partly or entirely. There is no browser compatibility issues while using this where as when using margin properties IE has probelms. IE6 has serious problems with position relative in certain combinations, but provoking bugs with margins isn't a problem either in that old bugger. IE7 is better but far from flawless. IE7 and older introduce positioning and margin problems related to 'hasLayout'[1], where the cure for one bug often causes more problems than the disease. regards Georg [1]http://www.satzansatz.de/cssd/onhavinglayout.html -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] issues with too many divs
Ben Lau wrote: Are there any major downfall in doing so apart from increasing page size? I'd like to be able to convince our designer to simplify the design... No UA will have problems with a dozen or so extra wrapper-divs around every single element in a page - doesn't even have to be valid nesting, so that in itself won't give you arguments for simplifying a design. Complex imagery in designs tends to lead to failures when exposed to font-resizing and other normal user-induced challenges - background-images don't scale with foreground, so it's probably easier to find arguments for a simplified design on the accessibility/usability side of web design. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
Re: [WSG] HTML/XHTML/XML - Question about the future of.
Benjamin Hawkes-Lewis wrote: David Hucklesby wrote: The validator still needs a DTD though. If you mean the W3C validator, then no, it just got experimental HTML5 support. And the W3C validator misinterprets XHTML5 to be some lesser XHTML flavor... http://qa-dev.w3.org/wmvs/HEAD/check?uri=http%3A%2F%2Fwww.gunlaug.no%2Fxhtml5-en.xhtml ...so it is a bit too experimental to be of practical use today. The http://html5.validator.nu/ validator OTOH gets it right... http://html5.validator.nu/?doc=http%3A%2F%2Fwww.gunlaug.no%2Fxhtml5-en.xhtmlshowimagereport=yesshowsource=yes ...and is also useful for checking details. The W3C validator gets HTML5 alright, but I'm not sure if it gets it right... http://qa-dev.w3.org/wmvs/HEAD/check?uri=http%3A%2F%2Fwww.gunlaug.no%2Fhtml5-en.html ...since the http://html5.validator.nu/ comes to another conclusion... http://html5.validator.nu/?doc=http%3A%2F%2Fwww.gunlaug.no%2Fhtml5-en.htmlshowimagereport=yesshowsource=yes ...obviously because I've left the xml declaration in there. So, the future doesn't change the HTML vs. XHTML-XML relations, or lack of same. We will still have one standard, that can be applied to the web in (at least) two different ways... http://www.w3.org/QA/2008/01/html5-is-html-and-xml.html ...if they don't change something in the xHTML5 spec in the near future. Of course, only HTML can be widely used, as long as XHTML isn't supported by the most used browser. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] HTML/XHTML/XML - Question about the future of.
Andrew Maben wrote: XML is not going away, so by all means hope for an XHTM revival somewhere down the road, but for now, if it's text/html then shouldn't it be HTML as HTML, and not XHTML treated as HTML? IMHO, naturally, and of course YMMV. Of course. We have choices and preferences :-) Since HTML5 allows XHTML syntax more or less all the way, it doesn't really matter which flavor the document is coded in as long as it is served as 'text/html' ... and provided with the proper standards mode triggering doctype on top. It's just a trigger anyway. Since I personally wouldn't dream of intentionally letting IE6 switch to its not very standards compliant 'Strict' mode, while at the same time I definitely want IE7 and 8 and so on to obey W3C standards as best they can, I'll probably plug in an xml declaration on top no matter which mode-trigger I use - even if it's declared non-valid. So 'text/html' it is, and probably will be for most coders for a long time - maybe until internet as we know it is obsolete, and most of it will probably be non-valid and subject to error-recovery until the very end. I personally don't think the xHTML5 standard will have much influence on markup quality as such, although I'd love to be proven wrong on this point. Serving properly coded documents as 'application/xhtml+xml' is nice when one wants to push the boundaries and/or add in something that doesn't work when served as 'text/html', and knows those at the receiving end got a proper browser (or something else) that can handle it all. We're already filtering out weak, old and obsolete browsers from stuff they can't handle - from CSS for instance, or ignoring these browsers' existence entirely. Thus, letting weak browsers filter themselves out from everything, can be an interesting option, at times. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] HTML/XHTML/XML - Question about the future of.
Brett Patterson wrote: From the few recent posts, I have become so far confused, as anyone would as to why, Gunlaug, you keep stating xHTML5 or as above you say XHTML5? HTML and xHTML/XHTML are different. xHTML is XHTML, albeit 1.0 or 1.1 or 2.0 etc. So, is it a typo? No typo, but I understand the confusion. We may call it 'HTML5', '(x)HTML5', 'xHTML5' or 'HTML5 + XML serialization', as the 'HTML5' drafts in existence to date cover both HTML and XHTML as two flavors, or rather serializations, of the same markup language. See: http://www.w3.org/QA/2008/01/html5-is-html-and-xml.html http://dev.w3.org/html5/html-author/ Keep in mind that we're reading drafts, so nothing is set in stone, and won't be for years to come. Gives us a good indication of how they're continuing, and smoothing, the relationship between 'HTML' and XHTML that began with 'HTML4' and 'XHTML1.0' though. To exemplify: one can in most cases just change doctype and a meta, and serve a valid and tested XHTML1.0 Strict document... http://www.gunlaug.no/html5-demo.html ...as valid HTML5 (text/html)... http://html5.validator.nu/?doc=http%3A%2F%2Fwww.gunlaug.no%2Fhtml5-demo.htmlshowsource=yes ...or as valid XHTML5 (application/xhtml+xml)... http://html5.validator.nu/?doc=http%3A%2F%2Fwww.gunlaug.no%2Fhtml5-demo.xhtmlshowsource=yes Note which validator I use - http://html5.validator.nu/, as the experimental W3C HTML5 validator won't play ball yet. I can't judge which one is more correct on every detail than the other, as both validators are new and experimental and will be tuned to spec in time. Thus, I may have to make minor adjustments to how I modify my old markup, once the dust settles around xHTML5 :-) Unless they introduce major changes to the specs, the syntactic differences are not creating any real problems for us who serve valid XHTML1.0 as 'text/html' and/or 'application/xhtml+xml' today. Only one or two HTML4/XHTML1.0 elements are signaled to be deprecated in xHTML5, so that's not a problem. Serving a document as 'text/html' vs. as 'application/xhtml+xml' does of course introduce potential problems in other areas, but nothing really new for the average document there either. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Disappearing legends in IE 6
Christian Montoya wrote: Unless anyone here knows what good would come of applying negative margins to legends, I'm going to remove them for good. Probably this you're looking for... http://www.gunlaug.no/tos/moa_18a.html regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] CSS font-size-adjust
Christian Montoya wrote: Could someone please read the body of my email instead of just looking at the title and then post a response that is on-topic? OK :-) CSS2's 'font-size-adjust' support is limited to Gecko/Fx IIRC, and is probably put on hold by the W3C CSS group for the time being - to pop back up in a later CSS version. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] CSS font-size-adjust
Christian Montoya wrote: Could someone please read the body of my email instead of just looking at the title and then post a response that is on-topic? OK :-) CSS2's 'font-size-adjust' support is limited to Gecko/Fx IIRC, and is probably put on hold by the W3C CSS group for the time being - to pop back up in a later CSS version. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] *** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] google and validation
Brett Patterson wrote: So, Gunlaug, in essence, (essence being the operative word), you do validate your site by using tidy? Correct? I mean if you trust tidy to correct your code and all the code that tidy puts out is, as you say, 99.9% effective then that is kinda like validating, right? Pretty much so, although tidying is an active process while validating is pretty passive. http://www.gunlaug.no/contents/wd_1_07.html If my Tidy gives up on my markup, then it's time to ask the validator. In such cases I go back and forth between validating, tidying and cross-browser checking until the problem is tidy, valid and solved. May I add that I don't really trust any software - my own creations included. So, when I'm really bored I attack 'em with all I've got and then some. My Tidy has survived all my attacks quite well. Always some weak spots that may be overcome by cross-checking and making notes on what to look out for. My Tidy disagrees with the validator on a few points - like MSIE down-level conditional comments, and I haven't bothered fixing my Tidy on these points since the ones I've encountered are so few and easy to remember. Otherwise I think Dave Raggett got it more or less right in the original... http://www.w3.org/People/Raggett/tidy/ ...but, as I say in my article, I'm not impressed by what others have done to Tidy later. Some releases/attachments are ok, while others are crippled by someone's personal preferences. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] min-might question
tee wrote: I cannot control or foresee how long the content in the 'set-minheight' div be. What do I do to have the p tag always stay at the bottom of the block? For the example it's pretty strait forward as the p will always stay below the 'set-minheight' div, no matter how much or how little content that div is given, and 'set-min-height' must just be styled tall enough to push the p to the bottom of the 'box' - if that's what you want. The 'box' must also be able to expand if the content in 'set-min-height' pushes it taller. If there's any problems with that, then other factors/styles are affecting the construction and we must see a live example. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] min-might question
tee wrote: 'min-heigh' talls enough is the problem. If I can't forsee how long the content will be, how do I decide the set the value of min-height? http://lotusseedsdesign.com/opera-test/mh.html The design is the fixed width, but even with fuild layout, it's a problem not knowing how tall the content be Looks like you're trying to build a table with divs. Much better to use a real HTML table for that since none of the existing CSS solutions are supported well enough to replicate one. As you know, IE doesn't play ball when served CSS table - support = zero. In addition to that, Gecko can't A:P the p in a table-cell - real or styled, so you'll have to give those p their own rows with cells. Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] google and validation
tee wrote: Hi, I am just curious how many people in this list actually spend extra time making a validation error free page for the sake of validation when third party's code is embedded. Surely the above example is an easy fix, but how about embedding google calendar or other scripts? I rarely ever spend extra time on it, but I do like to save time on debugging later by checking and cleaning up my own and third party's code early - and often. If something is going to break anyway, it better break early. I use the one click - 1/10 of a second processing in HTML Tidy shortcut all the time, which means I actually have problems creating or leaving non-valid parts in a page even when wanting to - for testing-purposes and alike. Embedded scripts are automatically commented out by my Tidy - thus ignored by the validator, so no problems there. Google code and similar sometimes means my Tidy performs doctype-downgrading, which isn't much of a problem either, IMO. If the source-code is only good for Transitional, then Transitional it is. If I want a pass on Strict when Tidy says it is only Transitional, I'll have to perform the extra tidying and testing myself to make sure it works, before calling on Tidy again to check and confirm. Sometimes I even validate my work, but not often since my Tidy got it right in 99.9% of all cases anyway. The validator does a better job at informing me about what's wrong than Tidy does though, so if I'm more confused than usual the validator is a nice to have. The cleaning-up process I'm very much depending on in my daily work, seems to only work properly with the original, customized, Tidy-version integrated in my old editor though, which is why I haven't changed basic editing-tool for my own work for years. I'll probably have to customize it, and my Tidy, for (X)HTML 5 one day, so it doesn't trip on new elements and attributes. I normally only use my much newer and more user-friendly editors when I'm looking at other people's pages - like yours :-) - since I've found their newer Tidy-versions (if they have one) and integration of it near useless. They seem to have become too lenient, and many of the integrated Tidy's are almost set in stone and can't be properly customized through the interface no matter what. I am not implying validation isn't important nor should be ignored. But as we in this list know it's not something that matters much as far as accessible site concerns. Do people today actually still trying to make the page validate by way of proper xhtml markup that may create problem in IE and then write another script to hack the IE? Validation _isn't_ important at all in itself, but making sure the markup and whatever else is in there is actually in accordance with specs before one starts to curse various browsers for their failures, sure makes those curses more valid :-) After all: most cross-browser problems are caused by invalid and/or nonsensical markup and CSS, so quickly knowing in which direction one should direct those curses saves time and frustration. Can't say I've seen IE fail because of validity, but of course one in rare cases has to add something (still valid) to the markup in order to avoid an IE bug or two. Nearly all IE bugs can be fixed without touching the markup though - if the source-code is valid and logical, and, as mentioned, embedded scripts don't create validity-problems. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] 1px difference between IE and FireFox
Taco Fleur wrote:
http://www.onlinemarketingplatform.com.au/ In Internet Explorer there
is a 1px difference in the evolution image.
IE6 doesn't like odd numbers so it rounds off 'height: 135px' on h3 to
134px - making the h3 1px too short.
IE7 handles odd numbers better so it gets the height right, but it
places the h3 itself 1px too high - at least relative to the
body-background.
Suggest you cut IE some slack (or bug-space) by making the image 1px
shorter that the h3. Will at least make it appear right in those buggers.
Furthermore, on that same page there is a find out how button to
the bottom right, in IE this aligns to the center of the p element,
but in Firefox it does not. I would like it centered.
Add...
p.findOutHow a {margin: 0 auto;}
...to center across browser-land.
regards
Georg
--
http://www.gunlaug.no
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] 1px difference between IE and FireFox
Taco Fleur wrote: The cause of this problem is something I've never encountered in my 14 years of web dev, this is amazing to [EMAIL PROTECTED] Well, IE moves in mysterious ways, but one can always follow its path and figure out which bugs we're dealing with :-) What IE6 does with odd numbers in such cases is relatively well known, I think. Easy to check, and usually not a problem as long as designs can take +/- 1px or avoid those odd numbers. IE7' behavior is caused by the way they made IE7 respect declared dimensions - something IE6 doesn't. IE7 internally replicates the old hack we sometimes use on IE6 to make it respect dimensions while presenting any overflow - 'overflow: hidden' on the container and 'position: relative' on the content. In your design the '#mn li a' is actually 1px taller that the '#mn' that's containing it because of the declared height and border-width, which causes 1px overflow. This 1px overflow pushes h3 down and into the actual position in all good browsers - and even in IE6 because IE6 auto-expands '#mn'. However, IE7 now respect declared dimensions so well (!) that it won't let the overflowing 1px take up space even though it does present it visually. This is a documented IE7 bug, and it causes the h3 to sit 1px too high in the page. So, you can fix IE7 by making height on '#mn' 1px taller, and no other browser will complain since that's the actual height of '#mn li a' anyway. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] old horizontal list formatting issue in ie
kevin mcmonagle wrote:
Floating the images/ anchors contained in the li's left next to each
other is what im trying to do. But right now each li streches to the
width of the ul so the cant float left. Even distributing them evenly
would be fine though.
You're running into specificity problems, as you have styled li
completely different other places and those styles override the low
specificity '.bos_image_index li' styles.
Make the selector...
#rightcol .bos_image_index li {...}
...and the styles will kick in.
regards
Georg
--
http://www.gunlaug.no
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] [IE7 Glitch] footer is expanding, and acting wonky with scrolling.
Andrew Brown wrote:
Does anyone know what would fix this? I exhausted my self with
various solutions. The live demo is here:
http://monsterboxpro.com/dump/webtemp/index.html
Stiffen up IE's backbone with a 'hasLayout'[1] triggering declaration.
Add...
div.footer_wrap {height: 1%;}
...and it'll do fine.
BTW: 'display: relative;' that you have on the same element, must be a
mistake. No such 'display' value - you probably meant to write
'position: relative' but I can't see the need for that one either.
regards
Georg
[1]http://www.satzansatz.de/cssd/onhavinglayout.html
--
http://www.gunlaug.no
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Is it a good practice to have 'Back to Top' link?
Joe Chiang wrote: Perhaps, implement something like 'sticky sidebar' or 'position fixed' to present the 'Return to top' link rather than adding it after each section is another option I look favourably at. Obviously, I need to work out on IE6 for this. http://www.derekallard.com/blog/post/conditionally-sticky-sidebar http://www.nowcss.com/javascript/emulating-position-fixed-in-ie-6-below Any thoughts? I collected my thoughts on 'fixed' here a couple of years ago... http://www.gunlaug.no/contents/wd_additions_15.html ...and used IE-expressions to enhance my home and ToC pages in IE6 for quite a while... http://www.gunlaug.no/main-en.html IE-expressions, complete with the jerkiness fix, creates a good illusion, but they rely on script-support as much as any other script and do put a load on computer resources over time. Apart from that they can be made to work better that the real 'position: fixed' since one can conditionally manipulate both axis independently. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Setting HTML and BODY background not working
Cole Kuryakin wrote:
http://www.koisis.com/.clients/asdem/dev/index.php?cmd=001001
The height of the body image (the hiroshige painting) - rather than
showing in full - seems to be getting cropped by the height of my
wrapper div.
Add...
body{
padding: 1px 0;
min-height: 100%;
}
* html body{ height: 100%;}
...to make body at least as high as html/viewport - and growing with
content.
regards
Georg
--
http://www.gunlaug.no
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Is it a good practice to have 'Back to Top' link?
Joe Chiang wrote: I have some VERY long pages in the website I maintain. Currently, I insert 'Back to Top' after every section in the page. Sometimes, I feel they are disturbing and am not sure if there is any better way to do it or don't insert them at all. Unless clients insist on having 'in-page navigation' links, I don't add any. That goes for Back to Top, Skip to Content, Skip to Navigation and all the others. In most cases such links are duplication of browsers own functionality, which is only useful additions in rare cases and in most cases can be seen as unnecessary noise. The exception is links to in-page references or content groups, which I add since browsers can't help much in finding them otherwise. Good example: W3C documents list of links to sections - would be hard to access them without those ToC lists/links. Of course, splitting the page into smaller pages is the simplest way out, but for our application, the page has to contain all the information on the same page. Splitting documents is also something I avoid when I can, almost regardless of how long a document becomes. It takes longer to move between sections and split documents are a nuisance when going to print. Cross-linking separate documents for reference is of course a different matter, and splitting up documents because there's a change of subject also. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Is it a good practice to have 'Back to Top' link?
May I suggest that we fix an Up link at the bottom and a series of section tabs and Skip to ... at the top of the window - 'position: fixed' that is. Should work on all but the smallest windows and in all the latest browsers, and are easy to reposition or turn off for print. IE6 will have to pull a little extra, but should otherwise cooperate well. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Is it a good/bad practise to have more than one same link url?
tee wrote: As far as SEO concerns, it seems to have an advantage because google image search and a few other image search engines (can't remember their names). This seems to be very useful for sites that sell products, image stock and photographers Have to keep that in mind when I'm looking for such products - look beyond the first few dozen finds. This is something I quite regularly do anyway, for all searches, because of all the SEO aimed at twisting search-results. But no good for screen reader I guess. Without one to test from, I imagine the screen reader reads each links?! They ain't got much of a choice - a link is a link even if it is a duplicate. To expand on practical solutions at hand: I often duplicate links myself, but in a different way and for a different reason - no SEO intended. - One link to a page goes in the relevant place in the main section. - One link to same page goes in a listing of links in a separate section, so that all relevant links can be found in one place - for instance in the sidebar. I may have one such link-group for internal pages and one for external, marked up with suitable group-headlines. In some layouts an image can be positioned out of the text-link, which eliminates the need for duplicated links. Depends very much on the actual layout if this noise-reduction method can be used, or not. Would work fine in layouts like the one the site I used as example of link-duplications - http://www.sitepoint.com/. Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] suckerfish problem - ie6
kevin mcmonagle wrote:
cheers george. i thought the !important; fixed that but apparently
not. menus height ok in ie6, just have to give it a conditional
comment for the width now.
Suggest you add this package instead of something in a CC...
#mainMenu li ul {padding: 0; }
* html #mainMenu li { overflow: hidden; }
* html #mainMenu li ul {margin-bottom: -1000px; overflow-x: hidden;
width: 12em;}
regards
Georg
--
http://www.gunlaug.no
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Is it a good/bad practise to have more than one same link url?
tee wrote: I was thinking maybe it's a SEO question and shouldn't post it here, however, the more I think about it, the more I feel it deserves a semantical perspective and wonder if it creates obstacle for screen reader. Might be seen as noise, but can't see any other problems with otherwise meaningful duplication of links. On http://www.sitepoint.com/ you'll find 3 links to same page for each of their main posts, and I don't think it hurts. Don't think it helps either for that matter. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Background-Image not displaying in IE5 IE6
Kristine Cummins wrote:
I have a div container that has a background image (gradation) which is
displaying fine in IE7 Mozilla, but it's not displaying in IE5 IE6.
http://www.cpwrehab.com/test/index.html
Add...
* html #container,
* html #headercontainer {
height: 1%; overflow: visible;
}
...to give old IE something it understands - a 'hasLayout' trigger and a
hint not to hide the overflow. That will fix the problems.
regards
Georg
--
http://www.gunlaug.no
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] please help me understand how Opera (9.5) deals with em, % and pixel
tee wrote:
http://lotusseedsdesign.com/opera-test/opera.html [1] input element
or class has background color borders - no checkmark (or tiny
checkmark depending on the width/height of the class for input
element) in checkbox.
Padding seems to cover the area, and does so until the padding becomes
too large so padding from all sides starts overlapping inwards. Once
that happens the checkbox presents its status properly again.
In your test-page, with 'input {border:1px solid #555;padding: 5px;...
}' there's 1 red pixel visible when checked.
With 'input {border:1px solid #555;padding: 6px;... }' there's no
visible check-mark when checked.
With 'input {border:1px solid #555;padding: 7px;... }' the checkbox and
check-mark appears normal. Continue to do so on larger padding, but (of
course) eventually the padding becomes so large that it breaks the
checkbox apart.
Conclusion: one or more nonsensical bugs for styled checkbox in Opera.
[2] input element or class has background color, no borders -
checkmark shows up alright.
[3] input element has no background color, no borders and no class
added - see second checkbox/radio button example.
http://lotusseedsdesign.com/opera-test/opera-nobg-in-input.html
So, [1] seems to be a bug. What about [2] and [3]? Which one is the
correct rendering? It looks like none of them are correct because
they are all inconsistent.
If by inconsistent you mean don't appear identical across
browser-land and OEes, then you won't find a correct one in Opera.
Opera seems to use its own across OSes, while for instance Firefox seems
to change with (rely on) OS. They will never look the same.
[2] is probably the best shot at consistency based on what I see on my
win-OSes, but it definitely doesn't look the same in Opera 9.52 and
Firefox 3.0.1 on win2K.
regards
Georg
--
http://www.gunlaug.no
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] please help me understand how Opera (9.5) deals with em, % and pixel
tee wrote:
Is it just me kept running into issues with Opera? I really don't
remember having these problems so obvious with pre-version 9.5 that I
can't tolerate. I am getting this impression that the evolution of Opera
has come to an end and now it's rapidly reversing back to the buggy
primitive state that it almost mimics IE 6's behavior and the worse, I
don't have a conditional comment to make it works better. From some
articles I have read, I got a sense that Opera folks are very proud of
the CSS3 spec achievement, but my take is, if I have to make double
effort to have my layout render just slightly closer to FF and Safari, I
can't afford to care all those shiny CSS3 attributes and Selectors. What
is more aggravating is that it's less than 3% population that needs to
support.
Not the first time Opera, or any browser, goes into regression - or
worse. Lack of extensive real-world testing, I guess.
I can see that Opera is weakening on a few points that matters to me,
but generally the latest versions (9.5x 9.60b) haven't created any
real problems.
Good thing Opera is hard to hack, or else those regressions might end up
being pretty permanent - as in IE. Might make it easier for some, but
not for progress.
Better to ignore those 3% or whatever if you can't make it work,
although I'm not sure Opera's performance is to blame for all your problems.
I still have not fixed the problem I have had from my previous post (and
still can't figure why the link and text are not clickable/selectable),
now I am seeing another two little problem.
In this link, it illustrates two issues: the screen shots on the right
are taken from Opera, as you can see, the background image drops to the
bottom in the breadcrumbs.
http://lotusseedsdesign.com/opera-test/opera-has-issue.png
And the button, it works likes IE does, the difference is that IE
doubles the width and Opera doubles the height.
My font size declared in the body tag:
font: normal 100.1%/1.5em
Obviously Opera got it wrong again somewhere with em and pixel
calculation. Is this another new bug or something so old that never got
fixed ?
Have no thread/post to look at for debugging. What page(s) (links)
present the problem?
And here is another Opera problem I stumbled few days ago when I was
doing Opera bug hunting:
The page uses Prototype Glider script:
http://marinersq.com/index.php?id=50
In Opera, you will see clicking the snapshot on the left changes nothing.
Turn out I goofed, I forgot to load the script in the page (time wasted:
over 24 hours):
script type=text/javascript
var my_glider = new Glider('glider', {duration:0.5, frequency: 4});
/script
But the fact that page still works (except without glider effect) in all
other browsers make me think this is just another bug of Opera.
Confirming that. Opera before 9.50 beta supported effects like that,
without scripting. No go in later Opera versions.
Example: http://www.gunlaug.no/tos/moa_25e.html
Here is the working page with glider script loaded.
http://marinersq.com/meet_trainers.html
if you go to homepage of the site, you will see another Opera opacity bug.
I see problems in that page, but even after side-by-side comparison with
Fx3.0.1 I can't see opacity problems. Care to explain? You can mail me
off-list if it becomes long-ish.
regards
Georg
--
http://www.gunlaug.no
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] please help me understand how Opera (9.5) deals with em, % and pixel
tee wrote: Hi Georg, very nice to 'see' you :) :-) http://lotusseedsdesign.com/opera-test/opera-has-issue.png I am narrowing down to the % and em that are causing many problems I have encountered. The site is in my localhost therefor I can't post it, but I will move it to a webserver maybe tomorrow or in the weekend, and email you the url (can't show the site to public) as I have stumbled 3 more issues after my post. Some of Opera's '%' and 'em' issues are old as , and should have been fixed half a decade ago. I'll see if any of those issues are creating problems for you when I get the page for debugging. Problem in debugging is that I can't recreate the exact conditions of OS and parallels you use. Should be able to improve things for the average end-user though - to the degree Opera is willing to cooperate. I see problems in that page, but even after side-by-side comparison with Fx3.0.1 I can't see opacity problems. Care to explain? You can mail me off-list if it becomes long-ish. http://marinersq.com Sorry, the opacity bug is in the homepage, the large slide show. I looked at the correct page first time around, but couldn't decide what intended rendering-effects should be. Looked a bit challenged in all my browsers. When the image pan out, it turns to semi-transparent and fading, but Opera shows a solid image. Indeed. Opera starts fading too late and behaves as if it it hangs on fading at cross-points. I reported this before and talked to the author who wrote the slideshow script, he couldn't figure out even though he was very keen to fix it. Something for those at Opera, me thinks. Looks like an excellent real-world test case. Re the unclickable and unselectable issue, here is the page. http://lotusseedsdesign.com/opera-test/opera.html Bruno wrote he has no problem selecting the content and clicking the link 'go there'. No problems with select or functions in Opera 9.20 --- 9.60beta versions on win2K or winXP at my end. I trashed my Opera from both Mac and PC version (via Parallels), re-installed it but the problem doesn't go away. I am also seeing the same behavior (links not clickable) in the site I was working in my local server. I figure it must be something to do with %, pixel and em units I have for font size, margins, padding, width and line-height and Opera isn't smart enough to do the math. Sounds like a problem in the relationship between Opera and MacOSX, and I've quit updating/using Mac so can't test. Though very unlikely, I have started thinking maybe the problem occurs because I have more than 1 classes declared in a div. Never observed any multiple classes problems in Opera. Don't think there are any. Also, in the above page, do you know which checkbox/radio button is the correct rendering in Opera? When 'Enable Styling On Forms' is checked (default) in 'opera:config', all instances of checkbox/radio button in your page look like in your image in Opera 9.20 --- 9.60beta version on win2K. In Opera on winXP the colored area of checkbox is smaller - the size of unstyled checkbox, and therefore bordered area wider than colored area with white space in the gap. How far you style those elements should have no effect on function. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Position and peace of mind
John Unsworth wrote: So my questions to the group are; Was the decision to write the markup in the order I did correct or pedantic? Because if I didn't then I wouldn't have the layout issues I'm having I'd guess. Positioning out of visual order on a detailed level, can easily create more problems than it solves. Unless found to be absolutely necessary, and tested to function flawlessly (see below), I advice not to rearrange actual vs. visual order for accessibility or other reasons. Was it a mistake to try and create an elastic layout in em's and expect the entire interface to expand? In this case might it be better to use pixel for width's but em's for font and % for height and allow the boxes to expand with the text? Or should I just stick to pixel's all round. Elastic layouts with lots of images tend to not do to well in the real world, but otherwise there's nothing principally wrong with them - they just have to be done right. Percentage for height will create problems. Proper equal height boxes can only be created in a reliable way when using HTML or CSS 'table', ant the latter ain't supported by IE7 and lower. Is there a 'golden rule' about repositioning sections of markup out of the order they're written, and why was there variation with the margins across apparently very well behaved browsers? The only reliable 'golden rule' is that _it has to work_ - preferably also under stress. Stress-testing should ideally cover what end-users _might_ do to your layout because their browsers allow, not only what most of them are most likely to do to it. This means you as designer has to know at least as much about each of the browsers you choose to support, as the most knowledgeable end-users, while still catering reasonably well for the majority of dummies. For instance: your dimensioned boxes are overflown by their content when exposed to the 'minimum font size' option (I always set)... http://www.gunlaug.no/contents/wd_1_03_04.html Other misalignments in the layout look pretty unimportant then, since vital parts become inaccessible and unusable. [...] Generally the whole IE thing I ignore until required. You should run through the supported IE-versions regularly while designing, so you don't run into problems that can't be solved later on without changing things for/in all browsers. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Code for Firefox, hack for IE
David McKinnon wrote: For a while now, I've been operating on the principle Code for Firefox, hack for IE. Is this the way anyone works? Apart from that I code for the most standard compliant browsers (plural) at present time, and then hack for various IE versions, I think I'll go along with your principle. FWIW: Firefox (3.01) is third on my list of reasonable compliant browsers at the moment. Is it the best way to work? Well, it is rather time-consuming and impractical to code for IE and then hack for the other browsers, so I think you got that about right too :-) Does anyone know where I got this idea from? Book? Blog? A bit of googling this afternoon turned up not very much. Maybe on this old note... http://css-discuss.incutio.com/?page=WhichBrowsers regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Figures out issues. Standards for troubleshooting css
Fred Ballard wrote: For problems with box alignment, I know I usually turn on background colors to clearly see the size and position of the boxes the browser is using. Or is that a newbie answer? Definitely not a newbie method. Setting backgrounds is one of the quickest ways to check line-ups while designing and troubleshooting. I usually set borders first time around, and the extra element-dimensions borders create gives me lots of information about tight-corner layouts and other potential design-problems that browsers may handle differently. Another technique I use daily is to invalidate CSS rules instead of commenting them out during troubleshooting. Typical example: background-: #abc; Such rules stop working in all browsers, and the CSS validator will help find these invalid rules if I lose track of them. I prefer such direct debugging over developer tools in various browsers, simply because the tools are always at least one step behind. Michael Horowitz wrote: The hardest thing about learning a new language is learning its troubleshooting techniques. Maybe not a technique, but... Being able to separate browser-bugs from designer-bugs quickly, helps a lot. That means being aware of the browser-bugs we run into most frequent, to a point where it almost becomes second nature to spot them. A quick stress-test of a design in the major browsers should normally be enough to pin-point most bugs and design-weaknesses, without even having to look at the HTML/CSS behind it. Getting to that point takes time and a lot of bug-spotting, so looking at other designers' work, attempts, failures etc. across browser-land is (for me at least) more useful and less time-consuming than creating test-cases and struggling with my own designs. That's the main reason I keep an eye on lists/forums like [css-d], [WD], [WSG] etc, since all you new and old designers manage to trigger many more browser-bugs and create more weak designs than I can - even on a good day :-) Helping others fix their problems helps me recognize, remember and thereby avoid getting stuck on the same or similar problems. Seeing how others go about solving problems helps a lot too - even when I disagree. Doesn't matter if I see the problem or need a solution right now, as I probably will one day. A few minutes troubleshooting someone else's case may save me hours on my own cases later on, so it is time well spent. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Mystery Margin or Padding in FF and IE
Cole Kuryakin wrote:
Hello All -
I'm developing a new framework for my projects and have come across
something I can't get rid of.
Go here: http://www.koisis.com/.framework/-public/index.php
If you look at the purple float that contains a beige main content
area, you'll see that the beige content area is being pushed down
about 25px for some reason in FF. In IE 6 and IE 7 the same phenomena
also happens, but it happens at the TOP of the beige content area
itself.
The top margin you've declared on h1...
#contentMain h1 {margin: 25px 0 10px 0;}
...is escaping #contentMain and ends up on top of it in compliant
browsers. That's correct behavior AFAICS...
http://www.w3.org/TR/CSS21/box.html#collapsing-margins
IE6/7 OTOH are containing h1's margin because of the 'hasLayout'
triggering...
#contentMain {width: 550px;
...you've declared in there. That's not correct but not much you can do
about it.
One way to solve it is to have zero margin-top on that h1, and use on it
padding-top instead.
Another way is to contain the margin-top by declaring...
#contentMain {float: left; display: inline;}
...which all browsers will agree on, and thereafter adjust h1's
margin-top to taste.
regards
Georg
--
http://www.gunlaug.no
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Marking Up Poems
Jens Nedal wrote: [...] If you ask me, i would say that a double br is a p already. Look at word processing programs. When you wish for a double br you will simply type Enter. If you want a line-break you will mostly do a Shift+Enter. Word processing isn't web design, and one has to look beyond the visual when selecting markup since markup convey both visual and non-visual meaning by its presence, or absence. A br doesn't tell anything about the context it's in - it is just a line-break no matter where it is found. How many breaks one add doesn't change that. Visually a br can have some height, line-height or zero height, depending on how one styles it, so one can not rely on it to create a space to add additional meaning either. p is a paragraph and a poem can consist of multiple paragraphs, called verses. The discussion might be about small matters, but i feel p looks more like it fits breaking a poem into verses. One can observe some discussion about how to markup poems and alike on the HTML 5 lists, and so far series of paragraphs with line-breaks (br) as appropriate and spans for additional styling seems to be the only somewhat suitable option. I think that'll stick ... unless they add new, dedicated, elements for poems, which seems unlikely. Since one can style paragraphs, spans and line-breaks as one wants, one can achieve quite acceptable visual presentations with control of white-space etc., without losing or messing up more than one has to for the non-styled and/or non-visual presentation. Wrapping the whole poem in a div (division/section) provides for additional styling. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] IE6/7 behaviour
Rob Enslin wrote: Although not a standards-based question (I think) I wonder if anyone has the 'fix' for it? The page: http://www.servicemanagement.co.uk/new.htm Maybe better to trigger standard mode in browsers first, and add fixes later. The combination of declarations you have now is a somewhat new one - to me at least. An XML declaration has no place above an HTML DTD in an HTML document, and the DTD is incomplete and triggers quirks mode in all browsers... http://gutfeldt.ch/matthias/articles/doctypeswitch/table.html If you really want quirks mode rendering, you may as well delete both these lines... ?xml version=1.0 ? !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Marking Up Poems
Must you Australian's *always* have the last say? ;) not always, but often. esp if it ends in beer and a party Is that why what you say most often makes no sense? :-) Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] W3C HTML Validation of an Intranet site
Hayden's Harness Attachment wrote: http://validator.w3.org/check?verbose=1uri=http%3A%2F%2Fwww.terasengas.com%2FHomes%2Fdefault.htm I am really confused. Can anyone explain? What the validator says: There's one end-tag too many for a link on line 91. Delete one /A in that line. Alt-attributes not included for images on line 115 and line 130. Make that empty alt-attributes, alt=, since those images probably don't need alt-text. Looks like a missing on the start-tag for the link on line 150. That generates three errors since the validator tries to interpret the link-text as part of the link-address. You've used XHTML syntax to close the image-element in line 304. Delete the ending / since you're marking up in HTML 4.01 Transitional. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Should we design for 800x600 screens?
Darren West wrote: An alternative could be to develop with relative sizes for all measurements, allowing the interface to be scaled to any screen resolution. Examples can be seen at http://www.linkedin.com and http://www.sky.com Dysfunctional examples, but they clearly show what many mean by relative sizes - font-size dependent layouts, without looking into the potential problems created by such a framed approach. 1: wanting or having a need for larger text, doesn't mean one has or want a larger screen and/or browser-window. 2: having a larger screen and/or browser-window, doesn't mean one wants or need larger text. Thus, relative sizes means a/the layout only works well within a certain window-size on a certain screen-resolution with a certain font-size, and can not adapt well to the end-user's environment and needs if they deviate from the designer's frame. Sounds designer-friendly enough since they get to keep the designed proportions, but is not what I would call user-friendly. Page zoom in Opera, Firefox 3 and Safari 3 allow layouts to adjust to the end-user's environment and needs - unless the designer has declared relative sizes and/or other width-barriers. Since this user-friendly zoom-feature seems to be on its way in - after having been found only in Opera for years, it would be better if designers tried to make sure it could actually work as intended instead of designing for certain relative or absolute sized frames. Since all browsers can also resize fonts (one way or another) independent of page zoom, relative sizes risk creating even more problems when both font resizing and page zoom are used. The latest mobile browsers also incorporates page zoom and font resizing in various forms in order to enhance the experience, so the more freedom we give those browsers to perform their job the easier it'll be for the end-user. Optimizing our designs for an average window-size is an ok approach IMO, as long as we don't lock them in so they fail too badly outside that average window. Personally I optimize for a range of 600 - 1200 in width, and am now working on extending the don't fail too badly range to 200 - 2400 in width by giving the browsers more freedom to determine proportions. I also get to keep _my_ design-proportions, since I design for the way browsers treat my layouts and make as much out of the many variables introduced by browsers and their various options as I possibly can. I use 3800 wide screens/browser-windows and mobile browser emulators to test on, and although there may be quite a few problems getting older browsers perfectly in line, I see no real problems in getting the new ones to play ball. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Help setting current menu state on level2 menus
Susie Gardner-Brown wrote:
But when the link has sub-menu items under it, all of those get the
same treatment! Because the styles are applied to the list item. Can
anyone think of a way to do this that would not affect the sub-menu?
http://crunchie.tedi.uq.edu.au/trials/UCTLC/stLucia.html
Add specificity to the selectors for sub-menu styles...
#lhnav #navcontainer li li a { ... }
#lhnav #navcontainer li li a:hover { ... }
...to make those styles override ACTIVE styles on first level.
BTW: font-resizing doesn't play well with that menu in any browser, and
IE/win's em font-resizing bug[1] doesn't help much either.
regards
Georg
[1]http://www.gunlaug.no/contents/wd_additions_13.html
--
http://www.gunlaug.no
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Help setting current menu state on level2 menus
Susie Gardner-Brown wrote:
Re the font-resizing - sigh!! For a lot of the websites we develop at
the university here, we're supposed to use this awful template,
which includes the lefthand menu like this. In the template it's all
in tables!! I got the way of doing this menu from
http://demo.pixelsandpages.com/test_dual.html and I thought it
covered all problems!
For a menu in isolation, yes. When placed in your layout its 'em' sizes
creates more problems than it solves.
Once you start using 'em' for dimensions _one_ place, you'll have to
make sure _all_ elements play well together when subjected to font-resizing.
I already have the base body font size set at 62.5%. Are you saying
that if I add in html{ font-size: 100%;} before that it
will be OK?
If you check with the CSS validator you'll see that a big chunk of your
stylesheet disappears in a Parse Error - including the font-size on
body. Fix that part and you'll fix the em bug.
Of course: such a small font-size as 62.5% as base will make the effect
of 'minimum font size' in Firefox and Opera ruin the page...
http://www.gunlaug.no/contents/wd_1_03_04.html
Of course, I'm a Mac-user, who pretty much uses Firefox all the
time. But I do have XP and IE6 installed in Parallels so I check on
that. But I guess usually after I've developed in FF Mac ... :)
Cross-checking _during_ development will save you time - tons of it.
Testing with regular browser-option well beyond what normal users will
expose your work to, will save you from having to deal with
user-introduced problems later on.
regards
Georg
--
http://www.gunlaug.no
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Alt versus Title Attribute
[EMAIL PROTECTED] wrote: So what's the general consensus on the use of null or empty alt strings as per the reasons outlined in the article below? http://www.stuffandnonsense.co.uk/archives/accessible_alternatives.html The choice between alt-text or no alt-text depends entirely on whether an alt-text contributes something meaningful to the document, or not. This often makes it hard for authors to decide what's best to add or leave out, since most of us can't/won't read our documents as text-only. Even if we do, we will still have the images fresh on our minds, which affects our ability to make wise decisions. Basically: If nothing gets lost when an image cannot be appreciated visually, then its alt-text can be left out. If something/anything important _do_ get lost, one should use the alt-text to restore the meaning of the document in a no-images, text-only situation to as high a level as possible - without cluttering it. My own interpretation of the issue is presented in some length here... http://www.gunlaug.no/contents/wd_additions_24.html ...but whether or not that constitutes any level of consensus amongst authors/designers is a big unknown. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Alt versus Title Attribute
Designer wrote: I'm getting confused now - on MY IE6, the title is displayed on hover, not the alt. I was originally testing with my standalone IE6, so I checked on my laptop, (with 'real' IE6) and got the same result! Me too. IE/win shows title-text on images when such exists, otherwise it shows the alt-text if such exists. The most problematic with IE6' behavior comes when title is used on an anchor containing an image with alt-text - with or without a title. IE tends to show the image-title/image-alt while (at least most) other browsers show only the anchor-title, (if I remember my last battle with that correctly). Changes in default-behavior announced for IE8, IIRC. Probably more confusing than ever. Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Alt versus Title Attribute
Darren West wrote: There is the argument that you are changing the behaviour of IE, however wrong it is, it could be what users expect. I believe Jaws ignores empty attributes so all good there ... I do not think one should meddle with a browser's behavior in minor cases like showing alt-text as tool-tip by default. Nothing gets broken in most cases, and other browsers can show alt-text as tool-tip too - via an option or add-on. Only those cases where clearly a wrong and misguiding text pops up on :hover in IE, should any form of workarounds be applied ... IMO. Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] help with menu positioning
tee wrote: Tell me, what do you like for Christmas gift ? An internet-connection that is extremely fast and works all the time ;-) (Maybe I'll get one before Christmas, but I'm not holding my breath.) Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] IE6 background image positioning problem
Susie Gardner-Brown wrote:
http://crunchie.tedi.uq.edu.au/trials/UCTLC/index6.html
That big image on the right is a bg image in a container that has
absolute positioning. It works fine in Firefox on my Mac, but IE6 it
drops down.
Can anyone see what I'm doing wrong?
You're trying to fixed-position a background, which I don't think you
really want since that means the background is positioned relative to
the browser-window - not the page.
Anyway, IE6 can't handle fixed backgrounds on regular elements inside
body, so it is absolute positioning that background.
Change to...
#entryContainer {
background: #FFF url(entry-bg.jpg) no-repeat 193px 0;
}
...and IE6 will line up with the other browsers - or rather the other
way around but with all parts in the correct places.
regards
Georg
--
http://www.gunlaug.no
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] help with menu positioning
tee wrote:
My brain isn't working. I thought I have the answer but it's not
working :-(
http://lotusseedsdesign.com/menu.html
Missing base-position...
#menu li a {background-position: left top;}
Georg
--
http://www.gunlaug.no
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] transitional vs. strict
Patrick H. Lauke wrote: Gunlaug Sørtun wrote: Quirks mode is the best mode for the old bugger known as IE6, IMO, Care to clarify why, exactly? I listed a few reasons down this page some time ago... http://www.gunlaug.no/contents/wd_additions_16.html ...and nothing seems to have changed since then. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] IE8 beta's a nightmare
Jens-Uwe Korff wrote: Did anyone do some more testing with IE8? Yes, and I've concluded here... http://www.gunlaug.no/contents/wd_additions_32.html Do we know any better release date than mid year? The later the better, as the IE-team got plenty left to fix if they want IE8 to end up as a serious replacement for earlier versions. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] transitional vs. strict
Thierry Koblentz wrote: On top of using a correct Doctype, authors need to make sure that nothing (e.g., XML prolog or HTML comment) comes before the DTD or it will send IE into Quirks mode. Quirks mode is the best mode for the old bugger known as IE6, IMO, which is why I make sure to always have an xml declaration above an xhtml 1.0 Strict / Transitional DTD for any regular document. A comment at the top is not practical though, since that'll disturb later IE/win versions too. Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] IE7 - content not displaying
Likely, James A. wrote:
The footer on the page is not appearing, but the space that it is
meant to hold the footer is present. I know about the peek-a-boo
effect for IE, but this does not seem to be the case. Does any one
have any suggestions on how to fix this?
Example: http://wisconsin.joekiosk.com/version2/research.php
Start by adding a 'hasLayout'[1] trigger to the bottom-container, for
example...
#idx-content-bottom {height: 1%;}
That'll give IE/win something to hold on to when it tries to figure out
where to display the rest.
BTW: a div is 'display: block' by default, so all those 'display: block'
on divs is butter on fat that doesn't help any browser.
regards
Georg
[1]http://www.satzansatz.de/cssd/onhavinglayout.html
--
http://www.gunlaug.no
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Rogue text appears in IE6.
Rob Enslin wrote: I've recently built a website trying to move towards more standards-compliant code. After the delight at pushing the site live my world 'caved in' (a little over-dramatic maybe) this morning when a colleague noticed rogue 'ls. text some way down the home page. Live site: http://www.londoncalling2008.com Delete HTML-comments, and IE6 will stop duplicating characters. See: http://www.positioniseverything.net/explorer/dup-characters.html for more info about that bug. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] premature to test/worry new site for IE8?
tee wrote: I am about to start coding for a new site, and client asked me to make sure my code will work for IE8, meaning when IE 8 comes out, she doesn't need to pay me extra to fix any problem that may occur in IE 8.Client is from a web media company, though I understand her concerns and that she has to answer to her client, but I just don't know how or if I should commit to such 'expectation'. You've got no real IE8 to make anything work for yet, so, no. IE8b1 is so weak and broken that it doesn't make sense to do anything but reporting its weaknesses back to the IE-team. Better wait for better betas or the final version, or else you risk ending up having to redo whatever you do for it now. IE8 final will probably be relatively standard compliant - based on what the IE-team has written about it and what one can imagine from studying IE8b1, so there's a chance we won't have to do much for it if a design is made to work well in better browsers. Advice: just make sure IE8 can't see any fixes for IE6 and IE7, or for IE/Mac, and leave it at that for now. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Spolsky on IE8 flag
Lea de Groot wrote: Joel Spolsky has published an ... interesting article http://www.joelonsoftware.com/items/2008/03/17.html Microsoft failed to follow the evolutionary trail and keep up with common standards - to the degree that such exists, and now they try to catch up without causing a revolution with subsequent riots all over IE/win-hackery land. I wish the IE team - and us - good luck. A fresh start would indeed be worth considering - with name and all, but I can't see that coming :-( I like Internet Avenger for I am a romantic. Who can think of a better name? :) It already has one: Internet Exploder, and I'm pragmatic and can't think of a better name until I see a better browser. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Opera 9.26 Problem
Web Dandy Design wrote: [...] However the client's French distributor says that the site doesn't look right when they are using Opera v9.26, revision 8835, Win32, Windows XP. Has anyone ever come across this problem before? www.charis.uk.com http://www.charis.uk.com/ . Breaks the same way in all versions of Opera and Firefox at first load at my end, on win2K and winXP at 96dpi res. Problem is known as unprepared for font-resizing, and all these browsers are preset at 'minimum font size: 14px' here. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Opera 9.26 Problem
Web Dandy Design wrote:
Can you advise what would need to be done to the site to 'make it
work' in Opera?
Add...
#left-col {clear: left;}
...and the problem is solved in all browsers and on all resolutions.
The problem was that the left-col got hung up on the horizontal nav's
right edge when that nav grew in height when subjected to font-resizing.
Opera has a 'minimum font size' default value around 9 - 14px depending
on OS and resolution, while Firefox has 'minimum font size' default of
none.
regards
Georg
--
http://www.gunlaug.no
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] inline floated right problem in Firefox
tee wrote: http://lotusseedsdesign.com/firefoxbug.html I have not tested this page in IE as my Parallels desktop has networking issue and I can't connect to the Internet from Windows XP, so I am not 100% sure if the problem only occur in Gecko browsers. IE/win handles it like Firefox. Gecko and IE have one interpretation of such float line-ups, and Opera and Safari have another. I prefer the Op/Saf one since it works well for all cases, but it's probably the wrong one :-) Float first is the only cross-browser reliable solution, but it doesn't always suit the case. I sometimes use the alternative styled into your example 2... http://www.gunlaug.no/tos/alien/tee/test_08_0313.html ...but it has the same potential overlapping effect as absolute positioning has, and does therefore only work well in some cases. A better alternative is what I have overstyled a bit in the added example 2-b, as there's no chance of overlapping in such a reverse styled case, and the source-order is the the same as the visual order. One more span needed though. Sorry for the mess, but I don't have time to create a new demo right now. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Links are not hot in ie8
Thierry Koblentz wrote: I think it's going to be a fun ride... I really don't think it's time to saddle up yet :-) http://tjkdesign.com/test/ie8/links.asp So, they still have those stacking-bugs to sort out. Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] multiple css style sheets
dwain wrote: On 3/1/08, Melissa Forrest [EMAIL PROTECTED] wrote: aaah no, there is nothing invalid about more than one stylesheet link tag in the markup do you have a link for your side? Validity isn't a problem, but don't add too many stylesheet links or style elements in the markup - unless one doesn't want IE/win to get them all... http://www.gunlaug.no/contents/wd_chaos_27.html Haven't tested for number of @imports yet, but IE/win gets them wrong anyway - so far... http://www.gunlaug.no/contents/wd_chaos_20.html http://www.gunlaug.no/contents/wd_additions_12.html regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] multiple css style sheets
dwain wrote: On 3/1/08, Matthew Pennell [EMAIL PROTECTED] wrote: On Sat, Mar 1, 2008 at 12:47 PM, dwain [EMAIL PROTECTED] wrote: do you have a link for your side? validator.w3.org? what about the w3c specs? http://www.w3.org/TR/html401/present/styles.html#h-14.3 I think this gives us the necessary freedom to add stylesheet links. 14.3.1 Preferred and alternate style sheets HTML allows authors to associate any number of external style sheets with a document. The style sheet language defines how multiple external style sheets interact (for example, the CSS cascade rules). ...with this limitation... If two or more LINK elements specify a preferred style sheet, the first one takes precedence. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] re: generate data
dwain wrote: if accessibility isn't cracked up to what it's supposed to be, then why are there laws about the subject? The laws are probably there to prevent accessibility from falling through the cracks. Consciously or unconsciously ignoring access for all is after all more the norm than the exception, and that has to change. The two levels of accessibility have been mention. - The first level, where access to content and functionality should be guaranteed on a technical level, is not much of a problem. Basic understanding of how to build a site is all that's required to reach that level. The challenged user-groups I ask for advice, expect me to meet them at that level - which is (slowly being) required by law for public sites in my country anyway. - The second level, where some kind of optimizing for specific user-groups and their hardware/software solutions has to take place, is of course harder. I'm being told *not to go there* by the same challenged user-groups, as more accessible solutions for smaller groups may end up being tied to some weak end-user solutions that should rather be upgraded/replaced and brought in line with the technical level most of them are comfortable with. They work for improvements and solutions that are tailor-made to the individual's needs - at their end, based on common delivery-methods and techniques that can be made to work for all - as long as we developers/designers don't get in their way. A requirement for common delivery-methods and techniques is being introduced by law in my country now anyway - for public sites, which should mean solutions at the user-end will make the need for more accessible solutions at our end a non-issue over time - in Norway. What kind of leveling that is missing/introduced/necessary in other parts of the world is somewhat unknown to me, but providing accessible solutions on a technical level - and pretty much limit it to that, is the only common and sensible approach if we want some progress, IMO. Promoting the need for accessible solutions on a technical level on top of existing and future web standards, should keep us busy enough for quite a while. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Please help! - CSS Drop Down not working under IE 6
Cole Kuryakin wrote:
First, go here under IE 6: http://www.crewasia.ph/index.php
The drop down menuing system at the very top of the screen DOES work
(it drops down correctly). You can even select the FIRST menu item on
each drop down menu. But, when you try to cursor over any other menu
item, POOF! The menu disappears!
The absolute positioned dropdowns are stacked behind the header, even
though they appear visually in front. This prevents interaction below a
certain point in both IE6 and IE7.
Try adding...
#navTop {position: relative; z-index: 1;}
...to fix that IE/win stacking of A:P elements bug.
I've only tested that it works in IE7.
regards
Georg
--
http://www.gunlaug.no
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] IE6 3-pixel jog victim
Jens-Uwe Korff wrote: thanks very much for your solution - it works perfectly. Could you please explain how the margin works with IE6? I wonder how the top margin eliminates the left margin when I apply it. Thank you. Not sure I understand your question - which margin eliminates what, since there's a zero margin-left on the paragraph in my example. The paragraph is hanging on its right margin - floated right with a declared width, which means a left margin isn't needed. That's the trick, and would work the same in all browsers - if they could see these styles. IE6 ignores margin-bottom on floats in your line-up - an IE6 bug, so I instead introduced margin-top for both the paragraph and the dl to preserve the vertical spacing and line-up. The negative margin on the floated ol then compensates for these top margins that are pushing the whole line-up downwards, by moving the entire ol upwards. BTW: your page suffers from the em font-resizing bug in IE5 - IE7[1]. regards Georg [1]http://www.gunlaug.no/contents/wd_additions_13.html -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] IE6 3-pixel jog victim
Jens-Uwe Korff wrote:
I have restyled a timeline but have come stuck with IE6's 3-pixel
jog.
I cannot apply the usual remedy (floating the paragraph) as I need
any element next to the floated offender to be indented. Hence the
paragraph has a left margin which cannot be zero.
http://creativespirits.info/aboriginalculture/history/aboriginal-history-timeline.html
You haven't exhausted the 'float' property yet.
By adding...
* html ol.timelineList dl {clear: both; margin-top: 1em;}
* html ol.timelineList li p {float: right; width: 500px; margin: 1em 1em
0 0; clear: right;}
* html ol.timelineList {float: left; margin-top: -1em;}
...you'll get rid of the 3-pixel jog and keep indentation.
The indentation will then be depending on the paragraph-width - not the
left margin, in IE6, and the whole line-up can be tuned to taste.
Note: the em font-resizing bug in IE5 - IE7...
http://www.gunlaug.no/contents/wd_additions_13.html
...is hitting your creation hard.
regards
Georg
--
http://www.gunlaug.no
***
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [EMAIL PROTECTED]
***
Re: [WSG] Conflict between Mime Type and Document Type
Designer wrote: Maybe, but coding in xhtml1.1 makes you MUCH more fussy about syntax etc. and it shows up any 'well formed' errors as soon as you browse. So, whilst the user will know nothing about all this, it makes you as a designer get lots of practice in using the stricter syntax, ready for some day in the future when you will need it. Maybe :-) Yes, Maybe :-) I don't know if this is a stable feature, but when I write documents in XHTML 1.0 (intended to be served as 'text/html'), Opera 9.5 beta (build 9694) treats it as 'text/xml' off-line and refuses to render it if it isn't well-formed and up to standard. Same document is treated as 'text/html' on-line - as intended. Opera's behavior gives me immediate feedback during the design-phase without having to bother with MIME type switching. No such on/off-line MIME type switching in available versions of other browsers AFAIK. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] This IE8 controversy
Well, apart from that I don't like IE/win version targeting one bit, if MSIE uphold this version targeting strategy in future versions, we may as well use it to our advantage. Sidelining IE/win while designing for standards and better browsers, doesn't have to become a problem for designers or users, as we can keep on designing for the present edge at any given time, and fix IE/win when we get around to it. That's how I go about it now anyway, and version targeting will only make it easier to cover all IE/win versions that are still in use at any one time. We won't need several IE/win versions in order to test and tweak, as we can just roll back the latest IE/win through previous versions during the design-phase - providing previous versions are flawless copies that we can target. Once finished, we can decide which IE/win version is most suitable as our own IE-final for that particular job, and leave it there. Other browsers won't be affected - as long as they stay well away from any form of version targeting. Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
Re: [WSG] Compatibility and IE8
Ben Buchanan wrote: Implementation specifics aside (yes I still think it's spam), the version target feature offers us a chance to lock our sites to the most convenient version of IE. MS has invited us to ignore their newer products. We can opt to save our energy for standards-based browsers and not bother learning new versions of IE. Lazy? Pragmatic? Mercenary? Discuss? :) Surely this list has some opinions... All of the above - depending on the situation at hand. Being practical, it all comes down to what IE8 is worth - in any mode, once it's released and thoroughly tested. - IE6 and IE7 will need their workarounds for a few years, so it's mostly business as usual on the IE/win front even after IE8' arrival. - If IE8 can do without its own workarounds and isn't disturbed by any workarounds for its predecessors, then triggering IE8 mode doesn't cost anything. If not, then the most solid workarounds have to be found and tested before seriously leaving the IE7 forever mode - if that mode really works. The way the proposed switch works, we should be able to relax and not bother looking for IE8 fixes until after IE9, or IE10, is out - just to see how the browser is shaping up. - If clients expect and/or demand triggering of a beyond IE7 mode (which they probably won't), then they'll get it once any problems with it are solved. Bottom line: I don't like this new switch one bit, but I'm pretty relaxed on the matter and will trigger a suitable beyond IE7 mode if it serves any purpose - for me. regards Georg -- http://www.gunlaug.no *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: [EMAIL PROTECTED] ***
