Writing forward-compatible websites

103 views
Skip to first unread message

Boris Zbarsky

unread,
Aug 22, 2011, 10:22:52 AM8/22/11
to
Backstory: I think we should create and publicize an MDN article on
writing forward-compatible websites and webapps. That means websites
and webapps that will have a minimal chance of behavior changes as
browser updates happen.

Some items I have so far for a best practices list to accomplish that:

1) Avoid or minimize use of on* content attributes on elements,because
barewords in such attributes are resolved against IDL properties on
those elements before being resolved against function names in global
scope, so adding new IDL properties can break scripts in such attributes.

2) Avoid assuming that sniffing a particular object or capability
implies anything about the presence or absence of other objects,
capabilities, or bugs.

3) Don't UA-sniff.

4) Avoid cutting-edge nonstandard features.

5) Avoid malformed HTML. I'm not sure how to best describe this one,
because the bar here is much lower than "pass the validator"; it's more
like "don't require token-level fixup", so that tag names don't become
attributes as in markup like "<input </form>".

Any other suggestions? Any objections to the above? Modifications to
the above?

-Boris

L. David Baron

unread,
Aug 22, 2011, 10:43:56 AM8/22/11
to Boris Zbarsky, dev-pl...@lists.mozilla.org
On Monday 2011-08-22 10:22 -0400, Boris Zbarsky wrote:
> Backstory: I think we should create and publicize an MDN article on
> writing forward-compatible websites and webapps. That means
> websites and webapps that will have a minimal chance of behavior
> changes as browser updates happen.
>
> Some items I have so far for a best practices list to accomplish that:
>
> 1) Avoid or minimize use of on* content attributes on
> elements,because barewords in such attributes are resolved against
> IDL properties on those elements before being resolved against
> function names in global scope, so adding new IDL properties can
> break scripts in such attributes.
>
> 2) Avoid assuming that sniffing a particular object or capability
> implies anything about the presence or absence of other objects,
> capabilities, or bugs.
>
> 3) Don't UA-sniff.
>
> 4) Avoid cutting-edge nonstandard features.

I'd include vendor-prefixed features here too, or perhaps as a
separate point, but with the exception that it's ok to use
vendor-prefixes to support older versions of browsers as long as
they're not needed for the current versions of any browser (and such
that the non-prefixed form is always the one that wins in current
versions).

> 5) Avoid malformed HTML. I'm not sure how to best describe this
> one, because the bar here is much lower than "pass the validator";
> it's more like "don't require token-level fixup", so that tag names
> don't become attributes as in markup like "<input </form>".
>
> Any other suggestions? Any objections to the above? Modifications
> to the above?

6) Don't leave experiments that didn't work in your content. For
example, if you tried using a CSS property to do something you
wanted, but it didn't have any effect, remove it. It might do
something in the future.

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla Corporation http://www.mozilla.com/ 𝄂

L. David Baron

unread,
Aug 22, 2011, 10:46:45 AM8/22/11
to Boris Zbarsky, dev-pl...@lists.mozilla.org
Also:

7) Never target hacks (e.g., targeting a particular browser with
one bug to work around another bug, such as targeting older IE
versions with *>html selectors) at the *current* version of a
browser. In other words, don't assume that bugs that are currently
perfectly correlated will stay correlated in the future. (It may,
however, be ok to do this if the bugs are no longer present in
current browser releases and are therefore known to have been fixed
simultaneously.)

Jeff Hammel

unread,
Aug 22, 2011, 11:27:14 AM8/22/11
to dev-pl...@lists.mozilla.org
These all sound good, and FWIW I think this is a much better approach
than trying to answer the backwards-compatability question.

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

Gijs Kruitbosch

unread,
Aug 22, 2011, 11:38:28 AM8/22/11
to

4b) if you do add cutting-edge features (even standard ones), feature-test and
always ensure that fallback paths are also tested.

(I just had a rather nasty surprise when the PM said "let's release this with
feature X turned off", and on doing the beta deploy discovering the fallback
path had regressed since it was last tested)

Cheers,
Gijs

Joshua Cranmer

unread,
Aug 22, 2011, 11:46:56 AM8/22/11
to
On 8/22/2011 9:22 AM, Boris Zbarsky wrote:
> 1) Avoid or minimize use of on* content attributes on
> elements,because barewords in such attributes are resolved against IDL
> properties on those elements before being resolved against function
> names in global scope, so adding new IDL properties can break scripts
> in such attributes.

I'm not sure what you mean here. Do you mean I shouldn't do, e.g., <body
onload="alert('Hi!')"> ?

> 4) Avoid cutting-edge nonstandard features.

Here, it would be nice to have an idea of what you mean by cutting-edge
nonstandard features. For CSS, I suspect you intend to mean any feature
which is prefixed; I don't know what the equivalent level is for HTML/SVG...


>
> 5) Avoid malformed HTML. I'm not sure how to best describe this one,
> because the bar here is much lower than "pass the validator"; it's
> more like "don't require token-level fixup", so that tag names don't
> become attributes as in markup like "<input </form>".

This might be better worded as "write your HTML like XML", perhaps with
the exception that normally self-closing tags like <br> don't need the /
at the end.

