[thelist] Site redirect check : old browser

aardvark roselli at earthlink.net
Wed Jun 6 07:38:42 CDT 2001


> From: "Mark Cheng" <mark.cheng at ranger.com.au>
>
> Hey aardvark - should we move this to thesite?  It seems to be
> straying off topic?

well, it's strayed from the original request for testing, but it's still on-
topic... also, thesite is reserved for development on the evolt.org 
site, so this wouldn't belong there...

> True, however, I'm interpreting my comments purely from an HTML point
> of reference.  Therefore I have achieved the separation of style from
> content, because I can change styles without changing the HTML.

granted, but you can't change your HTML without editing your 
individual content pages... that's what i'm trying to clear up here, 
that you have separated your style from your markup, but you 
havne't separated your content from you markup... seems like a 
small point, but it's key in understanding where you are now...

> ????  I'm not suggesting that separating style from content allows you
> to jump to different languages/protocols/markup.  Nor do i include the
> markup language as part of style.  imo style is colouring and design
> for a particular protocol/markup.  I've achieved that.

but that's not quite right... your classed <div> tags *are* style... 
your markup is considered to be style (at least by n-tier models, 
although ALA and WaSP have confused that point), because it 
exists for display purposes only... your inline markup (<strong>, 
<a>) is part of the content, giving it structure and semantic 
meaning... that you don't have to worry about...

it may not sound right, given what other sites have said, but style 
is not just CSS, it's any markup that exists solely for presentation 
(like you <div>s) as well as other things like navigation and 
branding elements... again, your content and style are not truly 
separate, but your markup and CSS are...

> Interesting point.  I view the div/span as object markers to which I
> can apply a style if I choose, they do not of themselves contain any
> style information.  I think they are different to <strong> which has a
> different style attached to it.

<strong> has semantic meaning... it tells aural browsers to speak 
louder or change pitch, it tells WML browsers to perhaps bold, but 
do something else if they can't bold... <b>, on the other hand, *is* 
style, since it simply tells a visual browser to bold text, but imparts 
no semantic meaning... you can apply CSS to both, but failing 
that, <strong> means something, <b> styles something...

and because you view div/span as generic tags to which you can 
apply styles, you are embedding them within your content to do 
just that, which means you are embedding *style* (layout) into your 
markup... they have no semantic meaning and impart no structure, 
so therefore they exist only to style (by breaking up content and 
acting as anchors for CSS)...

> >if down the road you need to modify your classes, perhaps rename
> >them, you still have to go into each content page and change your
> >class names... maybe you'll have to add a new one, which means you
> >still have to go into every page...
> 
> Your point is valid, but thats a coding issue.  If the objects to
> which styling needs to apply are properly identified (whether through
> markup or naming) then you shouldn't need to change anything in the
> HTML.

no, you shouldn't need to, but you'll still *have* to if that pops up... 
hey, don't get me wrong, somebody embedding inline styles to a 
<strong> is also embedding style in their content, blurring the 
separation... but overall, if it pops up as an issue, you'll need to 
edit every page...

> eg I have a class called bodypic which represents images that are just
> there for show (as opposed to a geological diagram which has a
> different objective).  That group of images represented by bodypic
> have a particular style.  If an image is in the wrong class, sure I
> need to change the HTML to put it in the right class.  However, if the
> style applied to bodypic is wrong it must be wrong for all images in
> that class.  So I change the stylesheet and it fixes all images in the
> site in that class.

the point is, though, if you need to change the HTML on every 
content page, instead of one template, you haven't separated your 
content from your style (which, again, is your markup and CSS)...

> No list, happy to present the page to all browsers that support
> getElementById. (We did check that it included ie5,ie55 and ns6 before
> we started work)

i still think letting any browser get to it, regardless of how the page 
renders, is better, but that's my opinion...

> >i guess i can see your point for the short-term... yes, it seems to
> >address what you need now, but i think you are possibly doing
> >yourself a disservice by ignoring not only some of the users, but
> >also by believing that you've actually achieved that separation of
> >style from content...
> 
> I've achieved it in the context of HTML4.01.
> I can change the position and style of various objects on the page
> (and on every page in the site with those objects) without changing
> the HTML.

no, you really haven't... you've split your markup and your style, but 
your content is still embedded in markup, which by all the 
definitions of style vs. content you'll see thrown about here, is not 
separation of style from content... *style* is not just CSS, it is also 
all the presentational markup on the page, and your pages still 
have presentational markup embedded within the content... again, 
if you change a class (like its name), you have to edit every .html 
file on the site... that's not separation...

but it also doesn't mean you need a db to do it, you could just pull 
content from text files via SSI, which i've done on a couple sites... 
makes presenting a printable page very easy, since there is no 
style in the content to override in order to change the layout...

> >and is using the 'full potential' of the standards worth it when only
> >the latest versions of three browsers are capable of rendering it
> >even remotely correctly?
> 
> For this site, yes.  would I do it for a site designed for schools?
> probably not.

