W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2002

Re: CSS optimised for different browsers

From: Tina Marie Holmboe <tina@elfi.org>
Date: Mon, 18 Nov 2002 15:38:31 +0100
To: "Scarlett Julian (ED)" <Julian.Scarlett@sheffield.gov.uk>
Cc: John Ablett <john@jablett.freeserve.co.uk>, w3c-wai-ig@w3.org
Message-ID: <20021118153831.A4957@elfi.org>

On Mon, Nov 18, 2002 at 12:02:24PM -0000, Scarlett Julian (ED) wrote:

> >    Personally I dislike the [css] hacks mentioned. Then again, perhaps
> they
> >   fit your requirements.
> Is you dislike based on aesthetic or practical grounds?


   From a personal, aestethic, point of view I find them unelegant. It
  should really be unnecessary to, as one of them suggests, include a
  text-string as part of a value for the voice-family property which IE
  reacts to and stops parsing. It smacks of GOTO.

   From a more practical point of view, I see the hacks both as a problem
  in maintenance and in future-proofing. Maintenance of code, even CSS,
  has high priority. If a number of "hacks" that may, or may not, work in
  various browsers of versions versions are included in the CSS, I have
  no difficulty seeing complex maintenance coming my way.

   Finally, consider the following hack taken from Tankek's pages:

   div#menubar {
    position     : absolute ;
    voice-family : "\"}\"" ;
    voice-family : inherit ;
    position     : fixed ;

  which by no means can be considered elegant. It does, however, take
  advantage of a parsing bug in Internet Explorer. Contemplate, now, what
  will happen for a new version of IE/Windows which HAS support for 
  fixed positioning - something the ones of today has not - but still
  contains that little quirk regarding the string "\"}\"" ?

   A minor problem with this particular example, yes. I am sure we could
  come up with examples where the end results became less accessible due
  to this.

   You might also want to notice that in the document which describes this
  technique[1] it is also suggested to add another rule block to help
  browsers which support the property we are trying to hide, but who doesn't
  hand the string - among them, it is claimed, Opera.

   The added rule block, of course, demands support for even more things
  to help unshield the properties that was attempted shielded with a
  parsing bug unrelated to the property shielded ... ;)

   In short, I dislike methods that take advantage of incorrect parsing
  or similar in browsers. One really never know what'll happen in terms
  of the future. That is also why I dislike browsers who, despite
  having different capabilities, claim to be something else.


 - Tina Holmboe <tina@greytower.net>
Received on Monday, 18 November 2002 09:38:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:21 UTC