> Any other suggestions? Any objections to the above? Modifications to
> the above?

Any page working across the latest versions of any 3 of Internet
Explorer, Firefox, Opera, Safari, and Chrome without needing to do any
sniffing whatsoever (UA sniffing, CSS hacks, feature detection) should
be forward-compatible.

Kyle Huey

unread,
Aug 22, 2011, 11:55:26 AM8/22/11
to Joshua Cranmer, dev-pl...@lists.mozilla.org
On Mon, Aug 22, 2011 at 11:46 AM, Joshua Cranmer <Pidg...@verizon.net>wrote:

> Any other suggestions? Any objections to the above? Modifications to the
>> above?
>>
>
> Any page working across the latest versions of any 3 of Internet Explorer,
> Firefox, Opera, Safari, and Chrome without needing to do any sniffing
> whatsoever (UA sniffing, CSS hacks, feature detection) should be
> forward-compatible.


That's not necessarily true though. The global namespace pollution stuff
that we're trying to get changed in the spec come to mind here ...

I suppose one can find a counter-example for pretty much any rule we try to
come up with though, and this is probably a good guideline in general.

- Kyle

Jesper Kristensen

unread,
Aug 22, 2011, 1:22:48 PM8/22/11
to
Den 22-08-2011 16:43, L. David Baron skrev:
> On Monday 2011-08-22 10:22 -0400, Boris Zbarsky wrote:
>> 4) Avoid cutting-edge nonstandard features.
>
> I'd include vendor-prefixed features here too, or perhaps as a
> separate point, but with the exception that it's ok to use
> vendor-prefixes to support older versions of browsers as long as
> they're not needed for the current versions of any browser (and such
> that the non-prefixed form is always the one that wins in current
> versions).

Same applies to feature detection of "very much not cutting edge
features". When using feature detection, try to ensure that the newest
versions of all browser engines use the same code path.

-Jesper Kristensen

Boris Zbarsky

unread,
Aug 22, 2011, 3:33:03 PM8/22/11
to
On 8/22/11 10:46 AM, L. David Baron wrote:
> Also:
>
> 7) Never target hacks (e.g., targeting a particular browser with
> one bug to work around another bug, such as targeting older IE
> versions with *>html selectors) at the *current* version of a
> browser.

That's my #2, really, but maybe we should phrase it both ways to drive
the point home...

-Boris

Boris Zbarsky

unread,
Aug 22, 2011, 3:36:05 PM8/22/11
to
On 8/22/11 11:46 AM, Joshua Cranmer wrote:
> On 8/22/2011 9:22 AM, Boris Zbarsky wrote:
>> 1) Avoid or minimize use of on* content attributes on elements,because
>> barewords in such attributes are resolved against IDL properties on
>> those elements before being resolved against function names in global
>> scope, so adding new IDL properties can break scripts in such attributes.
>
> I'm not sure what you mean here. Do you mean I shouldn't do, e.g., <body
> onload="alert('Hi!')"> ?

Precisely.

>> 4) Avoid cutting-edge nonstandard features.
>
> Here, it would be nice to have an idea of what you mean by cutting-edge
> nonstandard features. For CSS, I suspect you intend to mean any feature
> which is prefixed; I don't know what the equivalent level is for
> HTML/SVG...

Yeah, things here are fuzzy. Basically, anything that's not implemented
interoperably by all 4 of Presto, Trident, WebKit, Gecko should probably
be avoided.

>> 5) Avoid malformed HTML. I'm not sure how to best describe this one,
>> because the bar here is much lower than "pass the validator"; it's
>> more like "don't require token-level fixup", so that tag names don't
>> become attributes as in markup like "<input </form>".
>
> This might be better worded as "write your HTML like XML", perhaps with
> the exception that normally self-closing tags like <br> don't need the /
> at the end.

Hmm... Perhaps.

>> Any other suggestions? Any objections to the above? Modifications to
>> the above?
>
> Any page working across the latest versions of any 3 of Internet
> Explorer, Firefox, Opera, Safari, and Chrome without needing to do any
> sniffing whatsoever (UA sniffing, CSS hacks, feature detection) should
> be forward-compatible.

That happens to be not true, sadly. Witness the "<input </form>" case
which worked fine in all browsers until they started adding support for
@form.

-Boris

Jesper Kristensen

unread,
Aug 22, 2011, 4:07:11 PM8/22/11
to
Den 22-08-2011 21:36, Boris Zbarsky skrev:
> Witness the "<input </form>" case
> which worked fine in all browsers until they started adding support for
> @form.

Why does the parser change depending on if a particular attribute is
defined in the spec? Isn't that supposed to have an effect at a
completely different level not involving the parser? Or do I
misunderstand what you wrote?

Boris Zbarsky

unread,
Aug 22, 2011, 5:52:25 PM8/22/11
to
On 8/22/11 4:07 PM, Jesper Kristensen wrote:
> Den 22-08-2011 21:36, Boris Zbarsky skrev:
>> Witness the "<input </form>" case
>> which worked fine in all browsers until they started adding support for
>> @form.
>
> Why does the parser change depending on if a particular attribute is
> defined in the spec?