i consider you lucky... i have no clients that will allow their sites to 
not render the same for 15% of their users...

> >> Basically, that is a user choice - I'm not shrouding my "failure" -
> >> I'm pointing out to users who don't know/realise a simple fact.
> >
> >and you think they'll listen to you?  or care?
> 
> That is a decision for them to take, given the information provided to
> them.

i think you'll note that i've already said you don't give good enough 
information to form an educated decision...

> >this is where i truly take issue with your points... you incorrectly
> >assume that all users can upgrade, and all users have no reason not
> >to... let's disregard users who: - cannot upgrade due to corporate
> >policy...
> 
> Wait.  This site is targeted at high bandwith corporate users.  We
> have assumed:
> 
> a) being high bandwidth they are reliant on technology; and
> b) corporate users who can afford high bandwidth are likely to invest
> in recent technology. c) if not they are likely to have the capability
> to upgrade at least one machine in their office;
> 
> In the context of our target audience, we considered the redirect
> appropriate.

ok, you've assumed it, but do you have any data to back it up?  
we've already seen even PwC can't satisfy any one of the three 
points, and they're reasonably large...

and high bandwidth doesn't imply anything beyond high 
bandwidth... you may see a correlation in browser versions, but 
overall, i've never seen anything in my work to say that all high-
bandwidth users satisfy your three points... let's consider DSL, 
which i consider to be high bandwidth:

a) users of DSL are reliant on technology?  perhaps, but for all the 
accounting firms in town, that's Great Plains or Solomon... that 
doesn't imply they are reliant on new browsers...

b) DSL is cheap, so what's the numeric correlation between dollars 
spent on bandwidth and dollars spent on higher-end machines?  
those accountant machines are still P2s running IE4, and they're 
not changing (they're down the hall from me, too)...

c) so, DSL users are allowed to upgrade?  that's odd, as soon as 
you get an IT department setting up a firewall, i've often found any 
customization related to the internet is disallowed from personal 
machines (like browser upgrades, chat software, etc.)...

> all of the above can be true - but aren't in the target audience. 
> Surely you'd agree that you design a site for a particular audience. 
> If you decide on a windows platform - well you are excluding all macs,
> pick ie and use document.all - there goes everyone else.  This is
> unavoidable - unfortunately at the moment you can't design for
> everyone.  What about Flash navigation?  This issue has faced you
> designers for years - I think it is the wording of the redirect that
> you object to, not the concept.

yes, i do object to the wording... but i also disagree with your 
statement that you can't design for everyone... in fact, you can, 
perhaps past the 99% mark... you aren't doing that, though...

and i don't think you know enough about your target audience to be 
able to make the decisions you've made...

> It is the users choice whether to upgrade.  As a result of the
> discussion I agree that the wording needs amendment.  This site will
> not work unless the browser supports getElementsById, not from a
> presentation point of view, but from a dhtml one.

wow, you still see it as the user's choice?  somehow you've 
missed my point that it's not always the user's choice, and it's 
often less the user's choice than most people think... if i can't get 
you past that, i can't help you there... so, got $500 to upgrade my 
TV?  i'm not gonna spend it...

> I checked the site in ie5.0 win98 and it looked fine.  Can I have a
> screenshot please?

just use the Mac one... it's close enough...

> Yep, it will be worth it.  We can redesign on a six monthly/annual
> basis and the final code will be much easier for others here to
> insert/delete content. Will we?  There is a plan to update 6 monthly -
> will that involve positioning/color changes?  who knows - better to be
> prepared.

granted, and i suspect this will work for you precisely because you 
don't need to do all the things with it that would benefit from a true 
split between style (markup and CSS) and content... i don't think, 
however, that you've got it quite right...

> >> Everyone else can, just choose not to.
> >
> >yep, that's the part that bugs me... not only is it categorically
> >false, it is also highly arrogant...
> 
> Are you sure it is categorically false for the bulk of our target
> audience?

that depends, now doesn't it?  it's your site and your audience, 
shouldn't you be able to cite percentages for me?  i can tell you for 
one site i'm working on now, after polling users and similar 
audiences, about 35% of the users cannot upgrade past NN4.x and 
IE4... no, that's not the 'bulk' of users, but that's what i consider to 
be show-stoppingly significant...

> >yeah, i suppose we've all chosen not to sneak into the library and
> >upgrade their systems, or not to bypass corporate policy, or not to
> >spend $800 dollars to get a system to run the latest browsers... but
> >we *can*...
> >
> >seriously, don't trot that argument out again, it won't fly here...
> 
> that argument is mostly true for my targeted audience.  It is not true
> for the web using community as a whole.

so, what are the numbers?  or, better yet, who, specifically, are the 
users?  have you polled their existing clients?  their most recent 
prospects?  what to the numbers look like there?




More information about the thelist mailing list