- From: François REMY <fremycompany_pub@yahoo.fr>
- Date: Mon, 11 Aug 2008 11:12:49 +0200
- To: "CSS 3 W3C Group" <www-style@w3.org>
- Message-ID: <A898D4D059F046B69A4D96E029A69805@fremycompany>
Simplicity and security of @media
Can we suppose that a hypothetical 'OpenWeb' browser using 'freegate' as render engine.
Freegate already support CSS3 but fails when we try to apply 'opacity' on a parent of an IFRAME element (opacity is not applied to the IFRAME) but it works if we specify opacity on the frame itself.
<style .><!-- div.translucent { opacity: 0.5; } --></style>
<div class="translucent">
<iframe src="about:blank" . />
</div>
If we want that "OpenWeb" correctly support the opacity, we need an extra rule:
div.translucent iframe { opacity: 0.5; }
But it breaks all others browsers (opacity get applied two times to the iframe).
So, we find a hack for OpenWeb:
@import {;
div.translucent iframe { opacity: 0.5; }
@import };
When a new vesion of OpenWeb came out:
- The bug can be fixed but the hack can be not fixed
o We need to find another hack that works in previous version of OpenWeb but fails on new one. A very complex job.
- The bug can be not fixed but the hack can be fixed
o We need to find another hack that works on new version of OpenWeb (and old one, if we want to have only one hack). Another very complex job.
- If both hack and bug are fixed, we don't need to change anything.
If we use a standardized @media filter with only (ua-version and max-ua-version):
@media (max-ua-version: freegate 1.*) {
div.translucent iframe { opacity: 0.5; }
}
When a new version came out:
- The bug is fixed
o We don't need to modify the code
- The bug is not fixed
o We can change 1.* into 2.*
Browser voluntary incompatibility
If someone wants to make a site non-compatible with a browser, he doesn't need @media at all. A simple script can do the job at this time and having the same effect:
<script ... ><!-
if (navigator.userAgent.indexOf('xxxx')) == -1) {
// All browsers except xxx will load this code
document.write('<link href="style.css" . />');
} else {
document.onmousemove=alert;
}
--></script>
So it will not be @media that will add this problem to the web.
--------------------------------------------------
From: "David Woolley" <forums@david-woolley.me.uk>
Sent: Monday, August 11, 2008 9:29 AM
To: "CSS 3 W3C Group" <www-style@w3.org>
Subject: Re: @media and browsers conditional statments
>
> Brad Kemper wrote:
>> Nor would I, but spoofing is just so unlikely. This is not JavaScript in
>> the 90s. Things have progressed since then. Those authors who have not
>> progressed are blissfully unaware of more modern css features anyway. I
>
> This is largely a human factors problem and, whilst one may get fashion
> cycles, one shouldn't expect basic human nature to change over these
> time scales.
>
> Changes will take place as a result of shifts in the age profile and
> because more people are going through academic training, but there are
> still a lot of new inexperienced people, and a lot whose training is
> limited to glossy cook books and looking at other people's solutions.
>
> --
> David Woolley
> Emails are not formal business letters, whatever businesses may want.
> RFC1855 says there should be an address here, but, in a world of spam,
> that is no longer good advice, as archive address hiding may not work.
>
Received on Monday, 11 August 2008 09:13:32 UTC