You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by David Crossley <cr...@indexgeo.com.au> on 2002/05/26 05:14:50 UTC
Re: Forrest HTML
Bert Van Kets wrote:
> Robert Koberg wrote:
>
> >There are alot of platforms and browsers to cover. Does this need to work
> >on all of them? What is the criteria to exclude a platform/browser from
> >the accepted list? There should really be some statistics as to what of
> >types of browsers are coming to apache.
>
> The logs of the webserver can provide that info. Who do we need to call
> upon for this one??
At one stage in early Forrest, there were some people working
on automated graphs of server and project statistics. During
that discussion there was talk of access to certain logfiles
and summaries. I tried to find the discussion, but no luck.
Here is one bit ...
Re: Graph data
http://marc.theaimsgroup.com/?l=forrest-dev&m=101431895118362
However, do we really need to know? Will browser and OS statistics
actually help us? I think not. Let us stick to the cleanest
(X)HTML code that we can manage with our powerful tools.
--David
Re: Forrest look-and-feel
Posted by Bert Van Kets <be...@vankets.com>.
Thanks for the input. Since this regard the L&F of the page they must go
through the list. Although I doubt that anyone would mind putting them in.
Votes please!
Bert
At 22:42 28/05/2002 +1000, you wrote:
>Bert,
>
> I know your flat out - but just want to flag a Useability issue;
>*The page number feedback text and the page navigation widget at the top of
>content should be mirrored at the bottom of the content.
>Reasoning being that if the User has to scroll down, they don't have to
>scroll back to top of the page to keep Control - also promotes better Flow.
>
>There should be a "To Top" link at bottom of pages also.
>
>What is the formal process for design Comments/Change Requests here?..
>should I just flow these through you..
>
>Chris
Re: Forrest look-and-feel
Posted by Chris Bentley <cj...@webguy.com.au>.
Bert,
I know your flat out - but just want to flag a Useability issue;
*The page number feedback text and the page navigation widget at the top of
content should be mirrored at the bottom of the content.
Reasoning being that if the User has to scroll down, they don't have to
scroll back to top of the page to keep Control - also promotes better Flow.
There should be a "To Top" link at bottom of pages also.
What is the formal process for design Comments/Change Requests here?..
should I just flow these through you..
Chris
Re: Forrest look-and-feel
Posted by David Crossley <cr...@indexgeo.com.au>.
Bert Van Kets wrote:
> Hi Forestiers,
>
> David Crossley wrote:
> >It would help to try keep the look-and-feel aspects discussed
> >in a separate thread and leave the browser-specific things
> >to the other threads.
> >
> >A few issues have been identified so far. Please add any more
> >such high-level issues.
> >
> >1) Square edges on the panels vs rounded corners.
>
> The decision to create rounded edges was not made by me. I based this on
> the design from Stefano. There is a PhotoShop file in
> src\resources\layout\xml.apache.org created by Stefano (and girlfriend to
> be exact). I liked it, so used it to create the page.
> I clearly stated in my mails that I would use that file to create the page.
> If I did not need to implement the rounded corners I could have finished
> the page in 1 third the time! I spent a LOT of time getting the corners
> right *every time*.
Sorry, but i did alert the list to the fact that Stefano's
first cut was not final.
If it takes a lot of effort to get the rounded bits to happen,
then i would suggest that indicates that they are too complex
and should be dumped. That is my rule-of-thumb in programming
too - it indicates that i am trying to do it the wrong way.
> >2) Need minimum indents for <ul><li> in the menu panel.
> >Can basic CSS can fix that?
>
> This is just content. At the moment it is done with unnumbered lists, but
> we can change that to lines with indents done by graphics or a table grid.
>
>
> >3) Where will the page title be placed? Will it just be the
> >first piece of content below the light-blue "Page 1 of 5"?
> >Will it be an <h2> level heading?
>
> Actually an h1 would be more relevant since it's considered more important,
> specially by robots indexing the page. We can style it using CSS. The
> location looks correct to me.
>
>
> >4) Is something gained by the white vertical bar down
> >the left-hand side of the window? We need to retain all
> >possible page space.
>
> It adds a little to the design, but can certainly be removed. A lot will
> need to change then. There's a 1 pixel line around the menu that will be
> rather ugly if it gets right up to the edge. I can remove the little line,
> but then a lot of "finesse" is lost from the design.
> Removing the white line simplifies the page a lot. Getting the little
> piece of horizontal bar at the left of the menu scale up with the right
> part was one of the challenges of the page. I cheated a little there since
> they are not in the same table and probably don't scale *exactly* the
> same. Since the menu is between the two no one will ever see it. I tested
> it with very little to very large text in different browsers and you really
> have to take a ruler to see the difference in height a large text sizes.
Leave it there then. However, alarm bells are ringing
out "too complex" again.
> >*) More?
>
> The French say "Les gouts et les couleurs, on ne discutte pas" (we don't
> discuss taste and color) which actually means that there will always be
> differences in opinion on style. One likes rounded corners, the other
> doesn't. One likes a white line at the left, the other doesn't. This
> discussion is endless!
I so not worry about taste and colour ... only usability
matters, and that means not wasting any valuable space on
the page. That is why i raised the issue of the vertical white
bar. I do agree that it helps to give the page a nice look.
> Let's make one thing clear: Let's first come to a decision on the layout
> (what you guys call "look and feel") and only then adjust the page. If we
> keep discussing and trying adjusting I'll be doing nothing but adjusting
> the page all day long. I thought the design was decided upon the
> layout/design from Stefano. Remarks and adjustments should have been made
> then. I made it very clear that I was going to use that design to start from.
The design was there for guidance but was not final.
I guess that we are now seeing troubles when we try to
go to implement it, and we need to revisit the layout.
Can the two ever be separated?
> I might sound harsh, but I've lost *countless* hours in the past creating
> and adjusting designs for customers who don't really know what they
> want. Since we are in a very distributed group here who can't sit around
> the table and make a final decision in a few hours I guess we must all
> accept the fact that we use a site that looks acceptable to everybody but
> mainly is technologically sound.
>
> Let's get a final agreement on the design and only then will I go on
> adjusting the page.
Well, we certainly do not want to waste anyone's time.
However, it is far better to waste a little time now than
to be stuck with a monster when we try to produce it with XSLT.
> Bert
>
> P.S. The above is meant to be constructive! I'm not pissed off, just hate
> to lose time on decision reviews. Do not start a flame war again. I don't
> want to be crying in the corner like Nikola ;-)
Please do not try to make jokes. We have seen that it
does not work in email.
--David
Re: Forrest look-and-feel
Posted by Bert Van Kets <be...@vankets.com>.
Hi Forestiers,
At 16:05 27/05/2002 +1000, you wrote:
>It would help to try keep the look-and-feel aspects discussed
>in a separate thread and leave the browser-specific things
>to the other threads.
>
>A few issues have been identified so far. Please add any more
>such high-level issues.
>
>1) Square edges on the panels vs rounded corners.
The decision to create rounded edges was not made by me. I based this on
the design from Stefano. There is a PhotoShop file in
src\resources\layout\xml.apache.org created by Stefano (and girlfriend to
be exact). I liked it, so used it to create the page.
I clearly stated in my mails that I would use that file to create the page.
If I did not need to implement the rounded corners I could have finished
the page in 1 third the time! I spent a LOT of time getting the corners
right *every time*.
>2) Need minimum indents for <ul><li> in the menu panel.
>Can basic CSS can fix that?
This is just content. At the moment it is done with unnumbered lists, but
we can change that to lines with indents done by graphics or a table grid.
>3) Where will the page title be placed? Will it just be the
>first piece of content below the light-blue "Page 1 of 5"?
>Will it be an <h2> level heading?
Actually an h1 would be more relevant since it's considered more important,
specially by robots indexing the page. We can style it using CSS. The
location looks correct to me.
>4) Is something gained by the white vertical bar down
>the left-hand side of the window? We need to retain all
>possible page space.
It adds a little to the design, but can certainly be removed. A lot will
need to change then. There's a 1 pixel line around the menu that will be
rather ugly if it gets right up to the edge. I can remove the little line,
but then a lot of "finesse" is lost from the design.
Removing the white line simplifies the page a lot. Getting the little
piece of horizontal bar at the left of the menu scale up with the right
part was one of the challenges of the page. I cheated a little there since
they are not in the same table and probably don't scale *exactly* the
same. Since the menu is between the two no one will ever see it. I tested
it with very little to very large text in different browsers and you really
have to take a ruler to see the difference in height a large text sizes.
>*) More?
The French say "Les gouts et les couleurs, on ne discutte pas" (we don't
discuss taste and color) which actually means that there will always be
differences in opinion on style. One likes rounded corners, the other
doesn't. One likes a white line at the left, the other doesn't. This
discussion is endless!
Let's make one thing clear: Let's first come to a decision on the layout
(what you guys call "look and feel") and only then adjust the page. If we
keep discussing and trying adjusting I'll be doing nothing but adjusting
the page all day long. I thought the design was decided upon the
layout/design from Stefano. Remarks and adjustments should have been made
then. I made it very clear that I was going to use that design to start from.
I might sound harsh, but I've lost *countless* hours in the past creating
and adjusting designs for customers who don't really know what they
want. Since we are in a very distributed group here who can't sit around
the table and make a final decision in a few hours I guess we must all
accept the fact that we use a site that looks acceptable to everybody but
mainly is technologically sound.
Let's get a final agreement on the design and only then will I go on
adjusting the page.
Bert
P.S. The above is meant to be constructive! I'm not pissed off, just hate
to lose time on decision reviews. Do not start a flame war again. I don't
want to be crying in the corner like Nikola ;-)
Re: Forrest look-and-feel
Posted by Christopher Bentley <cj...@webguy.com.au>.
On Monday, May 27, 2002, at 04:14 PM, Nicola Ken Barozzi wrote:
> From: "David Crossley" <cr...@indexgeo.com.au>
>
>> It would help to try keep the look-and-feel aspects discussed
>> in a separate thread and leave the browser-specific things
>> to the other threads.
>>
>> A few issues have been identified so far. Please add any more
>> such high-level issues.
>>
>> 1) Square edges on the panels vs rounded corners.
>
> When I saw the rounded edges, I likd them.
> Them they became squared, and I still preferred the rounded.
> Now you show me rounded again, and I realize how crappy the page looks
> while
> downloading.
>
> So I'm for the squared.
> I would like the page to look as pleasant as possible from the first
> character the browser displays.
>
>> 2) Need minimum indents for <ul><li> in the menu panel.
>
> +1
>
>> Can basic CSS can fix that?
Not across all browsers.
>> 3) Where will the page title be placed? Will it just be the
>> first piece of content below the light-blue "Page 1 of 5"?
>> Will it be an <h2> level heading?
>
> The page title should be clearly shown on top of the page IMHO.
>
> BTW, I don't like paging at all, because it obliges me to scroll
> anyways and
> then page too.
> We could keep some ability to switch pages, but it should be based on
> sections IMHO, not on breaking pages just for length preservation.
>
>> 4) Is something gained by the white vertical bar down
>> the left-hand side of the window? We need to retain all
>> possible page space.
>
> +1
>
>> *) More?
>
> Put in some non-compulsory emacscript that can collapse the left-hand
> side.
> It's just a matter of setting the vivibility of that div element.
Here are some Usability issues in regard to that;
*Hides navigation from the User.
*Naming of level 1 menu items becomes an increased issue for content
authors as 2nd level is not visable
*User needs to click to discover more navigation - User may require
repeated clicks until desired submenu item is found.
*User may initially be led down wrong path because they do not see an
item that more clearly represents their target.
*if implemented bullet marks should be replaced by some convention eg.
opening and closing triangle; to flag that there is hidden navigation.
Only a couple of browsers have implemented the CSS to replace an HTML
List's bullet mark with an image.
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
I found this recent article on usability quite good - nice summery
<http://www.boxesandarrows.com/archives/002330.php>
Is this kind of input helpful?, Chris
Re: Forrest look-and-feel
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "David Crossley" <cr...@indexgeo.com.au>
> It would help to try keep the look-and-feel aspects discussed
> in a separate thread and leave the browser-specific things
> to the other threads.
>
> A few issues have been identified so far. Please add any more
> such high-level issues.
>
> 1) Square edges on the panels vs rounded corners.
When I saw the rounded edges, I likd them.
Them they became squared, and I still preferred the rounded.
Now you show me rounded again, and I realize how crappy the page looks while
downloading.
So I'm for the squared.
I would like the page to look as pleasant as possible from the first
character the browser displays.
> 2) Need minimum indents for <ul><li> in the menu panel.
+1
> Can basic CSS can fix that?
> 3) Where will the page title be placed? Will it just be the
> first piece of content below the light-blue "Page 1 of 5"?
> Will it be an <h2> level heading?
The page title should be clearly shown on top of the page IMHO.
BTW, I don't like paging at all, because it obliges me to scroll anyways and
then page too.
We could keep some ability to switch pages, but it should be based on
sections IMHO, not on breaking pages just for length preservation.
> 4) Is something gained by the white vertical bar down
> the left-hand side of the window? We need to retain all
> possible page space.
+1
> *) More?
Put in some non-compulsory emacscript that can collapse the left-hand side.
It's just a matter of setting the vivibility of that div element.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Forrest look-and-feel
Posted by David Crossley <cr...@indexgeo.com.au>.
It would help to try keep the look-and-feel aspects discussed
in a separate thread and leave the browser-specific things
to the other threads.
A few issues have been identified so far. Please add any more
such high-level issues.
1) Square edges on the panels vs rounded corners.
2) Need minimum indents for <ul><li> in the menu panel.
Can basic CSS can fix that?
3) Where will the page title be placed? Will it just be the
first piece of content below the light-blue "Page 1 of 5"?
Will it be an <h2> level heading?
4) Is something gained by the white vertical bar down
the left-hand side of the window? We need to retain all
possible page space.
*) More?
Re: Forrest HTML
Posted by Bert Van Kets <be...@vankets.com>.
>>I don't agree since you will be getting a VERY false image on browser
>>use. Let me give an extreme example: You have a page that is only
>>viewable on IE. How many Netscape hits do you think you will get?
>>NONE!
>>We must start out with the most common delimiter starting from a certain
>>browser version
>
>How have you determined what that is without viewing some current site
>stats or doing User profiling?
If you go that way, you have the chicken-and-the-egg problem. You can only
get a *correct* browser version and type you have to target once the site
has been running for a while wile being compatible with ALL of them. If you
don't do this, you will never get correct stats.
It's a hard way to go, but it can make a world of difference in user visits.
>> and a certain group of browser types (IE4, NS 4.08 Opera5 and Lynx
>> 2.4). Only after a certain period of time will the server stats tell of
>> we can upgrade our technology.
>>
>>Bert
>>
>
>also I can help you with testing I have 3 macs and a win2k box which
>I can install any OS between 8.0 and 9.1 on the older Mac but need to keep
>IE5 installed on the Win2k box on OS X on my other macs, but I
>have pretty much every major browser release for the Macs going back to
>Netscape 2... I suspect your Mac User profile might be a OS X only zone. :)
Thanks for the offer. I'm almost done with the pure HTML version. I'll
let the list know as soon as I have something online. There are some
pretty complex nested tables in the page, but it shows up perfectly in
Netscape 4.08 while being scaleable in text and browser size!
Bert
>cheers, Chris
Re: Forrest HTML
Posted by Christopher Bentley <cj...@webguy.com.au>.
Hi Bert,
On Sunday, May 26, 2002, at 06:55 PM, Bert Van Kets wrote:
>> Well the cleanest would be using CSS :) But the reason to check what
>> browsers the users actually use will tell us what browsers *need* to
>> look perfect. Those that fall into a certain low percentage and
>> display the page incorrectly are not considered in testing, nor is
>> time spent on trying to make it work.
This is the headspace I have the most experience with....
> I don't agree since you will be getting a VERY false image on browser
> use. Let me give an extreme example: You have a page that is only
> viewable on IE. How many Netscape hits do you think you will get?
> NONE!
> We must start out with the most common delimiter starting from a
> certain browser version
How have you determined what that is without viewing some current site
stats or doing User profiling?
> and a certain group of browser types (IE4, NS 4.08 Opera5 and Lynx
> 2.4). Only after a certain period of time will the server stats tell
> of we can upgrade our technology.
>
> Bert
>
>
also I can help you with testing I have 3 macs and a win2k box which
I can install any OS between 8.0 and 9.1 on the older Mac but need to
keep IE5 installed on the Win2k box on OS X on my other macs, but I
have pretty much every major browser release for the Macs going back to
Netscape 2... I suspect your Mac User profile might be a OS X only
zone. :)
cheers, Chris
Re: Forrest HTML
Posted by Bert Van Kets <be...@vankets.com>.
At 22:14 25/05/2002 -0700, you wrote:
>Hi David,
>
>David Crossley wrote:
>
>>Bert Van Kets wrote:
>>
>>
>>>Robert Koberg wrote:
>>>
>>>
>>>
>>>>There are alot of platforms and browsers to cover. Does this need to
>>>>work on all of them? What is the criteria to exclude a platform/browser
>>>>from the accepted list? There should really be some statistics as to
>>>>what of types of browsers are coming to apache.
>>>>
>>>The logs of the webserver can provide that info. Who do we need to call
>>>upon for this one??
>>>
>>
>>At one stage in early Forrest, there were some people working
>>on automated graphs of server and project statistics. During
>>that discussion there was talk of access to certain logfiles
>>and summaries. I tried to find the discussion, but no luck.
>>Here is one bit ...
>>Re: Graph data
>>http://marc.theaimsgroup.com/?l=forrest-dev&m=101431895118362
>>
>>However, do we really need to know? Will browser and OS statistics
>>actually help us? I think not. Let us stick to the cleanest
>>(X)HTML code that we can manage with our powerful tools.
>Well the cleanest would be using CSS :) But the reason to check what
>browsers the users actually use will tell us what browsers *need* to look
>perfect. Those that fall into a certain low percentage and display the
>page incorrectly are not considered in testing, nor is time spent on
>trying to make it work.
I don't agree since you will be getting a VERY false image on browser
use. Let me give an extreme example: You have a page that is only
viewable on IE. How many Netscape hits do you think you will get? NONE!
We must start out with the most common delimiter starting from a certain
browser version and a certain group of browser types (IE4, NS 4.08 Opera5
and Lynx 2.4). Only after a certain period of time will the server stats
tell of we can upgrade our technology.
Bert
>best,
>-Rob
>
Re: Forrest HTML
Posted by Christopher Bentley <cj...@webguy.com.au>.
Rob just some minor comments - added inline
On Monday, May 27, 2002, at 12:35 AM, Robert Koberg wrote:
> Hi Christopher, thanks for the reasoned replies. (comments inline)
>
> Christopher Bentley wrote:
>
>> On Sunday, May 26, 2002, at 03:14 PM, Robert Koberg wrote:
>>
>>>>
>>>> However, do we really need to know? Will browser and OS statistics
>>>> actually help us? I think not. Let us stick to the cleanest
>>>> (X)HTML code that we can manage with our powerful tools.
>>>>
>>> Well the cleanest would be using CSS :) But the reason to check what
>>> browsers the users actually use will tell us what browsers *need* to
>>> look perfect. Those that fall into a certain low percentage and
>>> display the page incorrectly are not considered in testing, nor is
>>> time spent on trying to make it work.
>>
>>
>> Hi Rob
>>
>> My Requirements Docs used to say "Must render and function
>> Identically on IE5+ and Netscape 4.03+ on WIndow and Mac". They have
>> been increasingly relaxed about the 'render Identically' part for
>> about a year in regard to NS4.
>>
>> CSS is not as scary as it used to be, IE5mac, IE6 Windows and all
>> Mozilla variants have very nice solid support up through quite big
>> chucks of CSS2 and IE5 Windows although quirky and non-complient is
>> manageable in the most part and has pretty full CSS1.
>
>
> CSS2 seems to be obsolete before it even gets going (CSS3 is well
> underway). I would defintitely stick with CSS1.
But CSS3 wont replace CSS2, one of its design goals is to be
forward-compatible with CSS2?. In any case yes, you coudn't get too wet
because of the need to support IE5 Windows (and by implication juggling
tricks with the IE Box model and incomplete CSS1)
This is in fact my delema, I'm not too worried about CSS's ability to
handle the build past phase 3 but that IE5 Win would need to be treated
as a peer browser with the so called 'Standards Compliant' set. (IE6 and
IE5mac also have frustrating issues but that's a long conversation) -
its being able to scale the project and not have IE5W or Opera kill you
is the very scary bit.
>>
>>
>> I believe IE6 Windows use runs at around 60% in SME stats at present
>> with IE5 Windows taking up most of the remainder, as I mentioned in my
>> post "Cold sweat" your Users are likely to have scewed browser stats
>> and it would be good to find out at least what that scew is if in fact
>> it exists.
>
>
> yes, exactly. It could be that there are 30% of users coming in with
> Nav4.n. We should know to make sure.
>
>>
>>
>> While the design I have seen will have no problem with a full on CSS2
>> base build, it would however place you at the bleeding edge with all
>> the pit falls of that place - would you be prepared to cope with the
>> problems (and possible delays) that may arise in the UI.. the
>> outstanding questions maybe.
>> *will it scale to met all the requirements to Phase 3
>> * are there enough support people who have the CSS2 to maintain and
>> advance such a build
>> * do you want to be an early adopter
>
>
> On early adopter :) well... not for commercial stuff. For me, for
> commercial stuff, cocoon2 (production release) is still too young.
> Everything about cocoon seems like early adopter to me.
>
> <fwiw role="religion">
>
> But, taking cocoon's stated goal of SoC, why not extend that concept
> all the way down to the UA.
>
> XSL HTML structure (no presentation info)
> + -------> + ------------------------------------------>
> browser
> XML CSS presentation
>
> This would seem to be the most scalable and easily supported. You have
> a clean HTML structure separated from the final CSS presentation. The
> XSLT styling creating the HTML structure would rarely need to be
> changed going into the future. It is just SoC extended throughout the
> whole project. This seems to be right inline with cocoon ideals.
>
> </fwiw>
we go to the same church..
<xsl:choose>
<xsl:when test="//fwiw[@role = 'religion']">
XHTML
</xsl:when>
<xsl:otherwise>
HTML
</xsl:otherwise>
</xsl:choose>
> Since you can't eat your ideals, I agree that full-blown CSS would not
> work, but it would surely be the cleanest, most elegant (code-wise) and
> easily supported (by the maintainers) way to go.
Do you guys ever indulge yourselves with R&D side projects?
>
>>
>>
>> I can't answer these questions, no one I know has ever implemented
>> such a build in a commercial production of any scale- we are all
>> waiting on Mozilla 1.0 to be released!.. but there has been some great
>> work done over the last year to develop strategies to to deal with its
>> arrival. There is a pent up desire both by clients and developers to
>> move to this kind of build - myself included. for the following
>> reasons;
>>
>> The W3C recommend it
>> It leads to accessibility best practices
>> It is lightweight
>> It is future proof (I'm sure we've all heard that one before but at
>> least IE 7 should'nt break it)
>> It will work 'out the box' better against a wider cross section of
>> devises
>> It may even work ;)
>>
>> In the end Bert's view that he should center his design around
>> Netscape 4.08 may still remain the wisest for the obvious reasons not
>> the least because he is the one prepared to do it and is most
>> comfortable in that space. Also I sense a need for speed so adventures
>> in the unknown could be nerve racking for some
>
> Sure, I think Bert would be providing an excellent service to the
> community if he can make elegant, easily maintainable HTML for the
> project.
>
>>
>>
>> The downside to a NS 4 centered design is that it will not aid you in
>> keeping the UI lightweight, hack free or easily accessible.
>
> Theres the rub. I have to use nested tables to get everything looking
> correct across browsers/platforms (even then I doubt you can cover
> everything). I can't make a clean HTML layout that can render in all
> browsers.
>
> best,
> -Rob
>
>>
>> But hey our Apache! at least think about outputing XHTML 1.0
>> Transitional... its XML!
>>
>> Chris.
>>
>
>
>
Chris.
Re: Forrest HTML
Posted by Robert Koberg <ro...@koberg.com>.
Hi Christopher, thanks for the reasoned replies. (comments inline)
Christopher Bentley wrote:
> On Sunday, May 26, 2002, at 03:14 PM, Robert Koberg wrote:
>
>>>
>>> However, do we really need to know? Will browser and OS statistics
>>> actually help us? I think not. Let us stick to the cleanest
>>> (X)HTML code that we can manage with our powerful tools.
>>>
>> Well the cleanest would be using CSS :) But the reason to check what
>> browsers the users actually use will tell us what browsers *need* to
>> look perfect. Those that fall into a certain low percentage and
>> display the page incorrectly are not considered in testing, nor is
>> time spent on trying to make it work.
>
>
> Hi Rob
>
> My Requirements Docs used to say "Must render and function
> Identically on IE5+ and Netscape 4.03+ on WIndow and Mac". They have
> been increasingly relaxed about the 'render Identically' part for
> about a year in regard to NS4.
>
> CSS is not as scary as it used to be, IE5mac, IE6 Windows and all
> Mozilla variants have very nice solid support up through quite big
> chucks of CSS2 and IE5 Windows although quirky and non-complient is
> manageable in the most part and has pretty full CSS1.
CSS2 seems to be obsolete before it even gets going (CSS3 is well
underway). I would defintitely stick with CSS1.
>
>
> I believe IE6 Windows use runs at around 60% in SME stats at present
> with IE5 Windows taking up most of the remainder, as I mentioned in my
> post "Cold sweat" your Users are likely to have scewed browser stats
> and it would be good to find out at least what that scew is if in fact
> it exists.
yes, exactly. It could be that there are 30% of users coming in with
Nav4.n. We should know to make sure.
>
>
> While the design I have seen will have no problem with a full on CSS2
> base build, it would however place you at the bleeding edge with all
> the pit falls of that place - would you be prepared to cope with the
> problems (and possible delays) that may arise in the UI.. the
> outstanding questions maybe.
> *will it scale to met all the requirements to Phase 3
> * are there enough support people who have the CSS2 to maintain and
> advance such a build
> * do you want to be an early adopter
On early adopter :) well... not for commercial stuff. For me, for
commercial stuff, cocoon2 (production release) is still too young.
Everything about cocoon seems like early adopter to me.
<fwiw role="religion">
But, taking cocoon's stated goal of SoC, why not extend that concept all
the way down to the UA.
XSL HTML structure (no presentation info)
+ -------> + ------------------------------------------> browser
XML CSS presentation
This would seem to be the most scalable and easily supported. You have a
clean HTML structure separated from the final CSS presentation. The XSLT
styling creating the HTML structure would rarely need to be changed
going into the future. It is just SoC extended throughout the whole
project. This seems to be right inline with cocoon ideals.
</fwiw>
Since you can't eat your ideals, I agree that full-blown CSS would not
work, but it would surely be the cleanest, most elegant (code-wise) and
easily supported (by the maintainers) way to go.
>
>
> I can't answer these questions, no one I know has ever implemented
> such a build in a commercial production of any scale- we are all
> waiting on Mozilla 1.0 to be released!.. but there has been some great
> work done over the last year to develop strategies to to deal with its
> arrival. There is a pent up desire both by clients and developers to
> move to this kind of build - myself included. for the following reasons;
>
> The W3C recommend it
> It leads to accessibility best practices
> It is lightweight
> It is future proof (I'm sure we've all heard that one before but at
> least IE 7 should'nt break it)
> It will work 'out the box' better against a wider cross section of devises
> It may even work ;)
>
> In the end Bert's view that he should center his design around
> Netscape 4.08 may still remain the wisest for the obvious reasons not
> the least because he is the one prepared to do it and is most
> comfortable in that space. Also I sense a need for speed so adventures
> in the unknown could be nerve racking for some
Sure, I think Bert would be providing an excellent service to the
community if he can make elegant, easily maintainable HTML for the project.
>
>
> The downside to a NS 4 centered design is that it will not aid you in
> keeping the UI lightweight, hack free or easily accessible.
Theres the rub. I have to use nested tables to get everything looking
correct across browsers/platforms (even then I doubt you can cover
everything). I can't make a clean HTML layout that can render in all
browsers.
best,
-Rob
>
> But hey our Apache! at least think about outputing XHTML 1.0
> Transitional... its XML!
>
> Chris.
>
Re: Forrest HTML
Posted by Christopher Bentley <cj...@webguy.com.au>.
On Sunday, May 26, 2002, at 03:14 PM, Robert Koberg wrote:
>>
>> However, do we really need to know? Will browser and OS statistics
>> actually help us? I think not. Let us stick to the cleanest
>> (X)HTML code that we can manage with our powerful tools.
>>
> Well the cleanest would be using CSS :) But the reason to check what
> browsers the users actually use will tell us what browsers *need* to
> look perfect. Those that fall into a certain low percentage and display
> the page incorrectly are not considered in testing, nor is time spent
> on trying to make it work.
Hi Rob
My Requirements Docs used to say "Must render and function Identically
on IE5+ and Netscape 4.03+ on WIndow and Mac". They have been
increasingly relaxed about the 'render Identically' part for about a
year in regard to NS4.
CSS is not as scary as it used to be, IE5mac, IE6 Windows and all
Mozilla variants have very nice solid support up through quite big
chucks of CSS2 and IE5 Windows although quirky and non-complient is
manageable in the most part and has pretty full CSS1.
I believe IE6 Windows use runs at around 60% in SME stats at present
with IE5 Windows taking up most of the remainder, as I mentioned in my
post "Cold sweat" your Users are likely to have scewed browser stats and
it would be good to find out at least what that scew is if in fact it
exists.
While the design I have seen will have no problem with a full on CSS2
base build, it would however place you at the bleeding edge with all the
pit falls of that place - would you be prepared to cope with the
problems (and possible delays) that may arise in the UI.. the
outstanding questions maybe.
*will it scale to met all the requirements to Phase 3
* are there enough support people who have the CSS2 to maintain and
advance such a build
* do you want to be an early adopter
I can't answer these questions, no one I know has ever implemented such
a build in a commercial production of any scale- we are all waiting on
Mozilla 1.0 to be released!.. but there has been some great work done
over the last year to develop strategies to to deal with its arrival.
There is a pent up desire both by clients and developers to move to this
kind of build - myself included. for the following reasons;
The W3C recommend it
It leads to accessibility best practices
It is lightweight
It is future proof (I'm sure we've all heard that one before but at
least IE 7 should'nt break it)
It will work 'out the box' better against a wider cross section of
devises
It may even work ;)
In the end Bert's view that he should center his design around Netscape
4.08 may still remain the wisest for the obvious reasons not the least
because he is the one prepared to do it and is most comfortable in that
space. Also I sense a need for speed so adventures in the unknown could
be nerve racking for some
The downside to a NS 4 centered design is that it will not aid you in
keeping the UI lightweight, hack free or easily accessible.
But hey our Apache! at least think about outputing XHTML 1.0
Transitional... its XML!
Chris.
Re: Forrest HTML
Posted by Robert Koberg <ro...@koberg.com>.
Hi David,
David Crossley wrote:
>Bert Van Kets wrote:
>
>
>>Robert Koberg wrote:
>>
>>
>>
>>>There are alot of platforms and browsers to cover. Does this need to work
>>>on all of them? What is the criteria to exclude a platform/browser from
>>>the accepted list? There should really be some statistics as to what of
>>>types of browsers are coming to apache.
>>>
>>>
>>The logs of the webserver can provide that info. Who do we need to call
>>upon for this one??
>>
>>
>
>At one stage in early Forrest, there were some people working
>on automated graphs of server and project statistics. During
>that discussion there was talk of access to certain logfiles
>and summaries. I tried to find the discussion, but no luck.
>Here is one bit ...
>Re: Graph data
>http://marc.theaimsgroup.com/?l=forrest-dev&m=101431895118362
>
>However, do we really need to know? Will browser and OS statistics
>actually help us? I think not. Let us stick to the cleanest
>(X)HTML code that we can manage with our powerful tools.
>
Well the cleanest would be using CSS :) But the reason to check what
browsers the users actually use will tell us what browsers *need* to
look perfect. Those that fall into a certain low percentage and display
the page incorrectly are not considered in testing, nor is time spent
on trying to make it work.
best,
-Rob