Re: [WSG] Konqueror and Galeon issues
I'm running Konqueror 3.4.1 w/ KDE 3.4.1 on Gentoo Linux and there
aren't any problems at all when I go to your website. Konqueror and
Firefox render it exacly the same. On top of that IIRC Galeon uses
gecko, which is the same thing Firefox, Mozilla, Epiphany, et al use so
they should render the same.
I don't know what is up w/ brosershots.org, but I don't think it's a
problem w/ your website. I think you can just safely ignore that.
Alan Trick
Webmaster wrote:
Hi all,
The fix provided the other day to clear floats and make disappearing content
re-appear worked well enough in most browsers.
However, having just performed a preview test at http://browsershots.org
(incidentally, this site deserves an award for its service to the web-dev
community), I'm horrified to discover that my third column is pulling back
into the centre in these two broswers.
The question is: should I care? Is this due to quirks in those browsers? All
others display just how I intended.
The screenshots can be viewed here:
http://browsershots.org/website/363651/
Do I simply need to apply my fix to ALL higher-level container divs?
/* Improved hack for Peekaboo bug which causes content from #middle
to disappear
if its height is less than that of #right. Include backjslash here
for IE5-Mac \*/
@media screen {
* html #middle { height: 0; }
}
/* end fix */
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
Re: [WSG] Clearleft.com
Webmaster wrote:
Georg, the fix doesn't suggest putting different values on html and
body (or did I miss the whole point?).
I understood the solution to be setting body and/or html to 100.01%
and then setting any other styles and text-level attributes with ems
or %. Did I get it wrong?
Not necessarily, but the fix for that particular IE-bug is to define
font-size in percentage on the highest level, html *or* body *or*
'another element', and not to define font-size in em above it. This can
be achieved in (at least) two ways.
Therefore:
html {font-size: 100%;}
body {font-size: (whatever-value)em;}
...is a perfect bug-fix with cross-browser reliable results.
and the usual:
html {/* no font-size defined at all */}
body {font-size: (whatever-value)%;}
...is also a perfect bug-fix with cross-browser reliable results.
My point was/is that any other value-combination that can be calculated
to end up as the right base-size will also fix the bug -- but seems to
only give the calculated results in IE/win.
---
My reason for mentioning the whole thing is that there are always the
possibility that some may try to be smart and rearrange those values
in the first example without running a thorough cross-browser test.
They may end up with a perfectly valid human bug in their page-code--
banging its head against against some nasty human bugs that ended up
as browser-code, and such wars of logic can give pretty unpredictable
endings. So, reason enough to mention it.
Sorry if I complicated the matter for some, but after 25 years of
trouble-shooting solutions around buggy software, the tendency to go in
depth is irresistible. Must be a human bug-- somewhere :-)
---
I've just done a complete run of screenshots using the above method
and can still see some variations in size, particularly at larger
sizes (h1-h3).
Minor variations are usually caused by browsers having different
'tip-over' values for recalculating em/% into physical screen-units.
Some 'tip over' between .99 and .00, while other 'tip over' around
.40-.50. A few levels of inheritance and such differences can become
quite noticeable, but they are more or less unavoidable--apart from by
keeping the number of levels low.
Aside from such minor variations; I got some really huge variations
during my own testing with different 'html+body' values. My need for
killing human bugs during any debugging-process is why I asked for
confirmations or corrections.
---
For the record: my own extreme font-resizing bug fix is to feed
standard-compliant browsers a 'pixel-defined font-size on body', and
feed IE/win a 'percentage-defined font-size on body' through a
'conditional commented' stylesheet that I'm using anyway. That seems to
work quite well across browser-land -- and the bug is dead.
Georg
--
http://www.gunlaug.no
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
[WSG] consistent fontresizing - the right way
The result from my sidestep in the 'Re: [WSG] Clearleft.com' thread is
clear, thanks to some off-list input. It _is_ quite possible to inject a
human bug surrounding font-size into CSS, and end up with pretty
logical but strange results.
No problems with IE/win this time though...
I'm sure many designers have experienced problems with broken layouts
caused by user-control. (I have broken a few dozen layouts during my
quick investigation, so there are plenty of examples around.) No use to
fight user-control, so why not take it into account and create more
robust layouts.
This:
html { font-size: 100%; /* IE hack */ }
body { font-size: 0.75em; }
...does always result in consistent resizing. However, it does not
prevent unnecessary breaking of some designs, *if* elements further in
are sized _up_.
The reason is simple-- and logical:
Browser-option; 'minimum font size', will act on any defined font-size
that is smaller than users set as acceptable. A few million web surfers
are using browsers with such an option, and I think a number of those
know how to, and do, set it for daily use.
Therefore, if web designers _start out_ with small values and size them
up further in, the result is that fonts throughout the entire layout is
sized up if the _start-value_ is too small with regard to 'minimum font
size'. That's inheritance at work, so no bugs involved.
However, if the _start-value_ is large and down-sizing is used further
in, then the result is that only the text that is too small with regard
to 'minimum font size' will be sized up. Most designs survives better
then, and the user gets the minimum font size he/she need.
---
While you're at it, be aware of the difference between 'visual size' and
'actual size'. Choosing font-family for its 'visual size' may end up as
something of a gamble when subjected to 'minimum font size'. Only a few
font-families have somewhat neutral size, where 'visual size' and
'actual size' is the same. 'Font size adjust'[1] doesn't work in any
browser AFAIK, and certainly not on browsers 'minimum font size' option.
Georg
[1] http://www.w3.org/TR/REC-CSS2/fonts.html#font-size-props
--
http://www.gunlaug.no
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
Re: [WSG] Clearleft.com
I thought it was a quite descriptive name for an old bug. Must be a
flaw in my Norwenglish... :-)
Your Norwenglish is good. Much better than my Englegen. I'd just
never heard the bug name before so was curious.
I normally just do
body {
font-size: 62.5%;
}
The size everything else as ems.
I officially don't care about Opera so am happy to avoid using 100.0%;
Yours
Andy Budd
http://www.andybudd.com/
01273 241355
07880 636677
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
[WSG] Default display property of a TR
What is the default 'display' property of a TR element? Is there somewhere you can look this sort of thing up? Thanks, Stephen -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.11.5/110 - Release Date: 22/09/2005 ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Clearleft.com
Andy Budd wrote: I officially don't care about Opera so am happy to avoid using 100.0%; Brighton designer in browser snub shocker...news at 11 ;) -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] Default display property of a TR
Taken from http://www.w3.org/TR/REC-CSS2/tables.html
The default style sheet for HTML 4.0 in the appendix illustrates the use
of these values for HTML 4.0:
TABLE{ display: table }
TR { display: table-row }
...
Hope that helps!
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Stevio
Sent: 23 September 2005 12:45
To: Web Standards Group
Subject: [WSG] Default display property of a TR
What is the default 'display' property of a TR element?
Is there somewhere you can look this sort of thing up?
Thanks,
Stephen
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.5/110 - Release Date:
22/09/2005
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
Re: [WSG] Clearleft.com
Andy Budd wrote:
Your Norwenglish is good. Much better than my Englegen. I'd just
never heard the bug name before so was curious.
No wonder they spoke funny over in Brighton. Oh well, that was a long
time ago...
I normally just do
body { font-size: 62.5%; }
The size everything else as ems.
I just broke a few pages that used that method--in Safari. User-control,
you know. Worked well in other browsers. That just to say that the
method isn't bullet-proof, but I guess you knew that.
I officially don't care about Opera so am happy to avoid using
100.0%;
Gosh, had I known that...
Get yourself a decent browser, man!
Good thing Opera is most often well in line with Safari then -- apart
from the former having fewer bugs. Besides, the mentioned font-size bug
in Opera was fixed a long time ago. Have they fixed the 'clear: none;'
bug in Safari yet?
regards
Georg
--
http://www.gunlaug.no
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
[WSG] RE: digest for wsg@webstandardsgroup.org
Please remove me from your mailing list. KENNETH KING Internet Media Designer www.sybrondental.com -Original Message- From: wsg@webstandardsgroup.org [mailto:[EMAIL PROTECTED] Sent: Friday, September 23, 2005 1:49 PM To: wsg@webstandardsgroup.org Subject: digest for wsg@webstandardsgroup.org WEB STANDARDS GROUP MAIL LIST DIGEST If you have suddenly been thrown into digest mode and don't know why, it's because your address was bouncing for at least 5 posts. To revert to a standard subscription, please log into the website - http://webstandardsgroup.org/manage/ - and select Edit your login details and mail list subscriptions from the members home page and change the selection toFull WSG list. You can change your subscription at any time and you can now select a different email address for WSG and WSGCMS list posts. You can also suspend email from these lists. To unsubscribe entirely and leave the group, please log into the website and select Unsubscribe from the members home page. You can reach Russ and Peter the list managers at info@webboy.net When replying, please edit your Subject line so it is more specific than WSG Digest There are some problems with the Digest version. Our apologies for this. It is the way that SmarterMail handles it so that HTML email and attachments are not put into the digest as source code. We are STILL talking with the software developers about this. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] html design - best practices
Dear WSG Team, It's been my pleasure to be with you all these days. Now that I am not doing CMS any more, I wish to be removed from the list. I could not find any link on the site to unsubscribe. So, I request the moderator to remove me from the list. Thanks in advance. Hope you all enjoy continuing with Web and CMS. With warm regards, S. Gudur __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Semantics of address?
G'day I'm just wondering how you all use the address element, or how you think it -should- be used? There are several threads in the list archives about it. Here's a couple: http://www.mail-archive.com/wsg@webstandardsgroup.org/msg11099.html http://www.mail-archive.com/wsg@webstandardsgroup.org/msg17576.html Regards -- Bert Doorn, Better Web Design http://www.betterwebdesign.com.au/ Fast-loading, user-friendly websites ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] consistent fontresizing - the right way
On Sep 23, 2005, at 4:17 AM, Gunlaug Sørtun wrote:
html { font-size: 100%; /* IE hack */ }
body { font-size: 0.75em; }
...does always result in consistent resizing. However, it does not
prevent unnecessary breaking of some designs, *if* elements further in
are sized _up_.
The reason is simple-- and logical:
Browser-option; 'minimum font size', will act on any defined font-size
that is smaller than users set as acceptable.
Georg,
I haven't seen this documented anywhere. Do you have links? These
preferences effectively set a floor below which no value may be
inherited, radically changing the intent of the preference setting.
I went ahead and created a test page. It seems that this is a
significant problem in all browsers I tested except IE (because it
doesn't support the user preference) and Safari (because it applies
the filter on the final calculated value).
http://www.bivia.com/sandbox/demo/minimum-font-size-inheritance.html
This is very disheartening. It means that if you want to take into
account people setting minimum font sizes, you need to radically
change how you set up your fonts. For example, instead of this
typical setup:
div.content { font-size:0.875em; }
div.content h2 { font-size:2em; }
...you will need to use this:
body { font-size:1.75em; }
div.content h2 { font-size:1em; }
div.content p { font-size:0.5em; }
--
Ben Curtis : webwright
bivia : a personal web studio
http://www.bivia.com
v: (818) 507-6613
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
[WSG] Re: ol displaying 3.1 3.2 etc. instead of 1 2 3
There are Javascript Table of Content (TOC) scripts out there that can do this. Problem is, they don't work if Javascript isn't available. CSS 2.1 introduced support for this with list counters. Problem is, many browsers don't support list counters. I have a purely server-side (PHP) solution that works well. In fact, I've been meaning to put together an article on how I built it. With one or two PHP functions, and a data structure that represents your table of contents, you can build them very easily. It also allows you to abstract the entire structure of the page and insert links to any section of the document. Have a look at: http://loadaveragezero.com/hnav/help.php for a fairly complex example of a nested TOC like this. If you view the PHP source, you can see how it works. http://loadaveragezero.com/src/view/hnav/help.php For you validity fans, the results are XHTML 1.1. Doug From: Daniel Nitsche [EMAIL PROTECTED] Date: Wed, 21 Sep 2005 21:31:50 +1000 Subject: Re: [WSG] ol displaying 3.1 3.2 etc. instead of 1 2 3 There is something on this very topic in the WCAG: http://www.w3.org/TR/WCAG10-HTML-TECHS/#lists Cheers, Daniel Nitsche On 9/21/05, Taco Fleur - Pacific Fox [EMAIL PROTECTED] wrote: Is there any way to make list look like 3.1 text text 3.2 text text 3.3 text text 3.4 text text Instead of 1 text text 2 text text 3 text text 4 text text I am thinking NOT with plain markup, but I could be wrong (just checking). And how would someone else do this? Just use ul and put the numbering within the list item as text? -- Douglas Clifton [EMAIL PROTECTED] http://loadaveragezero.com/ http://loadaveragezero.com/app/s9y/ http://loadaveragezero.com/drx/rss/recent ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
