Archive for HTML

Set text file encoding to UTF-8 in Aptana

Working in a web environment, it’s important to keep your character encoding clear. Serious websites set their character encoding to UTF-8 to be sure to be compatible with different language sets. Obviously the same accounts for the database.

Sometimes it’s also important to set the text file encoding of your script file (php etc.). In Aptana 2 the global text file encoding is set to Cp1252. You can change this to UTF-8 the following way:

  • In Aptana go to Window -> Preferences
  • Type “encoding” in the search box.
  • Go to General -> Workspace
  • Change the text file encoding to UTF-8 and apply.

In my case Aptana hung with the build settings so I had to uncheck them all:

Happy UTF-8 programming!

Advertenties

Comments (2)

IE7 and form submitting

Often, IE7 is regarded less standards compliant than its open source alternatives. Accidentally I ran into a – at least for me – unknown feature in IE7 which proves that in some cases IE7 can be rather strict. Take this, a FORM without a submit-button, but with a BUTTON-button:

<form>
  <!-- a lot of code -->
  <button>fire!</button>
</form>

Firefox just submits the form when you click the button. IE7 however does nothing! It appeared that IE7 only submits the form when the attribute type is specified as type=”submit”.

  <button type="submit">fire!</button>

Cool! Seems logically in the end. Where are the times that Microsoft interpreted all your sloppy code?

Tested with a XHTML 1.0 Strict page with a FORM-element which included three BUTTON-buttons. I encountered no form submitting problems without the type attribute specified  in FF 2.0.0.1 or in Opera 8.54 on Windows XP SP2. I didn’t test in IE6 or other exotic browsers. Lees de rest van dit artikel »

Comments (7)

Betere HTML in 37 stappen

Een paar weken geleden publiceerde Tommy Olsson zijn artikel “Bulletproof HTML: 37 Steps to Perfect Markup“. Het is een leerzaam verhaal dat soms een belerend toontje heeft, maar desalniettemin voor velen de basiskennis van HTML kan vergroten. Een aantal dingen viel mij op.

Onder standardista’s is het nogal cool om geen XHTML, maar HTML te schrijven. Belangrijkste argument is doorgaans dat je XHTML als “text/html” en niet als XML mag serveren (omdat Internet Explorer daar geen raad mee weet). So what? zou je zeggen. Tommy Olsson: “We cannot use any of the features of XHTML when serving it this way, because we are not really using XHTML at all — we’re only pretending to.” Dan zou ik wel graag willen weten wat die ‘features’ zijn. Missen we echt iets? En over missen gesproken: mis je iets als je XHTML gebruikt in plaats van HTML? Ik vermoed van niet.