It doesn't. The above markup is parsed as:

<input form="">

by the HTML5 parser. What changes is what form="" on an input means!
If you don't support the attribute it means nothing; if you do it means
the input won't be submitted.

-Boris

Robin Berjon

unread,
Aug 23, 2011, 7:16:28 AM8/23/11
to L. David Baron, Boris Zbarsky, dev-pl...@lists.mozilla.org
On Aug 22, 2011, at 16:43 , L. David Baron wrote:
> On Monday 2011-08-22 10:22 -0400, Boris Zbarsky wrote:
>> 4) Avoid cutting-edge nonstandard features.
>
> I'd include vendor-prefixed features here too, or perhaps as a
> separate point, but with the exception that it's ok to use
> vendor-prefixes to support older versions of browsers as long as
> they're not needed for the current versions of any browser (and such
> that the non-prefixed form is always the one that wins in current
> versions).

It's probably worth digging a little deeper into the vendor-prefixing discussion. If you're using a vendor-prefixed feature (and let's face it, they're often hard to avoid completely) and you're entirely certain that it's purely decorative (as many of the CSS ones are) in such a way that you know things still work if it breaks, then you're probably safe not just using it but also using the unprefixed variant, e.g.:

-moz-sexy-border: really-sexy;
sexy-border: really-sexy;

If it gets dropped, or if the final property has a different syntax, the odds you've created a problem are really low. However, I see a lot of code of the following form:

if (foo.coolFeature) foo.coolFeature(a, b, c);
else if (foo.mozCoolFeature) foo.mozCoolFeature(a, b, c);

where coolFeature() is very much in flux. Such code naturally completely defeats the point of prefixing and possibly justifies kneecapping.

--
Robin Berjon - http://berjon.com/ - @robinberjon

Robert Kaiser

unread,
Aug 23, 2011, 10:45:21 AM8/23/11
to
Boris Zbarsky schrieb:

> Any other suggestions? Any objections to the above? Modifications to the
> above?

*) If you apply workarounds or different code paths for something,
always send the most standards-compliant variant to those clients you
can't detect specifically (assume new versions or unknown browsers are
at least as standards-compliant as those you have tested with, and let
them use compliant code, don't block them from using your website or app).

Robert Kaiser


--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)

Henri Sivonen

unread,
Aug 29, 2011, 4:07:11 AM8/29/11
to dev-pl...@lists.mozilla.org
On Mon, Aug 22, 2011 at 5:22 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> 1)  Avoid or minimize use of on* content attributes on elements,because
> barewords in such attributes are resolved against IDL properties on those
> elements before being resolved against function names in global scope, so
> adding new IDL properties can break scripts in such attributes.

Wow. I didn't know that on* content attributes were trouble.

> 4)  Avoid cutting-edge nonstandard features.

I think this should be written more explicitly to include: Avoid using
vendor-prefixed features.

> 5)  Avoid malformed HTML.  I'm not sure how to best describe this one,
> because the bar here is much lower than "pass the validator"; it's more like
> "don't require token-level fixup", so that tag names don't become attributes
> as in markup like "<input </form>".

Hopefully, we'll get to a point where we can formulate this as "View
source and make sure there's no red."

The patches in my queue cover <foo</bar>. However, they don't cover
<foo<bar>, because that's not a Parse Error per spec. (It's not a
Parse Error, because "foo<bar" as an element name is caught as a
higher-level error when doing full validation and the spec tries to
scope Parse Errors to errors that aren't caught by the rules
observable from the DOM layer.)

> Any other suggestions?

6) Carefully review the source of all JavaScript libraries you use to
make sure they comply with the above guidance, too. :-(

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

Henri Sivonen

unread,
Aug 29, 2011, 4:14:00 AM8/29/11
to dev-pl...@lists.mozilla.org
On Tue, Aug 23, 2011 at 2:16 PM, Robin Berjon <ro...@berjon.com> wrote:
> It's probably worth digging a little deeper into the vendor-prefixing discussion. If you're using a vendor-prefixed feature (and let's face it, they're often hard to avoid completely) and you're entirely certain that it's purely decorative (as many of the CSS ones are) in such a way that you know things still work if it breaks, then you're probably safe not just using it but also using the unprefixed variant, e.g.:
>
>  -moz-sexy-border: really-sexy;
>  sexy-border: really-sexy;
>
> If it gets dropped, or if the final property has a different syntax, the odds you've created a problem are really low.

If we believe the above, I think the logical conclusion is to stop
prefixing properties.

That is to say, I think the forward-compatibility advice should be
"Don't use any vendor-prefixed stuff in app / on sites that don't have
an active maintenance team to change things when breakage occurs." If
that's not reasonable advice, I think we should stop prefixing stuff,
because authors using prefixes and abandoning code is harmful, because
the code breaks when stuff gets unprefixed and authors making guesses
about what the unprefixed stuff will do cause pretty much the same
effect in terms of legacy as making stuff unprefixed from the start.

Axel Hecht

unread,
Aug 29, 2011, 5:06:35 AM8/29/11
to
On 29.08.11 10:07, Henri Sivonen wrote:
> On Mon, Aug 22, 2011 at 5:22 PM, Boris Zbarsky<bzba...@mit.edu> wrote:
>> 1) Avoid or minimize use of on* content attributes on elements,because
>> barewords in such attributes are resolved against IDL properties on those
>> elements before being resolved against function names in global scope, so
>> adding new IDL properties can break scripts in such attributes.
>
> Wow. I didn't know that on* content attributes were trouble.
>
>> 4) Avoid cutting-edge nonstandard features.
>
> I think this should be written more explicitly to include: Avoid using
> vendor-prefixed features.

