[thelist] Site redirect check : old browser

Mark Cheng mark.cheng at ranger.com.au
Wed Jun 6 01:10:37 CDT 2001


Hey aardvark - should we move this to thesite?  It seems to be straying off
topic?


>-----Original Message-----
>From: thelist-admin at lists.evolt.org
>[mailto:thelist-admin at lists.evolt.org]On Behalf Of aardvark
>Sent: 6 June 2001 12:31
>To: thelist at lists.evolt.org
>Subject: RE: [thelist] Site redirect check : old browser
>
>
>> From: "Mark Cheng" <mark.cheng at ranger.com.au>
>[...]
>> I didn't say it wasn't.  What I said was that I was looking for the
>> benefits of separating style from content.  As I have no backend
>> skills whatsoever I didn't need the complication of a backend template
>
>i wouldn't refer to it as complication, nor is a data source being
>separate from the content genuinely analogous to a page with CSS-
>P handling layout...
>

Its complicated if you don't know anything about backend ! Like me :)


>i think the confusion here is that you are using the wrong
>terminology, and possibly believing that you've got something else...
>
>what you have achieved with the CSS-P and <div> is *not* a
>separation of style and content, it is a separation of style and
>*mark-up*... your content is still inextricably woven into the
>markup, meaning your content is not separated from anything at
>this point...
>

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.


>ok, push it to WAP... or slap an HTML2 template on it... or output
>your content as an RSS feed... all without touching a line of
>markup in your HTML pages...
>
>*that's* why your content is not separate from your mark-up... but
>your mark-up is separate from your style... which is really irrelevent
>as far as separation of content goes...
>

????  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.


>and let's not forget that <div>s in and of themselves imply no
>structure (like a <p> implies a paragraph, for instance)... by using
><div>s, you are, in fact, embedding style into the content, because
>you are inserting something other than structure and semantic
>value...  now if this were XML, i'd take a different tack on that...
>

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.

>> I'm looking forward (as in I'm eagerly awaiting - not "you are
>> backward looking")  to the day when we have a naming convention so
>> that all content is in a div id="content" or somesuch.  Then in my
>> user stylesheet I can set the preferences I want for the content (like
>> moving it into the center of the screen and blocking out ad banners :)
>> ).
>
>heh, that would be nice, but never happen... trying to standardize
>how people name classes is unlikely... but it would be nice... as it
>is, you can at least define all the HTML tags that exist through a
>personal CSS doc and handle those... you think ad-driven sites will
>create a 'spam' class?

Yeah, not for HTML.  Oh well, have to wait for XML and its children.
>

>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.

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.


>without listing them, do you have an absolute list of what those
>browsers are?  does the client (or is it your boss?)?  i don't
>consider that too simple (seen browsers.evolt.org?)... in fact, most
>of my sites eschew any kind of client-side script, beyond
>rollovers... relying on the client like that can be problematic...
>

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 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.

>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.

>
>> 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.


>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.


>- do not have a powerful enough system to upgrade...
>- can't get their kids over to do it...
>- surf at the library...
>- don't want to stay online for 3 hours to get a browser...
>- don't want to futz with their system, now that it's stable...
>- don't understand the message you're sending them...
>

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.


>in addition, the 'fact' you point out is that their browser is not W3C
>compliant... guess what, neither is the new one they'll download...
>that's a fact... but you don't mention that... your fact is a
>conveniently placed massaged bit of information to bolster your
>argument, but in reality, its implication is not true, so i wouldn't
>qualify it as fact...

Ok, so the wording needs amendment, I've already accepted that.

>
>so, you have actually taken away important information about the
>browsers out there (by presenting some, but leaving other
>information absent), and you've told them to upgrade, like it or
>not... you purport to educate the user, but give inaccurate and
>inadequate information...
>

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.

>> Actually this discussion has made me realise that the issue with this
>> site is not the positioning - its the javascript.  I wrote the
>> javascript using DOM and getElementByID.  The nav menu, expanding divs
>> and rollovers rely on DOM support.  So - as long as I put in
>> appropriate capability checking - and a warning that some things won't
>> work - I don't need a redirect.  I think that I'll still keep it, but
>> a wording change may be appropriate.
>
>agreed... capability checking would help a lot, as well as a clean-
>up of wording... i think the site can still work when linearized,
>although that's where you may want to explain why it doesn't look
>like eCompanyFoo.com...
>
I agree - maybe a popup if JS not enabled, doesn't support getElementById is
better.


>the problem cited on the mac is the same one i saw on IE5 (i don't
>have IE5.5), which, by the way, is still in the 5.x chain... are you
>not supporting IE5?  hmmm... if not, your assumed saturation is
>going to go *way* down...
>

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


>> As I said above, yes a simple table would have sufficed, but we wanted
>> the flexibility.
>
>of...? are y'all gonna change the layout and colors on a daily
>basis?  just *what* flexibility are you going to be using on a highly
>regular basis?  yeah, you can change the positioning and color via
>the CSS file, but are you going to?  and if so, how often?  will it
>have been worth it?  (considering you probably could have done a
>tabled layout in the time spent discussing this with me)
>

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.

>> >btw, let's not forget that not everyone can upgrade their browsers...
>>
>> Disagree - if you are referring to businesses, in today's e-world
>> businesses are more likely to upgrade faster than the general public.
>> They need to to maintain their information distribution systems.  (I
>> used to work for PricewaterhouseCoopers - their spending on knowledge
>> management was vast.)
>


>> 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?


>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.


This email may be confidential and contain commercially sensitive information.  Only the intended recipient may access or use it.  If you are not the intended recipient please delete this email and notify us promptly. 
We use virus scanning software but exclude all liability for viruses or similar in this email or any attachment.






More information about the thelist mailing list