- From: Simon Pieters <simonp@opera.com>
- Date: Sat, 14 Sep 2013 20:12:53 +0200
- To: public-html@w3.org, "Jukka K. Korpela" <jukka.k.korpela@kolumbus.fi>, "Charles McCathie Nevile" <chaals@yandex-team.ru>
On Fri, 13 Sep 2013 15:11:21 +0200, Charles McCathie Nevile <chaals@yandex-team.ru> wrote: > On Fri, 13 Sep 2013 15:29:12 +0400, Simon Pieters <simonp@opera.com> > wrote: > >> On Fri, 13 Sep 2013 10:57:05 +0200, Jukka K. Korpela > >>> It sounds illogical that a browser is not allowed to support <bgsound> >>> but is allowed to support <backgroundsound>. >> >> So a bit more context: > [...] >> So new elements should not be created, you're right that that means >> that there can exist situations in which it is conforming for a UA to >> do so anyway. The other requirement is that such extensions should be >> named as "x-vendor-feature", but again there can exist situations in >> which it is conforming for a UA to use a different naming. >> >> This suggests that both "bgsound" and "backgroundsound" *could* be >> vendor-specific extensions, and can be conforming if the UA vendor has >> valid reasons and has carefully considered the implications before >> implementing it. However, if a particular browser has just kept an old >> element around since the dawn of time (or at least since before this >> requirement existed in the spec), it's hard to argue that they comply >> with these "should" and "should not". > > What's wrong with "there is content using this, so we support it for > backward compatibility" as an argument? That can be a valid argument, but, if it is required for compat, its behavior should be in the spec. In the case of <bgsound>, Gecko and WebKit never found it being big enough compat loss not to support it, and Presto even intentionally dropped support. -- Simon Pieters Opera Software
Received on Saturday, 14 September 2013 18:13:25 UTC