Hacking for Christ

HTMLoverlays.js:

if (!browserSupportsOverlays())
{
// do overlay compatibility stuff
}

Nicholas: how would you write the "browserSupportsOverlays()" function in a way that meant it didn't have to be updated when new browsers were released?

Gerv

What about using the version attribute for something useful? :)

Or perhaps add a freaky var to the script:
var MOZILLA_ORG___THIS_CONST_SHOULD_NEVER_BE_USED_UNLESS_YOU_KNOW_WHAT_YOU_ARE_DOING___GOT_IT_ = 1;

;)

Erm, it seems my HTML code was removed:
<script version="HTMLOverlay" src="." />

Gerv: maybe write it in a way that contains those known not to work then? IE, check for UAs of those known not to work?

function browserSupportsOverlays()
{
return typeof(document.supportsHtmlOverlays) != "undefined" && document.supportsHtmlOverlays;
}
or something to that effect.

Of course, if all this can be done with scripting, why bother with explicit browser support?

You pinged me about it yesterday night, so I spent a few hours on the problem. I see only one solution that (a) is compatible with legacy browsers (b) is not intrusive and declarative.

The solution is "something like" two new attributes called "ifsupported" and "ifnotsupported". Just don't comment on the names please, that's not the important point here.

The attributes' value is a comma-separated list of the following functional notations:

• type(t)
• namespace(ns)
• element(ns, e)
• attribute(ns, e, a)
• feature(f)
• feature(f, subf)
• plugin(p)

where all arguments are strings.

• type(t) is true if the mimetype t is natively supported and rendered by the UA
  • ex: type('text/html')
• namespace(ns) is true if the namespace ns is natively supported and rendered by the UA
  • ex: namespace('http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul')
• element(ns, e) is true if namespace(ns) is true and if the element type e is supported in that namespace by the UA
  • ex: element('http://www.w3.org/1999/xhtml', 'object')
• attribute(ns, e) is true if element(ns, e) is true and if the attribute is supported on the element type in that namespace
  • ex: attribute('http://www.w3.org/1999/xhtml', 'dl', 'compact')
• feature(f) is true if the UA supports natively that feature, even partially
• feature(f, subf) is true if the UA supports natively that feature, even partially
  • ex: feature('css2')
• ex: feature('HTMLOverlays')
• ex: feature('css2', ':counter')
• plugin(t) is true if the UA has a registered plugin for the mimetype t

The two attributes are not exclusive. The element carrying the attributes is rendered/loaded/applied/executed/whatever only if all the conditions specified in the "ifsupported" attribute are true and all the conditions specified in the "ifnotsupported" attribute are false.

That way, you could just write:

<script src="HTMLOverlays.js" ifnotsupported="feature('HTMLOverlays')" ... />

No JS, extensible to any other HTML element, easily replaces NOFRAMES and NOSCRIPT element, object-friendly, etc. Furthermore, the attributes won't be understood by legacy browsers, so they will load and apply the script anyway.

I am pretty sure that the HTML Keepers of the Temple are going to scream about it, but I think it's a nice solution that solves backwards compatibility in a quite simple way.

Daniel

why not just use
document.implementation.hasFeature("moz-overlays","1.0")

in the script? Or call the whatwg-overlays ;-)

Axel: because if document.implementation.hasFeature ... is not defined, it will spark an error.

try{}catch{} is not supported in all UA's, and any solution which involves JS is just "bloat" on this that really shouldnt need to be hacked in to support a new UA feature, such as overlays.

and because you don't want to load the script at all if you can avoid it...

I have found a better way IMHO:

change the content model of the link element in new browsers to accept script and link element. Those inner script and link elements are used as a fallback if the rel/rev attributes on the link element are not recognized by the user-agent.

for example:

<link rel="HTMLoverlay" href="myoverlay.xml">
  <script src="HTMLoverlay.js" ....>
</link>

Legacy browsers accept it w/o problem and load the script, new browsers supporting rel="HTMLoverlay" drop the script element:-)

Daniel,
The latter wont feasably work, IMHO...

is defined as "must be empty" in HTML 4.01... many UA's will never understand it to be filled, and if we allow it to be, are we not *effectively* breaking old pages?

we could always use of course, but that defeats half the purpose of this (since we would need a mime-type for the overlay).

ok it ate my html <link /> was to go before the work "is" on the second sentance.

Callek: according to my tests, at least Gecko-based browsers and all flavors of IE I have here can accept that non-empty LINK.

Of course, if all this can be done with scripting, why bother with explicit browser support?

Because you may want overlays to continue to work if JS is turned off, and you may want to support overlays in e.g. Lynx, which doesn't support JS at all.

change the content model of the link element in new browsers to accept script and link element.

That's really smart :-) I like that a lot, and it works in the same way as e.g. <object>. Could this extension to the HTML spec be a WHATWG thing?

Could this extension to the HTML spec be a WHATWG thing?

Why not? Let's ping Hixie.