If all vendors would eagerly prefix their nonstandard bleeding edge
stuff, see
http://blog.chromium.org/2009/12/web-sockets-now-available-in-google.html :-/

Axel

<...>

Mike Hommey

unread,
Aug 29, 2011, 5:28:07 AM8/29/11
to Axel Hecht, dev-pl...@lists.mozilla.org

Unfortunately, across browsers, prefixing is mostly only a CSS practice.

Mike

Gervase Markham

unread,
Aug 29, 2011, 5:54:13 AM8/29/11
to
On 29/08/11 09:14, Henri Sivonen wrote:
> That is to say, I think the forward-compatibility advice should be
> "Don't use any vendor-prefixed stuff in app / on sites that don't have
> an active maintenance team to change things when breakage occurs." If
> that's not reasonable advice, I think we should stop prefixing stuff,
> because authors using prefixes and abandoning code is harmful, because
> the code breaks when stuff gets unprefixed and authors making guesses
> about what the unprefixed stuff will do cause pretty much the same
> effect in terms of legacy as making stuff unprefixed from the start.

Another bit of advice: don't use the unprefixed version of anything
until the standard is finalized. (I.e. don't assume it'll have the same
syntax as the prefixed version, and add it in to be "forward-compatible".)

Gerv

Dirkjan Ochtman

unread,
Aug 29, 2011, 7:19:42 AM8/29/11
to Boris Zbarsky, dev-pl...@lists.mozilla.org
On Mon, Aug 22, 2011 at 16:22, Boris Zbarsky <bzba...@mit.edu> wrote:
> 1)  Avoid or minimize use of on* content attributes on elements,because
> barewords in such attributes are resolved against IDL properties on those
> elements before being resolved against function names in global scope, so
> adding new IDL properties can break scripts in such attributes.

The talk about IDL makes this seem Firefox-specific, is that correct?

If so, maybe it's worth explicitly pointing out the difference between
a broader web community sense of forward-compatible and a
Gecko-specific forward-compatible. I'm not exactly sure which one
you're addressing here? (It seems like both would be closely aligned,
but they might not be the same.)

Cheers,

Dirkjan

Dirkjan Ochtman

unread,
Aug 29, 2011, 7:21:11 AM8/29/11
to Gervase Markham, dev-pl...@lists.mozilla.org
On Mon, Aug 29, 2011 at 11:54, Gervase Markham <ge...@mozilla.org> wrote:
> Another bit of advice: don't use the unprefixed version of anything
> until the standard is finalized. (I.e. don't assume it'll have the same
> syntax as the prefixed version, and add it in to be "forward-compatible".)

Do you mean

-moz-border-sexy: really-sexy;
border-sexy: really-sexy;

is not okay? If not, don't write it like that. ;)

And if you, doing just-the-prefix doesn't seem very forward-compatible...

Cheers,

Dirkjan

Kyle Huey

unread,
Aug 29, 2011, 7:29:57 AM8/29/11
to Mike Hommey, Axel Hecht, dev-pl...@lists.mozilla.org
On Mon, Aug 29, 2011 at 5:28 AM, Mike Hommey <m...@glandium.org> wrote:

> On Mon, Aug 29, 2011 at 11:06:35AM +0200, Axel Hecht wrote:

> Unfortunately, across browsers, prefixing is mostly only a CSS practice.
>

We've started prefixing new DOM APIs (e.g. IndexedDB, some File API stuff,
WebSockets).

- Kyle

Mike Hommey

unread,
Aug 29, 2011, 7:32:33 AM8/29/11
to Kyle Huey, Axel Hecht, dev-pl...@lists.mozilla.org
On Mon, Aug 29, 2011 at 07:29:57AM -0400, Kyle Huey wrote:
> On Mon, Aug 29, 2011 at 5:28 AM, Mike Hommey <m...@glandium.org> wrote:
>
> > On Mon, Aug 29, 2011 at 11:06:35AM +0200, Axel Hecht wrote:
> > Unfortunately, across browsers, prefixing is mostly only a CSS practice.
> >
>
> We've started prefixing new DOM APIs (e.g. IndexedDB, some File API stuff,
> WebSockets).

Unfortunately, it's not because we do that others do (which was more or
less my point). Though given some time, that may give others ideas...

Mike

Robert Kaiser

unread,
Aug 29, 2011, 7:49:55 AM8/29/11
to
Dirkjan Ochtman schrieb:

> Do you mean
>
> -moz-border-sexy: really-sexy;
> border-sexy: really-sexy;
>
> is not okay?

Exactly. Note that e.g. -moz-border-radius worked quite differently than
the border-radius property that was standardized in the end.

Dao

