- 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