Stephanie Booth's online ramblings
If you are using Mozilla RC1 (you should be using RC2 – RC=Release Candidate), code that has been commented out on this page will be visible to you (in the sidebar, and the second sitemeter icon in the footer).
You’ll be happy to know that this parsing bug is being fixed.
Having trouble because part of your page doesn’t show up in Mozilla? Using sitemeter, by any chance?
You might be yet another victim of the vanishing div problem, documented by yours truly for the good of all.
Lighten up your spirits by enjoying this depressed server’s 404 (file not found) error message.
[thanks Karl]
If you find the prospect of wading through the w3c specs daunting, and you are a lucky user of Mozilla or Opera, you’ll find these sidebar tabs invaluable. Yes, follow that link even if you don’t know what a sidebar tab is. I didn’t either before I went there.
These tabs conveniently list all the HTML and CSS elements in your sidebar. Click on the tag, attribute or element you need information on, and you’ll be transported to the relevant place in the w3c specifications. Without the trouble of finding the right spec, and then the right place in the spec. Still there?
I can’t imagine I discovered about them only now.
Yes, Shirley tells us they work in Opera, don’t worry.
Un truc qui aide beaucoup lorsque l’on travaille sur une mise en page en CSS, c’est de rendre visibles les bords des boîtes (<div>) que l’on utilise.
Voici un bookmarklet qui vous permet de visualiser les boîtes de n’importe quelle page.
Il suffit de copier <a href="javascript:void(d=document);void(el=d.getElementsByTagName('div'));for(i=0;ile javascript en question dans vos favoris. Vous pouvez simplement saisir le lien ci-dessus avec la souris et le faire glisser dans vos favoris (pour mozilla et IE, en tous cas – je ne suis pas sûre de comment ça se passe dans Opera. Pascale?)
Il vous suffira ensuite de cliquer sur ce favori pour visualiser les divs et spans de la page sur laquelle vous vous trouvez. Pratique, non? En plus, ça existe aussi <a href="javascript:void(d=document);void(el=d.getElementsByTagName('div'));for(i=0;i<el.length;i++){void(el[i].style.border='2px dashed red')};void(el=d.getElementsByTagName('span'));for(i=0;ien couleurs! (D’autres bookmarklets?)
[En cas de problème technique, vous connaissez le numéro…]
I had a conversation with Karl the other day, about static vs. dynamic implementations for a website.
Depending on how many page views you have per hour on the server, a dynamic implementation could slow down a site unnecessarily.
The important analysis is this one: divide the number of content changes in a given time by the number of page view requests for a given page. The closer that number is to zero, the more static your content is. The closer it is to one, the more dynamic it is.
My content is definitely more on the static side. I add pages every now and again, edit them every now and again, and of course, update my weblog fairly regularly. I don’t use a database back-end, but I do use a fair amount of PHP to hold things together.
I use PHP because it makes maintenance easier. I don’t really use it because my content is dynamic – so it could be seen as “abusive” use of a dynamic implementation. However, I don’t have so many visitors that it does make a difference to the server.
If the server load did become too important, however, I would certainly consider putting in place a script that would generate a static version of the site (each day or on demand). Visitors would access the static version, but it would be easily produced by the “generator script” on the basis of the easy-to-maintain dynamic version.
What is your opinion on the subject? Are “dynamic” website implementions being used abusively? Under what conditions do you consider using a database as a back-end? Do you have any numbers or statistics which either validate or invalidate the theories exposed above?
I’d love to hear from you. Add your comments below.
Here is a good page on using meta tags like “description” and “keywords”, and how they influence (or rather: don’t influence) search engine rankings.
Remember, you are using these tags to help make up for the lack of text on your pages, not as a way to successfully anticipate every keyword variation a person might enter into a search engine. The only hope you have of ever doing that is to have good, descriptive pages with good titles and text that is not buried on the bottom of the page by JavaScript, frames tags or tables. The meta tags are a tool to get around these aforementioned problems.
An interesting little survey is going on on webdesign-l: what tools do professionnal designers use?
From the replies of the list members who qualify as “professionnals”, it seems that BBEdit and Homesite (text-based editors like my beloved HTML-Kit) come out favorites, and that the likes of Dreamweaver tend to be reserved for churning out fast mock-ups.
Karl pointed out to me an article which can help answer some of my concerns about dealing with real-life CMS (DW) adepts:
I now use xml to store my weblog posts. If you’re a geek, have a look at the source. If you aren’t a geek, the main improvement for you is under the search box: you can now choose to hide French or English posts in the weblog too (hiding the English ones comes in handy for automatic translation, as I may already have mentioned).