unread,
Aug 29, 2011, 8:43:43 AM8/29/11
to

It's not expected to be forward-compatible. If it were, the prefix
wouldn't be needed.

Mike Shaver

unread,
Aug 29, 2011, 10:18:49 AM8/29/11
to Gervase Markham, dev-pl...@lists.mozilla.org
That's really not feasible, unless you want to kill all use of canvas and
<video> and such until HTML5 hits REC.

Gervase Markham

unread,
Aug 29, 2011, 10:22:28 AM8/29/11
to
On 29/08/11 15:18, Mike Shaver wrote:
> That's really not feasible, unless you want to kill all use of canvas and
> <video> and such until HTML5 hits REC.

A fair point; perhaps we need a different definition of "finalized" for
W3C standards.

What I'm trying to say is, if Mozilla just implemented -moz-border-sexy:
really-sexy;

Then don't write:

-moz-border-sexy: really-sexy;
border-sexy: really-sexy;

in your CSS in the name of forwards-compatibility ("for when they remove
the 'moz' version") because it's most likely to break.

So when _is_ it safe to use border-sexy: really-sexy;? Two
interoperating implementations? When browsers start shipping an
unprefixed version?

Gerv

Boris Zbarsky

unread,
Aug 29, 2011, 10:57:34 AM8/29/11
to
On 8/29/11 7:19 AM, Dirkjan Ochtman wrote:
> On Mon, Aug 22, 2011 at 16:22, Boris Zbarsky<bzba...@mit.edu> wrote:
>> 1) Avoid or minimize use of on* content attributes on elements,because
>> barewords in such attributes are resolved against IDL properties on those
>> elements before being resolved against function names in global scope, so
>> adding new IDL properties can break scripts in such attributes.
>
> The talk about IDL makes this seem Firefox-specific, is that correct?

No, this is a cross-browser issue. The IDL bit is not as relevant as
the "barewords are looked up on the element before being looked up on
the window when in an on* attribute" bit. It just happens that
everything that can be looked up on the element is defined in the
relevant specs' IDL.

-Boris

Boris Zbarsky

unread,
Aug 29, 2011, 10:58:25 AM8/29/11
to
On 8/29/11 7:21 AM, Dirkjan Ochtman wrote:
> On Mon, Aug 29, 2011 at 11:54, Gervase Markham<ge...@mozilla.org> wrote:
>> Another bit of advice: don't use the unprefixed version of anything
>> until the standard is finalized. (I.e. don't assume it'll have the same
>> syntax as the prefixed version, and add it in to be "forward-compatible".)
>
> Do you mean
>
> -moz-border-sexy: really-sexy;
> border-sexy: really-sexy;
>
> is not okay?

Yes. If you want to be forward-compatible, that's not OK.

> And if you, doing just-the-prefix doesn't seem very forward-compatible...

Yep. This is why there's a "don't use unstable bleeding-edge stuff"
item on the list!!!

-Boris

Boris Zbarsky

unread,
Aug 29, 2011, 11:00:09 AM8/29/11
to
On 8/29/11 10:18 AM, Mike Shaver wrote:
> That's really not feasible, unless you want to kill all use of canvas and
> <video> and such until HTML5 hits REC.

In the context of writing a forward-compatible intranet app, such a
restriction may in fact be ok. Depending on what your app is doing, etc.

-Boris

Henri Sivonen

unread,
Aug 29, 2011, 11:06:41 AM8/29/11
to dev-pl...@lists.mozilla.org
On Mon, Aug 29, 2011 at 5:22 PM, Gervase Markham <ge...@mozilla.org> wrote:
> So when _is_ it safe to use border-sexy: really-sexy;? Two
> interoperating implementations? When browsers start shipping an
> unprefixed version?

Probably when two of {Gecko, WebKit, Presto, Trident} ship unprefixed.

Ian Hickson

