Re: Re: New MCF pages
Steve Lhomme <[email protected]> Mon, 30 Sep 2002 15:04:03 +0200 (MEST)
| Newsgroups | gmane.comp.video.mcf.general |
|---|---|
| Message-ID | <[email protected]> |
En réponse à mf <[email protected]>: > 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. I know it takes some time to do that. But it's still time for changes (otherwise the request for comments on the website should be removed and you can put it only right now). I think I made constructive critics, so there's no reason for being annoyed. > Read the code before you moan. All images have alt texts. ALL. And I'm > not even THINKING about using HTML 4.0-strict. And XHTML ? (which is harder to verify with PHP BTW) Some of my comments were some advices based on my personal experience, not necessarily errors that occur on the page. Now I'm looking at the source and see : <img src="images/toplogo.gif" width="648" height="64" alt=""> Yeah, you have alt tags everywhere (didn't check). But this is just to trick a validator. It's not the way it should be used (with data inside, like when Tronic browse with a 28.8 modem, he already have the name of the image before it's downloaded). > >>>- 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. I'm sure the logo is not displayed and maybe not mentionned. > >>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 didn't say there are errors, but Mozilla and MSIE are not the best way to test a webpage. Actually the best way is to use Mosaic 3.0 and lynx. Both browser should have access to the information (that's why Flash is not a good option for a technical site). Also why do you want to keep the space (%20) in the URL instead of using _ or no space at all ? > 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 Good. Do you parse the HTML file for the <body></body> and put your layout around it ? > 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. Well, I don't see a real difference between copying a file with SCP or Checking in code in CVS (the former being much easier). It's only a good way to trakc changes. > 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). Uh ? What do you want to do ? There is one good way to trick Google, it's to use mod_rewrite. But I'm not sure SourceForge uses that for project hosting. I don't think we need any meta tag for that. BTW, you can edit meta tags and the layout with your system. But meta tags are rarely used, and when they should, they are pages dependant (so static=PHP). And most of the layout should go in CSS Stylesheet (so static=PHP). Of course PHP can do better things in this way. Also, the title of the page remains the same wether it's on Home, License or News. That's usually what is used as the link name in Google (or other engines). > 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. But your own version of the logo is blurry ;) Also on the aspect of the site, I don't like it much. Especially the MCF logo (I already mentioned in the forum I prefer Sarreq's one). But that's subjective and you can change it quickly with your system. > 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! My position is : - we use it = encourage software patents - we forbid it = discourage software patents I guess most of us here are for the second option (could be a good subject of Poll on the forum). Of course it's a political question, not technical. > 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. Don't get so nervous. I'm just trying to improve things. I've done the same mistakes I'm pointing in the past, so I want to avoid it and share my knowledge. Using 1 PHP page for a site is only good for security purposes in some cases, not for a system that serves static pages (SSI was created long before to do that). ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf