|
Convenient web based access to our favorite web design Usenet groups
|
 |
This is Interesting: Free Magazines for Graphics designers and webmasters
| Author |
| Thread |
 |
|
|
|
|
|
 |
 |
 |
CSS and IE's CC evaluation (Was: Re: A stylesheet for IE, another one for web browsers |
 |
|
 |
|
|
|
  01-12-05 - 04:16 AM
|
On 09 Jan 2005 12:24:39 +0000, "Jón Fairbairn"
<jon.fairbairn@cl.cam.ac.uk> wrote:
>Daniel Déchelotte <maitre_yodan@fr.club-internet.invalid> writes:
[...]
[...]
>I have no idea whether this would work (don't have IE
>handy), but what does IE make of something like this:
>
><!--[IF IE]>
><![IF !IE]>
><![endif]-->
>baz
><!--[IF IE]>
><![endif]>
><![endif]-->
>
>-- for everything else it's just baz surrounded by a pair of
> comments?
As reported, at least by Daniel, this CC attempt is "working" but it
also made me think a bit about what is really happening inside IE in
that case. Let's structure the "code" a bit at first.
1. <!--[IF IE]>
2. <![IF !IE]>
3. <![endif]-->
4. baz
5. <!--[IF IE]>
6. <![endif]>
7. <![endif]-->
I have always assumed that IE's CC evaluation is based on some form of
standard principle, similar to how conditional execution would take
place in any other "programming language". In which case I can not see
how that CC "code snip" could hide 'baz' from IE in the first place.
Let's send this to IE under that assumption of mine.
Line 1 will be evaluated to a BOOLEAN TRUE status.
Line 2 will start a new evaluation, which will at first
'push' the TRUE running value from Line 1 on the stack
to make room for a new running value, which will be FALSE
this time.
Line 3 "should" be the 'endif' statement for Line 2 which,
when evaluated, "should" 'pop' the stack to bring back the
original TRUE value from Line 1 as the running value.
/In which case/ Line 4. with its 'baz' lies fully open for
interpretation by IE.
After that, Line 5. and Line 6. becomes "dummies" for IE
and finally Line 7 will close the evaluation started in
Line 1.
I do fully agree with the statement that this "code snip" will present
'baz' fully undisturbed to real browsers, that part is not a problem.
But in order for it to work as expected in IE we need to assume that the
FALSE running value, that comes out of the evaluation in Line 2, will
also prohibit IE from evaluating Line 3?
In which case it will also not evaluate the 'baz' in Line 4 of course.
But then, why should it evaluate Line 5? Line 6? or even Line 7?
It would be really good, from a practical standpoint, to find a reliable
way to exclude some CSS from IE all together, but I can not make the ins
and outs of the presented "code", as seen in the light of a report that
it really does "work" as expected?
What gives?
--
Rex
|
|
|
| [
Post Follow-Up to this message ]
|
|
|
|
|
 |
 |
Re: CSS and IE's CC evaluation (Was: Re: A stylesheet for IE, another one for web brow |
 |
|
 |
|
|
|
  01-29-05 - 04:17 AM
|
Apologies for delayed followup.
Jan Roland Eriksson <jrexon@newsguy.com> writes:
> On 09 Jan 2005 12:24:39 +0000, "Jón Fairbairn"
> <jon.fairbairn@cl.cam.ac.uk> wrote:
>
>
> [...]
>
>
> [...]
>
>
> As reported, at least by Daniel, this CC attempt is "working" but it
> also made me think a bit about what is really happening inside IE in
> that case. Let's structure the "code" a bit at first.
>
> 1. <!--[IF IE]>
> 2. <![IF !IE]>
> 3. <![endif]-->
> 4. baz
> 5. <!--[IF IE]>
> 6. <![endif]>
> 7. <![endif]-->
>
> I have always assumed that IE's CC evaluation is based on some form of
> standard principle, similar to how conditional execution would take
> place in any other "programming language". In which case I can not see
> how that CC "code snip" could hide 'baz' from IE in the first place.
When I wrote it, I didn't have chance to check it on IE. Not
knowing how IE really works, I chose something that would
work under two of the numerous possibilities, namely a
macro-preprocessor and cautious bracket matching. (I don't
even know whether IE interprets nesting of conditional
comments; after all, if IE inside if not IE is a little bit
strange).
Given the more likely cautios bracket matching, the code
would be interpreted like this:
> 1. <!--[IF IE]> -- (1)
> 2. <![IF !IE]> -- (2)
> 3. <![endif]--> -- non-matching endif (because of the "--"
> 4. baz
> 5. <!--[IF IE]> -- nested conditional
> 6. <![endif]> -- matches (2), so error recovery closes the
nested conditional, and then (2)
> 7. <![endif]--> -- closes (1)
>
> It would be really good, from a practical standpoint, to
> find a reliable way to exclude some CSS from IE all
> together, but I can not make the ins and outs of the
> presented "code", as seen in the light of a report that it
> really does "work" as expected?
>
> What gives?
I think the above is a plausible explanation. However, even
Daniel Déchelotte's neater version of the code cannot be
relied upon. The *only* thing we can assume will work in
future versions of IE is the invalid (from an html point of
view) syntax given in Microsoft's description of conditional
comments.
After all, it would have been perfectly possible for them to
have chosen a syntax something like this:
<!--[IF IE]>
stuff to be processed by IE, cannot contain comment sequences.
<![else]-->
stuff to be processed by non-IE
<!--[endif]-->
or handle the not IE case thus:
<!--[IF !IE]-->
stuff to be processed by non-IE
<!--[endif]-->
I disdain to comment on whether their choice reflects
<del>malice</del><ins>sound commercial practice</ins> or
language design incompetence.
--
Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
|
|
|
| [
Post Follow-Up to this message ]
|
|
|
|
|
 |
|
|
 |
| All times are GMT. The time now is 10:11 AM. |
 |
|
|
|
|
|  |
|