unread,
Sep 3, 2011, 2:27:36 PM9/3/11
to Gervase Markham, dev-pl...@lists.mozilla.org
On Mon, 29 Aug 2011, Gervase Markham wrote:
>
> What I'm trying to say is, if Mozilla just implemented -moz-border-sexy:
> really-sexy;
>
> Then don't write:
>
> -moz-border-sexy: really-sexy;
> border-sexy: really-sexy;
>
> in your CSS in the name of forwards-compatibility ("for when they remove
> the 'moz' version") because it's most likely to break.
>
> So when _is_ it safe to use border-sexy: really-sexy;? Two
> interoperating implementations? When browsers start shipping an
> unprefixed version?

The practical answer is "when it does something". i.e. when one browser
(that you care about) ships an unprefixed implementation. At that point
the meaning of the unprefixed version is essentially frozen anyway.

--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

Boris Zbarsky

unread,
Nov 18, 2011, 6:29:48 AM11/18/11
to
On 8/23/11 2:22 AM, Boris Zbarsky wrote:
> Backstory: I think we should create and publicize an MDN article on
> writing forward-compatible websites and webapps. That means websites and
> webapps that will have a minimal chance of behavior changes as browser
> updates happen.

I finally got the feedback from this thread together and put up
https://developer.mozilla.org/Writing_Forward_Compatible_Websites

I'm not sure whether the various advice on prefixing there matches the
way we're thinking about prefixes now. Might be worth double-checking
those parts.

Please feel free to edit away to make things clearer or whatnot!

Once we're happy with the result, we can try publicizing it.

-Boris

Henri Sivonen

unread,
Nov 18, 2011, 8:56:33 AM11/18/11
to dev-pl...@lists.mozilla.org
On Fri, Nov 18, 2011 at 1:29 PM, Boris Zbarsky <bzba...@mit.edu> wrote:
> I finally got the feedback from this thread together and put up
> https://developer.mozilla.org/Writing_Forward_Compatible_Websites

Looks good expect I'd change the warning against targeting future
browsers to warn about targeting *current* or future browsers. That
is, the only safe way to sniff or do bug correlation hacks is to
target past versions. (Where the Firefox case Nightly is "current" and
Aurora is already in the "past".)

OK to make that change?

> I'm not sure whether the various advice on prefixing there matches the way
> we're thinking about prefixes now.  Might be worth double-checking those
> parts.

I think the advice about prefixes holds even if browsers stop using
prefixes in non-experimental builds in the future. Advice about new
unprefixed properties should probably tell intranets not to use new
properties until *two* browsers support them (the doc says one now).

Boris Zbarsky

unread,
Nov 18, 2011, 5:23:12 PM11/18/11
to
On 11/19/11 2:56 AM, Henri Sivonen wrote:
> Looks good expect I'd change the warning against targeting future
> browsers to warn about targeting *current* or future browsers. That
> is, the only safe way to sniff or do bug correlation hacks is to
> target past versions. (Where the Firefox case Nightly is "current" and
> Aurora is already in the "past".)
>
> OK to make that change?

Yes.

> I think the advice about prefixes holds even if browsers stop using
> prefixes in non-experimental builds in the future. Advice about new
> unprefixed properties should probably tell intranets not to use new
> properties until *two* browsers support them (the doc says one now).

This was a point of disagreement between you and Hixie in the initial
thread.... I just picked a side. ;)

-Boris


Gervase Markham

unread,
Nov 21, 2011, 6:45:40 AM11/21/11
to Boris Zbarsky
On 18/11/11 11:29, Boris Zbarsky wrote:
> I finally got the feedback from this thread together and put up
> https://developer.mozilla.org/Writing_Forward_Compatible_Websites

Suggestion: have a summary for busy people, which gives the instructions
with two sentences of rationale, and then either an expandable or a
linked "full explanation". At the moment, the document begins by
explaining name lookup algorithms, rather than with a clear statement of
precisely what you want the coder to _do_.

(I would also change that one to: 'in "on*" attributes, when you access
a global variable, prefix it with “window.”')

Gerv

Henri Sivonen

unread,
Nov 21, 2011, 7:15:52 AM11/21/11
to dev-pl...@lists.mozilla.org
On Sat, Nov 19, 2011 at 12:23 AM, Boris Zbarsky <bzba...@mit.edu> wrote:
> On 11/19/11 2:56 AM, Henri Sivonen wrote:
>> Looks good expect I'd change the warning against targeting future
>> browsers to warn about targeting *current* or future browsers. That
>> is, the only safe way to sniff or do bug correlation hacks is to
>> target past versions. (Where the Firefox case Nightly is "current" and
>> Aurora is already in the "past".)
>>
>> OK to make that change?
>
> Yes.

I made this change, added a guideline about testing with all the top
engines and edited the title of the first guideline not to require a
reader who skims the headings to know what an event handler content
attribute is.

Boris Zbarsky

unread,
Nov 21, 2011, 8:03:21 AM11/21/11
to
On 11/21/11 6:45 AM, Gervase Markham wrote:
> On 18/11/11 11:29, Boris Zbarsky wrote:
>> I finally got the feedback from this thread together and put up
>> https://developer.mozilla.org/Writing_Forward_Compatible_Websites
>
> Suggestion: have a summary for busy people

The section headings are supposed to do that...

> which gives the instructions with two sentences of rationale

Would this be useful? In the onfoo attribute case, it would basically
just have to say "if you don't do this, things can break as new
properties are added to elements", right?

> (I would also change that one to: 'in "on*" attributes, when you access
> a global variable, prefix it with “window.”')

Henri did this already... I'm torn about this, because the guidance
does NOT apply to things like this:

document.body.onclick = function() {
something();
}

but DOES apply to:

<body onclick="something()">

The former doesn't need the "window." bit, but the latter does. Sadly,
people use "attributes" to refer to both things because of the way
properties are expressed in IDL, so disambiguating the two is a bit of a
pain.

-Boris

Gervase Markham

unread,
Nov 22, 2011, 6:03:19 AM11/22/11
to Boris Zbarsky
On 21/11/11 13:03, Boris Zbarsky wrote:
> The section headings are supposed to do that...

The trouble is, for a "busy people" summary, the section headings are
too short, and the full thing is too long.

Here's an example of how it might go, to give you an idea:


Want to make your websites compatible with browsers that aren't yet
released? Here are 10 things to do:

1) Stick a "window." prefix on all global variable/function accesses in
onfoo attributes in your markup

Example:

<div onclick="localFunction()">Click me</div>

->

<div onclick="window.localFunction()">Click me</div>

Reason: because then your functions won't get stomped on if new DOM
properties get added in future browsers.

2) Don't concatenate scripts you don't control

