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?
> 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.
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.)
> 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?
> 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
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)
> 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.
On Mon, Aug 22, 2011 at 11:46 AM, Joshua Cranmer <Pidgeo...@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.
> 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.
> 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...
> 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.
> 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?
> 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.
> 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.:
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.
> 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! :)
On Mon, Aug 22, 2011 at 5:22 PM, Boris Zbarsky <bzbar...@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. :-(
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.:
> 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.
> On Mon, Aug 22, 2011 at 5:22 PM, Boris Zbarsky<bzbar...@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.
On Mon, Aug 29, 2011 at 11:06:35AM +0200, Axel Hecht wrote: > On 29.08.11 10:07, Henri Sivonen wrote: > >On Mon, Aug 22, 2011 at 5:22 PM, Boris Zbarsky<bzbar...@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.
> 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".)
On Mon, Aug 22, 2011 at 16:22, Boris Zbarsky <bzbar...@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.)
On Mon, Aug 29, 2011 at 11:54, Gervase Markham <g...@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".)
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: > > On 29.08.11 10:07, Henri Sivonen wrote: > > >On Mon, Aug 22, 2011 at 5:22 PM, Boris Zbarsky<bzbar...@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.
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: > > > On 29.08.11 10:07, Henri Sivonen wrote: > > > >On Mon, Aug 22, 2011 at 5:22 PM, Boris Zbarsky<bzbar...@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.
Exactly. Note that e.g. -moz-border-radius worked quite differently than the border-radius property that was standardized in the end.
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! :)
> On Mon, Aug 29, 2011 at 11:54, Gervase Markham<g...@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".)
