On Wed, Jan 6, 2016 at 12:50 PM, Robert O'Callahan <rob...@ocallahan.org> wrote: > On Wed, Jan 6, 2016 at 9:52 PM, Anne van Kesteren <ann...@annevk.nl> wrote: >> >> On Tue, Jan 5, 2016 at 10:18 PM, Robert O'Callahan <rob...@ocallahan.org> >> wrote: >> > That's an option, but it's a very large problem that's very difficult to >> > get right. And there are so many things that need to be plugged, it >> > would >> > make the feature very fragile: change the Web content in some subtle way >> > and suddenly it looks wrong or disappears altogether for no apparent >> > reason. >> >> We could also go the other way. And have some kind of opt-in flag that >> requires everything to be CORS-same-origin and doesn't allow :visited >> and plugins or some such. And if you have that enabled you get to use >> some new features. Might be easier than tracking on a per layout box >> basis whether it violates some constraints. > > Where would you put that flag?
You could put it in CSS on in the DOM. Something like only-render-safe-content: true || false; (inherits. Defaults to false) or <span onlyrendersafecontent> Maybe I'm missing what the problem with where to put it is? > I think this has basically the same problems: very difficult to specify and > police, and fragile when the content changes. Definitely specifying and implementing is challenging. We'd have to define all places where non-same-origin content is pulled in. Like cross-origin images/media, OS colors, OS form controls, OS scrollbars, :visited-coloring, etc. This doesn't seem that insurmountable though (in the scheme of how complex CSS is in general). I'd be more worried about implementation burden. Especially given all the other things that we're working on and that is important. / Jonas _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