Developers sometimes automatically concatenate scripts to reduce the
number of HTTP requests a page needs. But don't do it unless you wrote them.

Reason: If someone sticks a "use strict;" in one of them, it'll apply to
more code than it's meant to, and your code will break.

3) Don't sniff for one thing then use another

Example:

...

->

...

Gerv

Boris Zbarsky

unread,
Nov 22, 2011, 7:35:53 AM11/22/11
to
On 11/22/11 6:03 AM, Gervase Markham wrote:
> Here's an example of how it might go, to give you an idea:

Feel free to make edits, btw!

I'll try to find time to do that too, but don't feel forced to wait for me.

One thing to keep in mind, though: better to not have "this is the wrong
way" examples: people tend to copy/paste those almost as much as the
"this is the right way" ones. :(

-Boris

helpcrypto helpcrypto

unread,
Nov 23, 2011, 2:54:16 AM11/23/11
to dev-pl...@lists.mozilla.org
Are this kind of good-practices anywhere in mozilla wiki?

Boris Zbarsky

unread,
Nov 23, 2011, 8:23:25 AM11/23/11
to
On 11/23/11 2:54 AM, helpcrypto helpcrypto wrote:
> Are this kind of good-practices anywhere in mozilla wiki?

You mean like at
https://developer.mozilla.org/Writing_Forward_Compatible_Websites ?

-Boris

helpcrypto helpcrypto

unread,
Nov 23, 2011, 8:37:29 AM11/23/11
to dev-pl...@lists.mozilla.org
Thx a lot. I missed that.

Anywhere else?

2011/11/23 Boris Zbarsky <bzba...@mit.edu>:

Gervase Markham

unread,
Nov 23, 2011, 10:10:14 AM11/23/11
to
On 22/11/11 12:35, Boris Zbarsky wrote:
> One thing to keep in mind, though: better to not have "this is the wrong
> way" examples: people tend to copy/paste those almost as much as the
> "this is the right way" ones. :(

If we make the code not work, that tendency might be avoided somewhat...

Gerv


Gervase Markham

unread,
Nov 23, 2011, 10:41:00 AM11/23/11
to
On 22/11/11 12:35, Boris Zbarsky wrote:
> On 11/22/11 6:03 AM, Gervase Markham wrote:
>> Here's an example of how it might go, to give you an idea:
>
> Feel free to make edits, btw!

I just did some copyediting:
https://developer.mozilla.org/en/Web_development/Writing_forward-compatible_websites

Can someone check I didn't accidentally change the meaning of number 8?
I wasn't quite sure what it meant...

Gerv

Boris Zbarsky

unread,
Nov 23, 2011, 11:12:27 AM11/23/11
to
On 11/23/11 10:41 AM, Gervase Markham wrote:
> I just did some copyediting:
> https://developer.mozilla.org/en/Web_development/Writing_forward-compatible_websites

I really think that showing examples of the wrong thing, especially
without a good indication that it's wrong (the red/green thing you used
is not obvious unless you know one is wrong!) is not a good idea...

I think this is _very_ important. The edits also introduced various
inaccuracies, removed some sections wholesale, broke all existing links
into this document, and made it more likely that such links would break
repeatedly in the future.

I just spent 20 minutes trying to disentangle things, but I'm giving up
and reverting this edit for now. Let's try to do copy-editing and
substantive changes separately, ok?

-Boris

Boris Zbarsky

unread,
Nov 23, 2011, 1:07:32 PM11/23/11
to
Some clarifications:

On 11/23/11 11:12 AM, Boris Zbarsky wrote:
> I think this is _very_ important. The edits also introduced various
> inaccuracies

A specific example: the "if possible" verbiage on object detection was
very purposeful: there are cases in which it is not in fact possible,
and trying to insist on it in those cases just makes us sound dumb.

> broke all existing links into this document

Because devmo uses the section titles for links.

> and made it more likely that such links would break
> repeatedly in the future.

Because inserting a section anywhere except the very end would force
renumbering the sections.

There were also a bunch of good editorial changes here that we should
definitely keep...

-Boris

Gervase Markham

unread,
Nov 24, 2011, 4:28:04 AM11/24/11
to Boris Zbarsky
On 23/11/11 16:12, Boris Zbarsky wrote:
> I really think that showing examples of the wrong thing, especially
> without a good indication that it's wrong (the red/green thing you used
> is not obvious unless you know one is wrong!) is not a good idea...

We can certainly label them more clearly. But a good example
highlighting the difference is worth 100 words of explanatory verbiage.

Would you be happy if the red ones began "Wrong:" and the green ones
"Right:"?

> I think this is _very_ important. The edits also introduced various
> inaccuracies, removed some sections wholesale, broke all existing links
> into this document, and made it more likely that such links would break
> repeatedly in the future.

I removed a section because it wasn't relevant to the topic. The
document is about writing forward-compatible websites, not general
webdev best practice.

