Internes Quicksearch-PlugIn verhagelt HTML5-Validator

[Dr. Love]

Moin,

gerade habe ich mein Template auf den HTML5-Doctype umgestellt und mir direkt einen Error im W3C-Validator eingefangen: Das Title-Attribut ist bei Input-Elementen im aktuellen HTML5-Entwurf nicht mehr erlaubt (und macht auch keinen Sinn). Das interne Quicksearch-Plugin vergibt leider gleich zwei davon (in plugin_internal.inc.php beim Element mit der ID serendipityQuickSearchTermField). Ich habe die bei mir rausgeworfen.

Das wäre vielleicht interessant für die nächste S9Y-Version, ich bin sicher nicht der einzige mit einem HTML5-Template. Nachteile sehe ich dadurch nicht.

Liebe Grüße,
Gregor

[onli]

HTML 5 ist doch noch lange nicht fertig. Ich würde warten, bis das in Blei gegossen ist, bevor irgendwas wegen HTML 5 geändert wird, title-tags in input-Boxen sind an sich nämlich gar nicht so verkehrt (auch wenn meist das Label diese Funktion besser erfüllt). Oder ist das aus einem Abschnitt, der bereits fertig ist?
Gruß

[Dr. Love]

Ja, warten bis das verabschiedet ist, ist eine gute Idee. Die Änderung kann man ja auf eine Liste setzen mit Dingen, die nach der Verabschiedung geprüft und ggf. geändert werden sollten.

[yellowled]

HTML 5 ist doch noch lange nicht fertig.

Was kein Grund ist, es nicht zu verwenden, schon gar nicht, wenn man einfach nur den Doctype verwendet. Grundsätzlich würde ich es derzeit noch nicht für „Produktivseiten“ einsetzen, aber wenn jemand Spielkind ist und etwas ausprobieren möchte ... allerdings sollte man sich nicht zu sehr am Validator aufhängen.

Ich verwende z.B. derzeit auch bereits WAI-ARIA landmark roles, daran meckert selbst der HTML4/XHTML-Validator rum. In dem Fall ist einfach der Vorteil, den der Fortschritt bietet, größer.

YL

[onli]

Klar, sobald der Browsersupport da ist ist es gerade bei einfachen Blogseiten kein Problem, HTML 5 zu verwenden - das wollte ich damit auch nicht ausgedrückt haben

Ich bin selbst am überlegen, mein Template umzustellen, wenn ich Ubuntu auf Lucid aktualisiert habe.

Halte allerdings die Liste für keine doofe Idee, vll sollten wir die im Wiki anlegen.
Gruß

[Dr. Love]

Ja, der Validator ist reine Kosmetik. Aber wenns nichts kostet (die Semantik von Titles für Inputs halte ich für wenig zielführend), ist mir grün lieber als rot. Bei WAI-ARIA zieht man ja einen echten Nutzen raus, dafür kann ich mit rot leben. Am besten wäre natürlich, wenn man den Output des Quicksearch-Plugins einfach im Template überschreiben könnte. Meine mittelfristige Lösung wird sowieso sein, das Ding nicht mehr in der Sidebar zu haben. Also ist das eh im Grunde alles egal.

[yellowled]

Am besten wäre natürlich, wenn man den Output des Quicksearch-Plugins einfach im Template überschreiben könnte.

Völlig überlesen: Kannst Du doch. Du schreibst einfach an die Stelle der index.tpl den Formularcode, wie Du ihn brauchst (mit gewissen Konventionen natürlich, damit es funktioniert) und setzt das Plugin auf „versteckt“.

Ich benutze z.B. in meinem aktuellen Template folgenden Code für das Formular:

Code: Select all

<div id="blog-search">
        <h2>{$CONST.QUICKSEARCH}</h2>

        <form id="search" action="{$serendipityHTTPPath}{$serendipityIndexFile}" method="get" role="search">
            <div><input type="hidden" name="serendipity[action]" value="search" /></div>
            <fieldset>
                <label for="searchterm" class="invisible">{$CONST.QUICKSEARCH} in {$blogTitle}</label>
                <input id="searchterm" type="text" name="serendipity[searchTerm]" value="" />
                <input type="submit" value="{$CONST.QUICKSEARCH}" name="serendipity[searchButton]" />
            </fieldset>
         </form>
         {serendipity_hookPlugin hook="quicksearch_plugin" hookAll="true"}
    </div><!-- /#search -->

Wichtig sind natürlich action und method im form, das hidden field, die name-Attribute der Formularfelder sowie die serendipity_hookPlugin-Zeile.

Alles andere solltest Du relativ frei gestalten können, wie man hier sieht. Sorry, das hatte ich total verdrängt, weil ich mich so auf den HTML5/Validator-Aspekt konzentriert hatte

YL

[onli]

Wenn ich das richtig sehe braucht man das Plugin dann nichtmal, kann es also ganz entfernen.

[Dr. Love]

Mit im Template überschreiben meinte ich, dass der Output von dem PlugIn nicht im Core generiert wird, sondern mit einem Schnipsel im Template, das man leicht überschreiben kann. Dass man das Formular von Hand irgendwo platzieren kann und damit das PlugIn umgehen kann, ist einem ja ungenommen. So werde ich das auch machen. Meine Anregung bezieht sich auf den Fall, dass jemand ein HTML5-Template benutzen möchte und das interne Quicksearch-PlugIn in die Sidebar klatscht. Diese Leute sollten sich keine Errors vom Validator einhandeln müssen, nur weil der Core da ein (in meinen Augen) semantisch nichtssagendes und in HTML5 voraussichtlichlich nicht mehr erlaubtes Attribut reinrendert.

Daraus ergibt sich die allgemeine Frage: Muss der Core überhaupt direkt HTML-Code ausgeben, der sich nicht durch eine Template-Datei ändern lässt? Aber das führt etwas weit.

P.S. Das erinnert mich an die deprecated-Warnungen von PHP 5.3 angesichts von eregi-Funktionen. Klar kann man warten, bis es die egeri-Funktionen gar nicht mehr gibt, so lange die Warnings ignorieren und dann mal schauen. Man kann aber auch etwas Code-Hygiene betreiben und die eregis jetzt in pregs wandeln. Wobei man sich dem Fall ja sogar einen echten (Geschwindigkeits-)Vorteil einfährt, wenn man umstellt. Dafür kostet es auch mehr mühe, als eine Datei zu öffnen und an zwei Stellen ein paar Zeichen zu löschen.

[onli]

Daraus ergibt sich die allgemeine Frage: Muss der Core überhaupt direkt HTML-Code ausgeben, der sich nicht durch eine Template-Datei ändern lässt? Aber das führt etwas weit.

Ist doch eine berechtigte Frage. Argument gegen eine vollständige templatifizierung war die Performance, die darunter wohl leiden würde.
Gruß