Brother Cake

I've been waiting for something like this :D

-- user-agent/objection detection - I basically agree; object and feature
detection is much cleaner and easily allows for forward compatibility.
Having said that, they are not panaceas; there are a couple of serous
problems:

The support detection method "hasFeature" is somewhat spurious, because it
only returns a boolean; what if a browser only partly supports a spec, or
supports it with a buggy implementation - to return true would imply full
support, which it doesn't have, but to return false would imply no support,
which isn't the case either.

Object detection has similair issues, in that a browser may declare support
for an object or collection, when its support is buggy, incorrect or
incomplete in some way. Potentially, we can end up inferring support for
properties or methods which are not actually supported at all.

This kind of thing crops up with monotonous regularity, as I'm sure you
know.  And it eventually means there are circumstances here and there where
you do have to know exactly which version of which browser on which OS
you're dealing with. This is more and more the case as you build in
eye-candy features and try to get them to look consistent x-browser.
Layouts have to be consistent - to the extent that some of the navbar
dimensions and positions have to be pixel-perfect; like, exactly the same in
every supported browser.  Corporate users demand this; and hacks are nearly
always necessary to acheive it; it feels like every day I bemoan that
reality ... but reality it is ...

So I see it like, if, in-practise, you're commited to user agent sniffing
anyway, why not just stick with it as the fundamental paradigm?

Well ... that's slightly rhetorical because why not is obvious - and I do
take your point.  But I have to be practical; provide feature-rich content
which "works or be damned", and to that extent it's irrelvant how stupid,
arcane or non-compliant a hack I have to come up with, if feature X simply
*must* work. It makes no difference to the end user if there are 50
different browser-specific scripts in the API, because they only have to
load one of them. Obviously that's ridiculous, but there's a truism there.

Maybe the ideal is to use a combination of methods - group by collection
support, and then subgroup browsers within them; within the sniffer script
that's fundamentally what I'm doing - I generaly only use UA strings when
there isn't anything else (eg - it is not possible to identify netscape 4 in
a new session from a script within the HEAD section that looks for
document.layers - in that specific situation, the layers collection returns
undefined)

It does make support rather a chore; but it's gonna be a chore anyway - you
simply can't trust that future browser releases will be okay; you do have to
test and tweak because all browsers have bugs, and because not showing up at
all is infintely better than showing up screwed. But O7 is a  pleasing
example - I only had to change two lines of code to make it work, and they
were only because of rendering bugs in the browser :)


-- multi-level menus - yeah that's fair; I need to address that pretty soon
... although I do have reservations .. because allowing infinite sub-levels
introduces the possibility that users can create a menu layout which is
impossible to render in Opera 5 and 6 ...


