Re: New MCF pages

Hi.
Sorry that this mail might come over a bit unfriendly, but I've put some 
  good effort in this page and this criticism is beginning to annoy me 
quite a bit.

Steve Lhomme wrote:
> Sorry, I sent it to the wrong address.
> 
> En réponse à ChristianHJW <[email protected]>:
> 
>>>- place some title and/or alt text informations when you includes
>>
>>images
>>
>>>  on a web page
>>
>>Sorry for my stupid question, but what is the reason to do that ?
> 
> 
> For the next reason I give ;)
> Actually if you try to validate your HTML code on the W3C validator it will
> tell
> you that putting an alt information on every image is mandatory. (at least for
> strict (X)HTML). And the title one help to display a text information (Mozilla
> handle the Title one, not Alt) when you pass over an image. This is also VERY
> important for text based browsers (no pictures, so each picture has to be
> described) or blind people.
>  
Read the code before you moan. All images have alt texts. ALL. And I'm 
not even THINKING about using HTML 4.0-strict.

> 
>>>- test the pages in lynx (or links) to make sure all valuable
>>>informations are available.
>>

I have tried it with lynx, it looks neat, readable and all information 
comes through clearly.

>>We had a few people browsing the pages with Mozilla and all were happy,
>>so
>>we should be fine i guess.
> 
> 
> Mozilla, as MSIE, is error compliant. If there are some mistakes in the code,
> the page will still render normally.
> 

As far as I know there are no HTML errors anywhere. The only "error" I 
found was something that looks more like a bug in Lynx than anything 
else, and that is that it doesn't handle the spaces in the project page 
url. I have planned talking to hikke about this, to replace the space 
with %20.

> 
>>>- I see that all the pages have URLs like
>>>http://mcf.sourceforge.net/newpage/?content=Project Page
>>
> (notice the
> 
>>>blank space in the URL :( ) . This is not acceptable for various
>>
>>reasons :
>>
>>The decision to make standard design available in a php script was done
>>by
>>mf and myself, and i fully back it up. The main reason to do this was to
>>be
>>able to update the content easily, without having to change the whole
>>page
> 
> 
> Well, I assume that the site update will be done from a Web Form... That makes
> working offline on the site a hell. Especially when you work without the
> original design locally. If you can explain me how it can make things easier...
> 
> 
>>all the time, especially with respect to updating content from CVS one
>>day.
> 
> 
> You can update the site from CVS with static HTML pages. PHP is worth if you
> have a database behind, not a CVS. (copying the submitted HTML pages to the
> website on each check-in should be possible)
> 
> 
>>After all the work that has been invested from mf and hikke to get it
>>up
>>this way i dont recomment to change it now.
> 
> 
> I think it's time NOW that is not launched. After it will be a bigger work.
> 
> 

Content pages are now simply HTML pages stripped from their header and 
footer (head tags, body tag and document closing tags).
This is easy to edit, also in dreamweaver, I've done it, and content 
creation is easy too. A quick ssh login to mcf.sourceforge.net and you 
can write pages on the fly. This is how I'm doing it now, except for 
some more complex pages that I can't write by hand.
For CVS, hikke and I have planned to include an external content system, 
that will read the pages >DIRECTLY< from http://cvs.sourceforge.net, 
which makes it impossible for any desynchronisations with CVS pages to 
occur.

>>>* many search engines don't collect informations on dynamic pages.
>>
>>And
>>
>>>we definitely want to be searchable in a good way
>>
>>There is a simple solution to that i guess, we should setup a normal
>>HTML
>>page also containing all the important expressions surrounding MCF, and
>>then
>>link from this page to the other ( dynamic ) pages .
> 

We'll find a way for google (it's the only real search engine) to index 
our pages properly. I think there are some meta tags to help this (note: 
  even though most html is finished, I can still edit meta tags that 
would appear on all pages, because of the dynamic pages, saving a lot of 
work).

> 
> So what's the use of dynamic pages if you have the same static ones ?
> I'm sure the specs and many other sections don't need to be dynamic.
> If you want something efficient that can be updated with a web form daily
> easily, you can have the result of the form produce different static HTML
> pages.
> That will be the only needed dynamic part on the site (only available to
> admins).
> 
> 
>>>* using one page for a whole site (index.php ?) can look sexy from a
>>>coders point of view. But it's a hell to maintain (especially for
>>
>>people
>>
>>>using Dreamweaver or who don't know PHP).
>>
>>I thought its easier to update the content once its done ?
> 
> 
> It's equal, if not worse.
>

I'd go as far as saying that Christian can update page content himself 
after some quick instruction, which would be clear enough to indicate 
that it's easy. (No offence Christian)

> 
>>>* there is no need for dynamic content on most of this pages. This
>>
>>would
>>
>>>be MUCH easier to use simple static (X)HTML in this case. Design
>>>consistency can be enforced with CSS Stylesheets and maybe SSI
>>
>>includes
>>
>>>(don't know if Sourceforge support that).
>>
>>We decided to use php for this and i hope you can live with that.
> 
> 
> But don't make a whole site in 1 page !!!! Especially if 90% of the site only
> need static pages.
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf


Ohyea, and I don't see the sourceforge logo mentioned anymore. So I'll 
answer to that here. sflogo.php IS included in ALL pages, it's just 1x1 
pixels, so that I can use my own version that fits the design better to 
link to sourceforge.
I must say that I'm also pro-png for a lot of reasons, but browser 
support is a thing that's bugging me a bit. I am completely behind the 
idea of not using gif for patent reasons, and I don't use JPEG because 
of poor quality, but I simply think that it's a bit, well, unnecessary 
to go use PNG in all our pages now. Every graphical browser can read it, 
also those in linux distributions, so basically you're recommending 
something out of principle. I don't think MCF is something that bothers 
with free patent issues, as we allow codecs like MPEG-4, and we even 
allow companies to use our spec in their proprietary products!

I'll make this clear: I myself am NOT planning on dropping PHP now, the 
gif issue can be discussed, as there's no real disadvantage (except that 
most browsers don't support PNG transparency, and they do with GIF). I 
will /not/ see my design ruined with smart-ass ideas, and if you are 
against my ideas you are free to delete my page from sourceforge, deny 
me webadmin access, and do it better yourself. I think except for some 
glitches the site is OK, readable in all browsers easy to maintain, and 
ready for going public when all the content is finished.


Regards, mf





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf