Relative Pfadangaben sind relativ. Die Frage ist: Relativ zu????

Die Antwort: Relativ zum URI des Dokuments, in welchem sich die relative Pfadangabe befindet (href=, action=...)

Wenn Du dafür sorgst, dass diese Beziehung hergestellt werden kann, ist gegen relative Pfadangaben nichts einzuwenden.

Es ist jedoch nicht immer möglich, mit relativen Pfadangaben zu arbeiten, nämlich dann, wenn der Request_URI in einem virtuellen Pfad liegt, wie z.B. in /cgi-bin/ oder in virtuellen Pfaden, die mit dem Dateisystem überhaupt nichts mehr zu tun haben.

Zum /cgi-bin/: Der Webserver ist i.d.R. so konfiguriert, dass er Dateien in diesem Pfad ausführen möchte. Eine css-Datei ist nicht ausführbar, ein Request auf /cgi-bin/foo.css würde eine Fehlermeldung erzeugen (404 Not Found oder 500 Internal Server Error), welche das ist hängt von der Konfiguration des Webservers ab.

Wegen dieser Probleme ist es empfehlenswert, Pfadangaben zu verwenden, die dem virtuellen Serverpfad entsprechen. Das wäre dann konkret der "/" für die Dokument-Root, wobei:

Ein URI besteht aus:
($scheme, $auth, $path, $query_string, $fragment)

Von links nach rechts:
Scheme: http:///
Auth: example.com
Path: /foo beginnt stets mit einem Slash
Query_String: beginnt nach dem Fragezeichen
Fragment: beginnt mit dem '#" Zeichen

Summa: Scheme und Auth sind nur zu notieren, wenn diese abweichend sind vom Request-URI zum href= oder action= ... innerhalb des Request_URI

Ansonsten genügt eine Pfadangabe, die mit einem Slash beginnt, die funktioniert immer und braucht keinen Pflegeaufwand, wenn sich mal was ändern sollte (was oft genug der Fall ist).