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
Internes Quicksearch-PlugIn verhagelt HTML5-Validator
Re: Internes Quicksearch-PlugIn verhagelt HTML5-Validator
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ß
Gruß
Re: Internes Quicksearch-PlugIn verhagelt HTML5-Validator
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.
Re: Internes Quicksearch-PlugIn verhagelt HTML5-Validator
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.onli wrote:HTML 5 ist doch noch lange nicht fertig.
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
Re: Internes Quicksearch-PlugIn verhagelt HTML5-Validator
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ß
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ß
Re: Internes Quicksearch-PlugIn verhagelt HTML5-Validator
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.
Re: Internes Quicksearch-PlugIn verhagelt HTML5-Validator
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“.Dr. Love wrote:Am besten wäre natürlich, wenn man den Output des Quicksearch-Plugins einfach im Template überschreiben könnte.
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 -->
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
Re: Internes Quicksearch-PlugIn verhagelt HTML5-Validator
Wenn ich das richtig sehe braucht man das Plugin dann nichtmal, kann es also ganz entfernen.
Re: Internes Quicksearch-PlugIn verhagelt HTML5-Validator
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.
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.
Re: Internes Quicksearch-PlugIn verhagelt HTML5-Validator
Ist doch eine berechtigte Frage. Argument gegen eine vollständige templatifizierung war die Performance, die darunter wohl leiden würde.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.
Gruß