"Make sure to test what happens in a browser that doesn't implement the
feature you're using, especially if you don't use such a browser
day-to-day while working on the site." is advice for writing
backwardly-compatible websites, not forwardly-compatible ones.

As for breaking links, if MDN uses section titles for incoming links,
MDN is broken, because it means you can't update a section title to be
more clear or to fix an error.

Gerv

Gervase Markham

unread,
Nov 24, 2011, 4:29:32 AM11/24/11
to
On 23/11/11 18:07, Boris Zbarsky wrote:
> A specific example: the "if possible" verbiage on object detection was
> very purposeful: there are cases in which it is not in fact possible,
> and trying to insist on it in those cases just makes us sound dumb.

OK; but putting it in up front makes the thing sound weak. Better would
be to end with:

"In some cases, such as X, this is not actually possible. In that case,
do Y."

>> and made it more likely that such links would break
>> repeatedly in the future.
>
> Because inserting a section anywhere except the very end would force
> renumbering the sections.

Numbering the sections makes the document feel smaller and more
readable. Perhaps we can use CSS generated content to add the numbers to
the display without putting them in the markup?

Gerv

Neil

unread,
Nov 24, 2011, 8:55:39 AM11/24/11
to
Gervase Markham wrote:

> As for breaking links, if MDN uses section titles for incoming links,
> MDN is broken, because it means you can't update a section title to be
> more clear or to fix an error.

Other wikis do this too... I don't know how they deal though, if at all.

--
Warning: May contain traces of nuts.

Boris Zbarsky

unread,
Nov 24, 2011, 12:11:57 PM11/24/11
to
On 11/24/11 4:29 AM, Gervase Markham wrote:
> OK; but putting it in up front makes the thing sound weak. Better would
> be to end with:
>
> "In some cases, such as X, this is not actually possible. In that case,
> do Y."

That would be fine, yes.

> Numbering the sections makes the document feel smaller and more
> readable. Perhaps we can use CSS generated content to add the numbers to
> the display without putting them in the markup?

That seems worth trying, yes.

-Boris

Boris Zbarsky

unread,
Nov 24, 2011, 12:17:06 PM11/24/11
to
On 11/24/11 4:28 AM, Gervase Markham wrote:
> We can certainly label them more clearly. But a good example
> highlighting the difference is worth 100 words of explanatory verbiage.
>
> Would you be happy if the red ones began "Wrong:" and the green ones
> "Right:"?

There is pretty good data (though no citation offhand; if you really
care, I'll look) that people who see that sort of thing remember the
"wrong" pattern just as well as the "right" pattern. And they don't
remember the labels. They just remember the two patterns. Then when
they actually write code they pick one at random.

Keep in mind that people aren't looking at this document when writing
pages. They read the document sometime, then write pages later based on
what they remember from the document, not based on what the document
actually says.

> I removed a section because it wasn't relevant to the topic. The
> document is about writing forward-compatible websites, not general
> webdev best practice.

That particular section _is_ relevant to this topic, because
cutting-edge features can go away from browsers (whether because the
spec is rescinded, the spec changes, or the prefix is dropped) and then
a browser that didn't use to take a fallback path will take one. So
it's seriously all about forward compat....

> "Make sure to test what happens in a browser that doesn't implement the
> feature you're using, especially if you don't use such a browser
> day-to-day while working on the site." is advice for writing
> backwardly-compatible websites, not forwardly-compatible ones.

For longstanding features, yes. For unstable ones, no.

> As for breaking links, if MDN uses section titles for incoming links,
> MDN is broken, because it means you can't update a section title to be
> more clear or to fix an error.

I agree MDN is broken, sure. We should fix that too.

-Boris

Mark Tyndall

unread,
Nov 25, 2011, 5:16:26 AM11/25/11
to
On 24/11/2011 09:28, Gervase Markham wrote:
> On 23/11/11 16:12, Boris Zbarsky wrote:
>> I really think that showing examples of the wrong thing, especially
>> without a good indication that it's wrong (the red/green thing you used
>> is not obvious unless you know one is wrong!) is not a good idea...
>
> We can certainly label them more clearly. But a good example
> highlighting the difference is worth 100 words of explanatory verbiage.
>
> Would you be happy if the red ones began "Wrong:" and the green ones
> "Right:"?
[...]

Remember that many people either find it hard to, or simply cannot,
discriminate between red and green (Imagine that, at a glance, you
couldn't tell whether a holly tree was bearing berries).

See WCAG2.0, Guideline 1.4.1

Mark..

Paul Rouget

unread,
Nov 28, 2011, 1:29:30 AM11/28/11
to Boris Zbarsky, dev-pl...@lists.mozilla.org
We would like to promote this document more widely.
Do you guys think it's ready or should we wait?

-- Paul

Boris Zbarsky

unread,
Nov 29, 2011, 10:22:10 PM11/29/11
to
On 11/28/11 1:29 AM, Paul Rouget wrote:
> We would like to promote this document more widely.
> Do you guys think it's ready or should we wait?

I feel like it's ready (though we should keep improving it as needed);
the main issue is any pending changes to the section titles... If we're
planning any wholesale changes there we need to do it before promoting.

-Boris

Reply all
Reply to author
Forward
0 new messages