1 |
Esben Mose Hansen wrote: |
2 |
> |
3 |
> If you can live without IE support, use an alternative stylesheet. That way, |
4 |
> the add can be removed by selecting a stylesheet from a browser menu, no |
5 |
> javascript required. |
6 |
> |
7 |
> Of course, the IE people are screwed, but I can't imagine that IE is a common |
8 |
> browser there, nor is the functionality loss unacceptable. |
9 |
> |
10 |
|
11 |
Already thought of that but we want all browsers to display and behave |
12 |
the same. The only way I've found that works the same in all of them is |
13 |
using a javascript. |
14 |
|
15 |
|
16 |
Blackace wrote: |
17 |
> |
18 |
> You could use an XSL param to remove the ad div in the XSL stylesheet, |
19 |
> and make the link/button a link to "?ads=off" or similar. |
20 |
> |
21 |
> This would not require javascript but would have a like effect...the |
22 |
> best of both worlds. |
23 |
> |
24 |
|
25 |
I thought of that too. The problem is that I would have to add a new |
26 |
function to the href's parser and I'm not sure I want to add anymore |
27 |
complexity than we have too. Not to mention the href parser won't work |
28 |
on hard coded links in the menus and jumppads, only on dynamically |
29 |
created ones from xml files. This means if you turn off the ads then |
30 |
click a link in the menu the ads come back but if you click a link |
31 |
within the content area the ads will stay off. This is inconsistant |
32 |
behaviour and not really something I would want to do. Changing the href |
33 |
parser to work on the menu links wouldn't be an easy task. I would have |
34 |
to think about how to do that and experiment a little. |
35 |
|
36 |
|
37 |
Either way, getting rid of the ads column isn't a big priority, maybe we |
38 |
can look into it at a later date. I really want to focus on getting the |
39 |
existing site up and running. Then we can worry about enhancements at a |
40 |
later date. |
41 |
|
42 |
-- |
43 |
www-redesign@g.o mailing list |