-- browser support - cool ... I didn't know about Safari so i'll check that
out (thanks for the tip, although it does mean I'll have to buy a new mac
because my 6100 wouldn't be able to handle OSX!)

I'm impressed you've got ICEBrowser support ... i'm finding it such a pig,
and icesoft are such obstreperous SOBs (anyone would think they don't want
the support of developers ... that's how they come across)

But I'm gonna take you up on some of them:

- your menu is basically screwed in Espial Escape (4.85) - the layers are
all printed twice and overlap each other, which is about the same as mine
was doing until i excluded it.

- there are similar problems in linux/netscape 4 - gaps and vertical
layer-misalignments in the nav and menus.

- in mac/ie4 the menus go underneath the page text, and those which are
obscured don't receive events

- you haven't really got WebTV support - the menus don't work at all, but it
seems you've coded the main navbar to appear in browsers which can support
just that; fair enough - but my script can do that as well - there's a lot
of documentation about degrading with low-spec, legacy and noscript
browsers, and the script has a "virtual alignment" mode which was
specfically designed for this. I'm gonna guess that the other web tv clients
you support are the same?

- Konqueror is supported with version 3 but not 2.2 - the menus are
unuseable - they close when you hover over them, which I'm guessing is some
event bubbling oddity.


I very much appreciate your comments; you've given me some interesting
things to think about.  But the way it adds up ... I think my claim is still
true :)



James

>> your menu is basically screwed in Espial Escape (4.85)
> Yes, you are right. You have to leave the page alone to load completely
> before you try to do anything (even scrolling). Even then, it only lays it
> out correctly about half of the time. With that browser, I accept less than
> pixel-perfect displays, just like you have to with Opera 5 (because of its
> cellspacing->cellpadding-bottom bug). Also, more importantly, it's
> mouseover/out detection is pathetic, and it only detects them sometimes, so
> the menus close when they shouldn't.


I see; I don't really consder Escape a dhtml-capable browser at all, because
of its UA behaviour - the fact that it can completely spoof its own identity
(as opposed to Opera which you can still identify in all its spoof
settings) - to my mind it is counter-productive to create a browser which is
not detectable at all via its UA string.  Object detection really isn't
enough here, because it isn't netscape 4 or anything like. ICE also lies
like this, but at least it has a unique property "navigator.__ice_version";
maybe escape has something similar you know of?

I can't say I've had the Opera 5 problems you're talking about; apart from
its obvious lack of support for element creation and modification, I've not
had any serious issues with it. I even found a hack round its lack of offset
properties, which I can tell you about if you;re interested.


>> in mac/ie4 the menus go underneath the page text, and those which are
>> obscured don't receive events
> Not on the version of Mac IE4 my colleague has here. What IE4 version do you
> have?

I have 4.01 on MacOS 9


>> you haven't really got WebTV support - the menus don't work at all
> they do ... viewer 2.6. PP:K said his did not work in it either, but they do
> in 2.6. As WebTV automatically updates, you only have to consider the latest
> version, and that is the latest viewer.

Oh I see ... you have to click them to open.  Cool.   I'd still be a bit
worried about using them though - some of them appear outside the window,
and with no h-scrolling you end up with some menus and links that are not
accessible.  Nonetheless - nice one.


>> Konqueror is supported with version 3 but not 2.2
> I noticed that. There are several problems in KJS 2, largely due to its mis
> handling of events and ignoring object.onevent syntax. My menus do not use
> event bubbling.

Event bubbling happens whether you utilise it or not - if your mouse is,
say, in a div and you move it over a link inside that div, it will trigger
the onmouseout event for that div; so if your closing event is attached to
that, it will not give the behaviour you want unless you handle the event
bubbling explicitly. Personally, I've not encountered any event-related
problems in k2.2, but then, I don't really use mouseout events.


> Thanks for keeping me up to date with my own browser support.

Likewise :)


James

Yeah - putting the script at the end of the BODY is the only reliable
solution I know of  for virtual z-ordering in ie4 (and netscape 4 if you use
the menu on a page which already makes use of its layer collection, without
those being explicitly ordered by number).  Shame in one sense, because it
gives the false impression of slow menu-loading, when really it's just
because of the script being at the end.  But I think it's ultimately better
anyway - because IMO the page is more important than the navigation, so
users should be able to see that first.  One of my commercial competitors
makes a big trumpet about how his menu will be loaded before the page ...
but all he's done is put it at the beginning, and is therefore victim to
exactly this kind of issue.

I asked Espial tech guys if they have a unique property; I'll let you know
what they say.  Maybe Omniweb has "window.omniweb" or something - sounds
stupid to even try, but there have been times where just randomly guessing
at things has yielded useful results!

I see the O5 thing you're talking about ... pretty nasty; that explains a
discrepancy I had with the verttical-alignment of text, but I compensated
for it somewhere else without knowing what it was at the time.  Thanks for
the info.


J

dude, that's amazing :)  Thanks for keeping me informed, I very much
appreciate it.  I've actually bought a new iMac now (off eBay) which should
arrive at the weekend.  Looking forward to checking out Safari for myself :)


J

Brilliant - using your info, this:

if((agt.indexOf('mozilla')!=-1)&&(parseInt(navigator.appVersion)>=4)){
    exclude=0;
    ns4=1; 
    //this eliminates espial escape and omniweb
    if(typeof navigator.mimeTypes['*']=="undefined"){
        exclude=1;
        ns4=0;
        }
    }

Identifies netscape 4 while blocking escape and omniweb :)


Safari is a strange one ... PPK suggested "navigator.productSub"  which
at all settings returns 20021225 - I can confirm it works ... but
presumably this will change with each new build ....

It looks like a good browser - I'm seeing some small css and DOM
problems, similair to Konqueror's unsurprisingly, but nothing serious.


James

That's brilliant!  And your compatibility table is very nice; thanks for
taking the time to let me know about this, I very much appreciate it.

I'm working on some very fun stuff at the moment - using CSS to generate
menus, inspired by Eric Meyer's demo. So far I've come up with this -
http://www.brothercake.com/Ref/css_nav/page.php - it's only perfect in
gecko 1.2+ builds, but it's almost okay in safari, and degrades well in
others.

James

Interesting ... I do this to identify konqueror >= 2.2

if(typeof navigator.vendor!="undefined" && navigator.vendor=="KDE"){
    var thisKDE=agt;
    var splitKDE=thisKDE.split("konqueror/");
    var aKDE=splitKDE[1].split("; ");
    var KDEn=parseFloat(aKDE[0]);
    if(KDEn>=2.2){
        kde=1;
        ns6=1;
        exclude=0;
        }
    }


But when I tested it ... safari always returns undefined for typeof
navigator.vendor, even when spoofing as konqeuror; so your test, run in
a browser we've already established isn't konqueror, always identifies
safari :)


Yeah it seems Opera 7 does support the hover; it's weird, but the way I
had it, the whole cell - color, background and border - is an <a> with
a:hover doing the rollover background color.  It seems that's what broke
it in Opera 7 (and maybe explains why konqueror didn't work but safari
did; will have to check this again) - perhaps Opera doesn't like
processing two :hover pseudo-classes that happen at the same time.

Well I updated it now - doing the rollover with the li:hover - which
does mean that mac/ie5, oepra 6 and early gecko doesn't get the rollover
anymore, but the overall result is better - less CSS, and easier to
manage :)   Still has that rendering problem, and margin discrepancy
though ..


James

I am using the latest - build 2657 which is more recent than the public
alpha.  It's very strange - just adding a simple rule to the stylesheet,
like

a:hover { 
    color:#ff9900;
    }

Makes it stop working!

The IE problem is not the box model - I tried that already - I'm 99%
sure it's a bug in IE.  Have a look at that page and press Ctrl A to
select all - you see a little line of selected whitespace under each
main box?  That's not in any of the elements, it's a block-level
line-break space - except that the <ul>s in this case have their display
set to inline - in others browsers this makes the extra space go away,
but in IE it doesn't.  If I concetenate the entire list into one line of
HTML, the bottom three close up - because they *don't* have nested <ul>s
- but the links which do have nested lists, still have that whitespace.
Does that make sense? That's why I think it's a bug.

Wouldn't be the first ....:rolleyes:


J

That's great! position:relative on the li allows them flexibility of
movement, then the top position on the ul makes the others move *down*
except the affected ones ... I don't really understand the logic there
... Why that should happen ... But it is the desired effect :)

Unfortunate side effect is that the menus now have to be exactly
adjacent - if they inset and overlap, they appear underneath their
parent - and another position discrepancy, where the third level of
menus is right in the later mozillas, but indented in the others.


Thanks though - you've given me some interesting things to try.


J

I got another email from a guy I'd asked for help (off the evolt.org
mailing list - you a member of that? Very interesting)   He'd taken a
screeshot in moz1.3b on OSX and it was the same as the others (ie, *not*
the same as win/moz1.3a!)

So I decided to aquiesce; apply the margin globally and just don't worry
about those two builds being too high.  

And then .. I downloaded the latest Phoenix nightly (win/1.3b) and it's
alright again! So it's all cool in my mind :)


Thanks again for your help with this, I much appreciate it.


James

I thought you'd appreciate this -
http://www.brothercake.com/scripts/listmenu/

The key to it all (event-handling wise) is the prototyped contains()
method. Check it out :)


Cake

Thanks man - although it's looking like it's not gonna be needed for
anything other than token identification - very pleased about that, it's
nice to see OmniWeb has become a good browser, and certainly makes our
lives easier if there's on less renegade rendering engine to worry about
:)


Thanks for the info.


Cake