More Disruptive Innovations | Hacking for Christ

I need to go on holiday more often, if people come up with smart ideas like HTML overlays while I am away. Kudos to Dan Glazman and Laurent Jouanneau of Disruptive Innovations (obviously a wise hiring, Dan :-).

My first thought is: if and when we get browsers with native overlay support, how do you prevent the backwards-compatibility JavaScript executing and thereby including two copies of the overlay contents? You’d need to mark the script in some way to indicate that it was the special overlaying script, so the UA could ignore it. I see four options, all horrible:

Require that the script have a specific name, e.g.”HTMLoverlays.js”
Specify a correct “type” attribute and then abuse the deprecated “language” attribute (assuming this works in common browsers), e.g. language=”HTMLOverlays”.
Put a magic value inside the <script> tag, e.g. <script src=”…” …>HTMLOverlay</script>. This content should be ignored by compliant UAs if the <script> has a src attribute.
Use a <link> tag with a special “rel” to provide an alternate link to the script; the UA matches up the two filenames and ignores the script.

Any more ideas for solving this problem?

16 thoughts on “More Disruptive Innovations”

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.

Nicholas on September 6, 2004 at 10:22 PM said:

HTMLoverlays.js:

if (!browserSupportsOverlays())
{
// do overlay compatibility stuff
}
Gerv on September 6, 2004 at 10:47 PM said:

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
Vidar Braut Haarr on September 6, 2004 at 10:57 PM said:

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;

;)
Vidar Braut Haarr on September 6, 2004 at 10:58 PM said:

Erm, it seems my HTML code was removed:
<script version=”HTMLOverlay” src=”.” />
dantealiegri on September 6, 2004 at 11:00 PM said:

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?
Nicholas on September 7, 2004 at 1:56 AM said:

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?
Daniel Glazman on September 7, 2004 at 8:46 AM said:
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
Axel Hecht on September 7, 2004 at 9:50 AM said:

why not just use
document.implementation.hasFeature(“moz-overlays”,”1.0″)

in the script? Or call the whatwg-overlays ;-)
Justin Wood (Callek) on September 7, 2004 at 10:03 AM said:

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.
Daniel Glazman on September 7, 2004 at 10:53 AM said:

and because you don’t want to load the script at all if you can avoid it…
Daniel Glazman on September 7, 2004 at 12:00 PM said:
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:-)
Justin Wood (Callek) on September 7, 2004 at 3:13 PM said:

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).
Justin Wood (Callek) on September 7, 2004 at 3:14 PM said:

ok it ate my html <link /> was to go before the work “is” on the second sentance.
Daniel Glazman on September 7, 2004 at 8:09 PM said:

Callek: according to my tests, at least Gecko-based browsers and all flavors of IE I have here can accept that non-empty LINK.
Gerv on September 7, 2004 at 11:38 PM said:

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?
Daniel Glazman on September 9, 2004 at 9:20 AM said:
```
Could this extension to the HTML spec be a WHATWG thing?
```
Why not? Let’s ping Hixie.