I started this morning learning something I should have known for ages. I have been coding HTML for well over a decade, and CSS for nearly a decade. I have even taught HTML and CSS both at the University of Bergen and for student groups at Bergen University College.
Of course, that’s no guarantee of how much I actually know about the subject, but I think I have a pretty good knowledge of HTML and CSS. Even then, how position:relative actually works has managed to slip completely under my radar. I find this rather embarrassing, but I write about it here, because if I haven’t managed to get this before now, there is probably several other webdevelopers that also don’t know this (I hope).
The functionality of position:relative is not complicated, it’s actually very simple, you just have to know this.
Read the rest of this entry »
De observante der ute (og som ikke bare leser bloggen min fra rss-leseren sin) kan ha oppdaget at merkelappene på bloggpostene har fått et nytt utseende.
Det begynte egentlig med at jeg så på en post jeg hadde skrevet og tenkte “Hm, de taggene der ser ikke ut som om de egentlig hører hjemme der”. Videre tenkte jeg, hva skal jeg gjøre for å få dem mer inn i det visuelle uttrykket på bloggen. Det hadde vært fint med noen bilder, men da må jeg vedlikeholde en haug med bilder for alle taggene. Det har jeg forsøkt før, da bare for kategoriene, og det er nesten ti ganger så mange tagger som kategoriene.
Hva om jeg kunne lage en bakgrunn som fikk merkelappene til å se mer ut som merkelapper? Vel.. min assosiasjon til merkelapper i denne sammenhengen er slike brune lapper som brukes på postsekker. Jeg kunne alltids lage en bakgrunn som så slik ut, men jeg syntes det ville være rart om de bare gikk rett horisontalt.
Her kommer vi til en av de tingene som jeg har savnet i CSS. En mulighet til å rotere objekter.
Velvel. vi kan jo alltids generere bilder på serveren, og bruke det… Og det var akkurat det jeg endte opp med også. Ikke bare får jeg da generert merkelappene slik jeg vil ha dem, men jeg kan velge den fonten jeg vil ha også, selv om webfonts ikke er støttet i nettleserene enda.
Resultatet er merkelappene nedenfor, og php-koden som genererer dem finner du her
Og her er det jeg brukte for å putte det inn i wordpress-temaet
Foilsett med notater til CSS-foredraget avholdt for Bergen Teknikersamfund 2. Februar 2009 er tilgjengelig her.
Jeg glemte å nevne hvordan en faktisk kobler sammen stilarket og html-dokumentet. En kan enten putte stilarket i head-delen av HTML-dokumentet, inni en <style> blokk.
For eksempel:
<style type="text/css">
a {
text-decoration:none;
color:#FF0000;
}
</style>
Eller, dere kan (helst) ha stilarket i en fil, da refererer dere til stilarket med en tag som denne:
<link rel="stylesheet" type="text/css" href="adresse til stilarket">
Sett inn adressen til stilarket der det står adresse til stilarket.
Til dere som lurte på hvilken editor jeg brukte på mandag: Editoren jeg brukte heter Komodo Edit eller Open Komodo, og er tilgjengelig for Mac, Linux og Windows
Lykke til.
Foilsett med notater til HTML-foredraget avholdt for Bergen Teknikersamfund 19. januar 2009 er tilgjengelig her.
So, you’re going to parse a webpage, to extract some information. For instance if you want to get the tracking information for your last online order, and you want to display the tracking information changes using growl, dbus notifications or xosd.
You know regular expressions, so you go to the job with your long range missiles ready. But wait a minute, you’ll probably solve the problem but is regular expressions really the right tool?
The pro for regular expressions is that you can use the same tool you always use for parsing jobs, but then again you doesn’t learn anything new out of this. You might fortify your position as regex wizard even more, but how about something completely different?
Now. Most webpages is written in HTML, and some even in XHTML, for HTML documents languages like Python has a built-in parser, after the model of the SAX-parser. (It’s probably the other way around, the SAX parser is built on the base of the HTML parser…) Most programming languages has good support for XML, so for XHTML documents, you can use the HTML-parser, a SAX-parser or even the XML-DOM parsers.
The benefit of doing it this way is that your parser will probably be more robust to minor changes in the webpage. You don’t reinvent the wheel (The best way I’ve found to parse HTML documents using regular expressions is to make a specialized SAX-like parser anyway). Your code will probably be readable in a year, and others might even be able to understand your code. And finally, you learn something new, which might give you a fresh view on a lot of problems.
Now back to the original issue, to make a parser for the parcel tracking of your postal service. Here’s an example parsing the shipment tracking page of posten, the norwegian postal service.
Read the rest of this entry »
According to Stuart Herbert, if you use the advanced TinyMCE editor instead of the builtin wysiwyg editor, disable it before upgrading. Its not compatible with 2.5 (yet).
On the other hand, always disable all plugins before upgrading, and enable them one by one afterwards.
And, Bjørge, I will get back to what I did to make WP-upgrading easy soon.
I took a picture of my new laptop the other day. It was then I saw how geeky my bookshelf was, containing these books:
- Web Database Applications with PHP and MySQL
- Learning XML
- Learning XSLT
- Python – how to program
- MySQL reference manual
- Programming Languages – concepts and constructs
- HTML 4.01 Specification
- Conputer Networks
- A history of modern computing
- A brief history of the future – The origins of the Internet
- Learning Java
- Data Structures and Algorithms in Java
- Designing with web standards
- On to Java
- Java network programming and distributed computing
- Windows ME annoyances
- Java som første programmeringsspråk
- Java software solutions
- Learning WML and WMLScript
- Human computer interaction
For de som har lyst til å lese W3C sine spesifikasjoner av HTML, CSS og XHTML finner dere dem her:
Mange undervurderer viktigheten av charset taggen på nettsidene sine. (<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />) De klipper ut denne taggen fra en annen nettside, og limer den inn i sin, for at siden skal validere. Og, ja, den validerer, men feil tegnsett kan føre til at æ, ø og å (++) ikke vises korrekt i andre OS.
Dersom en bruker windows kan det hende at iso-8859-1 kan føre til det samme problemet for brukere av andre OS. Det samme gjelder dersom du skriver siden i UTF-8 men har iso-8859-1 i charset taggen.
Vet du ikke hvilket charset du bruker?
her er en liste over standardcharsets:
- Linux/UNIX bruker vanligvis ISO-8859-1, også kjendt som latin1
- RedHat/Fedora bruker UTF8 som standard, men kan også bruke ISO-8859-1
- Windows bruker et
superset
av latin1, kjendt som CP-1252
- Mac bruker vanligvis MacRoman, som er et
superset
av ASCII, og som ellers ikke har noe med latin1 å gjøre
Siden MacOS X er en Unix, kan det antageligvis bruke ISO-8859-1 eller UTF8 også.
En annen ting er at en del webservere (som Apache 2.x) overstyrer det charset’et du setter i html’en og på den måten griser det til.
Den beste løsningen er å bruke html-entities men det er litt mye arbeid
Mer om tegnsett
RFC’en for UTF8 (RFC3639)