AOL redesign using CSS

[Matt Rushton]

Has anyone seen the new AOL frontpage?

Great its a css tableless design.

Crap, its nearly impossible to read some of the text if you increase
the text size.

It may accessible to screen readers but not to large screen mozilla
users who surf with an increased font size.

oh well, lets hope a new revision will be forthcoming.

Matt

[Allen Day]

Re: AOL redesign using CSS

[color=blue]
> Has anyone seen the new AOL frontpage?
> Great its a css tableless design.[/color]

Wow, that is certainly a step in the right direction! It actually looks
pretty good. Initially.
[color=blue]
> Crap, its nearly impossible to read some of the text if you increase
> the text size.[/color]

Very true--"Our typography or bust" -- would be easily enough fixed with
relative block sizes.
[color=blue]
> It may accessible to screen readers but not to large screen mozilla
> users who surf with an increased font size.[/color]

Perhaps you should turn on your screen reader :-)


--
Allen crepe.null@jard ay.com Remove .null to reply
http://theprawn.com http://protempore.org/jarday
Arguments are to be avoided; they are always vulgar and often convincing.
-Oscar Wilde

[lostinspace]

Re: AOL redesign using CSS

----- Original Message -----
From: "Matt Rushton" <>
Newsgroups: comp.infosystem s.www.authoring.stylesheets
Sent: Monday, February 09, 2004 7:41 AM
Subject: AOL redesign using CSS

[color=blue]
> Has anyone seen the new AOL frontpage?
>
> Great its a css tableless design.
>
> Crap, its nearly impossible to read some of the text if you increase
> the text size.
>
> It may accessible to screen readers but not to large screen mozilla
> users who surf with an increased font size.
>
> oh well, lets hope a new revision will be forthcoming.
>
> Matt[/color]

I'm not an AOL fan :-(
Upon viewing the source, I found this tag quit interesting!

<meta http-equiv="Pragma" content="no-cache">

AOL caches or attempts to cache everything not abiding by webmasters meta
tags and yet includes the same :-)

[Chet]

Re: AOL redesign using CSS


"lostinspac e" <lostinspace@12 3-universe.com> wrote in message
news:0jTVb.1179 $t16.1094383@ne wssvr28.news.pr odigy.com...
| I'm not an AOL fan :-(
| Upon viewing the source, I found this tag quit interesting!
|
| <meta http-equiv="Pragma" content="no-cache">
|
| AOL caches or attempts to cache everything not abiding by
webmasters meta
| tags and yet includes the same :-)
|

It sounds like, "Do as I say, not as I do!" LOL

--
Chet
ng2.chet@NOchar terSPAM.net (remove NO.....SPAM)

[Chris Morris]

Re: AOL redesign using CSS

"lostinspac e" <lostinspace@12 3-universe.com> wrote:[color=blue]
> Upon viewing the source, I found this tag quit interesting!
>
> <meta http-equiv="Pragma" content="no-cache">
>
> AOL caches or attempts to cache everything not abiding by
> webmasters meta tags and yet includes the same :-)[/color]

While the original idea of <meta> was that it would be parsed
server-side, this would involve invoking an SGML parser every time
someone requested a page, a somewhat unnecessary overhead given that
ordinarily cache machines can be incredibly lightweight (provided they
have fast IO).

If AOL ignores HTTP headers _as well_ then that's more of a problem.

--
Chris

[lostinspace]

Re: AOL redesign using CSS

"If AOL ignores HTTP headers _as well_ then that's more of a problem."

EACH and EVERY AOL visitor to my sites upon their first entry invokes the
User-Agent
"Mozilla/3.01 (compatible;)" exactly as typed.

This UA (exactly as specified) is denied for every image and every page in
my sites. AOL or the AOL browser then immediately (within milliseconds)
responds with the users real UA and the pages and images are then delivered.

The reason the UA is used (by AOL) is only to cache data, both images and
pages. AOL or none of the other IP's or backbones could care less about the
actions of their own companies or subscribers, at least as related to
webmasters. Regardless of documented violations of either that IP or
Backbones User Agreements, and the websites TOS. In most instances the
direct result of a webmaster following their detailed requests for
notification are remedied with automated replies. RARELY is a solution
rendered.

This only leaves webmasters to fend for themselves and deny innocent
parties because of the actions of either the provider themselves or a
solitary user.