Wat ik niet wist was de betekenis van de opbouw van de DOCTYPE-declaratie (als <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">). Wat doet de ‘EN’ daar bijvoorbeeld? “Note that it doesn’t say anything about the language of the web page itself; it is the language of the DTD that is specified here.” Het eerste deel van de identifier heet de ‘public identifier’ en het tweede deel de ‘system identifier’. “If the system identifier is missing, or if there is no DOCTYPE declaration at all, browsers assume that this is an old document and render it in ‘quirks mode’.” (Hé, zou Anne bewust ‘quirks mode’ triggeren?)

Ook over character encoding is Olsson verhelderend. Ik wist bijvoorbeeld niet dat de character set die je in je HTML-pagina opneemt (bijvoorbeeld “<meta http-equiv="Content-Type" content="text/html; charset=utf-8">“) overruled wordt door de HTTP header die je mogelijk via de server verstuurt.

Over het address-element zegt Olsson dat “A common misconception is that address is meant to be used to mark up only postal addresses, but that is not the case.” Ook telefoonnummers en andere contactinformatie kan met het address-element opgemaakt worden. Hij vergeet evenwel te vermelden dat het bij het address-element gaat om de contactinformatie die van toepassing is op de informatie die een bepaalde pagina geeft. Een adresboek bestaat dus nietuit een lange reeks address-elementen.Alleen de contactgegevens van de maker van het adresboek zou je in een address-element mogen verwachten.

Olsson licht nog een paar HTML-elementen toe die we nooit gebruiken omdat geen CMS ze ondersteunt. Maar toch is het handig om te weten dat “A certain term should only be marked up with dfn once in a document (where it is first used and explained)” en dat “A common misconception is that var should be used for marking up variables in programming code samples”.

Over het alt attribute kan nooit genoeg gezegd worden: “This text equivalent should not describe the image; it should convey the equivalent information”. Olsson geeft ook een helder voorbeeld om deze stelling toe te lichten (zie step 33).

Tot slot beweert Olsson dat de waarde van een id, name and class attribute altijd moet beginnen met een letter. Ik dacht evenwel dat het ook een underscore mocht zijn?

Een aantal van dit soort artikel tesamen zou een prachtig boek kunnen vormen over de basis en de achtergrond van HTML; verplichte kost voor iedereen die al langer dan vijf jaar met HTML zit te knoeien.

Tags: , ,

Comments (5)

Bulk HTML validation

In addition to the Dutch webrichtlijnentoets you can now do a bulk validation on a complete website with the marvelous Nikita the Spider. Nikita does HTML validation and searches for broken links and more. However, it’s still in alpha and the job has to be started by hand, so be patient! (via EGS)

Tags: , , ,

Comments (2)

Delta Lloyd

Twee weken geleden is de nieuwe website van Delta Lloyd live gegaan. Een voor mij belangwekkende gebeurtenis, aangezien alle client-side code van mijn hand is. Delta Lloyd was een prettige klant om mee samen te werken, omdat ze op alle fronten hoge eisen stelden aan de website. Zo moest de site voldoen aan prioriteit 1 van de W3C richtlijnen en was SEO een belangrijk uitgangspunt.

Mijn HTML-templates valideren altijd als XHTML 1.0 Strict en het is goed om te zien dat – na door de mangel van een CMS gehaald te zijn – het meeste nog overeind staat op de livesite. Er waren wat omgevingsvariabelen die bepaalde zaken (met name formulieren) wat lastiger maakten. Tevens was het jammer dat het visueel design nog aan veranderingen onderhevig was, terwijl ik al lang met de HTML bezig was. De code is inmiddels bijna een jaar oud, en bepaalde zaken zou ik nu zeker anders doen, maar toch ben ik trots op wat er nu staat!

Comments (1)

Betere HTML

Tantek komt met 8 tips voor betere HTML. Weinig nieuws onder de zon, maar als de meester spreekt, dienen wij onze bek te houden. En natuurlijk wel belangrijk om in het oog te houden voor die definitieve gids voor complete HTML (ofzo) die er tezijnertijd toch echt een keer moet komen.

Tags: , ,

Comments (1)

Front-end code reviews

In het Digital Web Magazine spreekt Garrett Dimon over front-end code reviews. Hij heeft helemaal gelijk dat een review op HTML- of CSS-code een ondergeschoven kindje is. Hij vindt dat ook projectteamleden die niet direct met de HTML te maken hebben een review zouden moeten doen en ziet de volgende voordelen van front-end code reviews:

  • Verschillende disciplines binnen één team raken betrokkener bij elkaars werk;
  • Het verhoogt de consistentie van de code;
  • De code wordt beter, omdat meer mensen er een blik op geworpen hebben;
  • Het is een evidente manier om van elkaar te leren.

Vervolgens bespreekt hij een grondige aanpak voor code-reviews, die mijns inziens wat ver gaat, maar zijn punt is gemaakt. Garrett, ik zal er harder aan gaan trekken om dit voor elkaar te krijgen, want ik ben het met je eens dat de volgende drie gevolgen van code reviews erg belangrijk voor kwalitatief betere code: educatie, consistentie en vroegtijdige foutopsporing.

Tags: , , , , ,

Geef een reactie