Dear CSS listers,
A fortuitous default syntax for linking stylesheets in BBEdit has caused me
to stumble upon a method for hiding CSS from OmniWeb (4.1 and 4.11). This
has been a holy grail of mine for a while, so excuse me if I am feeling a
bit pleased with myself right now.
The following link methods are visible to OmniWeb:
<link rel="Stylesheet" rev="Stylesheet" href="owshow.css" type="text/css"
<link rel="Stylesheet" rev="Stylesheet" href="owshow2.css" type="text/css"
The following link methods are NOT visible to OmniWeb. Note the capital
letter at the beginning of the media attribute value.
<link rel="Stylesheet" rev="Stylesheet" href="owhide.css" type="text/css"
<link rel="Stylesheet" rev="Stylesheet" href="owhide2.css" type="text/css"
I have tested this on:
IE5.2 (Mac OS X)
IE 4.5 (Mac OS classic)
IE 4.0 (Mac OS classic)
iCab 2.8x (OS X and Classic)
Opera 5/Mac (OS X)
Opera 6/Mac (beta 2 OS X)
Netscape 4.77 (Mac OS Classic)
Chimera (and thus presumably other Mozilla based browsers)
Is it correct to use an initial cap in media types? I don't have a
definitive answer. It appears that OmniWeb is the only browser actually
following the HTML spec here: http://www.w3.org/TR/html4/types.html#h-6.13
"A case-sensitive match is then made with the set of media types defined
above. User agents may ignore entries that don't match."
Confusingly, the CSS2 spec contradicts this:
"Media type names are case-insensitive. "
My inclination is to follow the CSS spec not the HTML spec, in which case
OmniWeb is wrong and everyone else is right (are we surprised?). Some
clarification from the W3C or those who know its mind will be welcome at
this point. A "rules lawyer" could argue that case-sensitivity would apply
to media types defined in link elements but that @media and @import
notations have case-insensitive media types. This is needlessly complicated,
and in my view the HTML spec is the one that should be changed.
(Extraordinary that OmniWeb manages to pick up one obscure thing in the HTML
spec that it implements to spec, but misses something completely obvious
like positioning of absolutely positioned elements that are children of
relatively positioned elements.)
I don't have a PC at home and thus would welcome information on whether this
works in IE5/Windows (or indeed even IE4), Konqueror or other PC-hardware
I have placed a test page at MacEdition for people to verify this and to let
me know (on-list or off-list) whether this works for browsers other than the
ones I have tested:
It seems to work for both XHTML and HTML documents and thus link elements
with a trailing / and without.
If this proves to be a robust hiding method, this could be a step forward
for web authors with large proportions of OS X users in their audience. All
we have to hope now is that OmniGroup doesn't "fix" this behaviour to match
other browsers before it finally implements the rest of CSS2 properly.
My reading of this, and of various reputable books on the subject (anything
by Eric Meyer or Briggs et al) is that absolutely positioned items are
positioned relatively to their containing block, where the containing block
is the nearest parent element that is positioned as something other than
static, eg relative. If there is no such positioned parent, then the
absolutely positioned element is positioned relative to the initial
containing block, ie HTML or BODY, I forget which. OmniWeb positions all
absolutely positioned elements relative to the initial containing block.
This might explain all the footer DIVs sitting at the top of windows in
CodeBitch at MacEdition
Cracking the whip on your naughty HTML since 2000
Sponsored by www.westciv.com - CSS resources | software | learning