nicht angemeldet
Hallo Julian,
was meinst du mit "Suchparameter nach Belieben einstellen"? Das, was ich beschreibe, bringt ja nur etwas, wenn Website-Autoren das Metatag auch in ihre Seite einbauen.
Ich beschreibe es dann doch mal besser mit Screenshots (Achtung, alle über 200 KB), das ist einfach anschaulicher. In Omniweb funktioniert es auch ohne ein hypothetisches Meta-Element.
Mal angenommen, ich würde OmniWeb benutzen - tue ich wegen des 12"-Bildschirms nicht - und wollte eine Suchfunktion, die das gesamte Forumsarchiv durchsucht. Ich würde die Seite der SELFHTML Suche aufrufen und die Parameter einstellen, die eine Suche nur im Forumsarchiv braucht:
http://forum.de.selfhtml.org/tim/omniweb-suche-1.png [1]
Hat ein Texteingabefeld den Fokus, zeigt OmniWeb in der Statusleiste ein kleines Icon (Lupe mit Plus-Zeichen). Klicke ich darauf, kann ich diese Suche speichern:
http://forum.de.selfhtml.org/tim/omniweb-suche-2.png
Sofort steht sie im Suchfeld und als Kürzel in der Adresszeile zur Verfügung:
http://forum.de.selfhtml.org/tim/omniweb-suche-3.png
Und natürlich kann man die gespeicherte Suche und ihre Optionen im Nachhinein editieren:
http://forum.de.selfhtml.org/tim/omniweb-suche-4.png
Im Prinzip funktioniert das mit allen Formularen, also auch mit Nicht-Suchen. Anstatt also den langwierigen Weg zu gehen, da einen Wert für ein Meta-Element zu spezifizieren, wird hier die Entscheidung ob sinnvoll zu bookmarken oder nicht auf den Nutzer verlagert. Ich finde das sinnig. Würde ich OmniWeb benutzen, würde ich dieses Feature wahrscheinlich nutzen.
Nebenbei: Ein Meta-Element hielte ich für Dein Feature der bookmarkbaren Suchen für etwas schwierig. Was ist, wenn es zwei Inputfelder auf der Seite gibt? Sinniger wäre da wahrscheinlich ein standardisierter Wert für ein Universalattribut, class="search" oder id="search". Solche Attributewerte zu spezifizieren ist ja derzeit im Trend, wie man bei der Microformats-Initiative sieht.
Eine andere Variante liegt in der Weiterentwicklung von HTML. Apple hat für Dashboard einen eigenen HTML-Dialekt entwickelt. Dabei wurde auch das input-Element um den Attributwert type="search" erweitert und ein paar andere Attribute definiert. Im Dashboard-Kontext hat das Sinn - man bekommt anstatt eines schnöden input-Textfeldes ein in Apples GUI stimmigen Suchfeldes mit zusätzlichen Optionen wie Speichern der Suchanfragen. Dummerweise stellt Safari dies auch dar - mit dem Ergebnis, dass ich nun schon häufiger über die Verwendung von <input type="search"> im WWW gestolpert bin. Praktischerweise wird das Suchfeld dann von anderen Browsern als <input type="text> dargestellt. Das wäre eine sinnige Variante, bookmarkbare Suchfelder zu identifizieren. Allerdings denke ich nicht, dass sich das ausser in Safari im Web ausbreiten wird. WebForms 2.0 spezifiziert nichts in der Richtung, d.h. die WHAT WG Gang wird ihre proprietären Erweiterungen in anderer Richtung ausführen.
In einer ganz anderen, absonderlichereren Zukunft, nämlich in der des W3Cs mit XHTML 2, würde es noch ein anderes Identifikationsmerkmal dafür geben. Wenn ich das recht überblicke, kann man das XHTML 2 Attribut role auch für die in XHTML 2 integrierten XForms 1 Elemente verwenden. Und „search“ ist ein für role vordefinierter Wert. Das heisst, im Prinzip spräche nichts gegen ein solches „leicht identifizierbares“ Formular:
<html:p>
<xforms:input html:role="search">
<xforms:label>Suchterm</xforms:label>
<xforms:help>Geben Sie den Begriff ein, nach dem Sie suchen wollen.</xforms:help>
</xforms:input>
<xforms:submit submission="submit">
<xforms:label>Suchen!</xforms:label>
</xforms:submit>
</html:p>
Allerdings sind dies nur Form Controls, besser im Sinne von XForms sollte man das role Attribute wohl an das Modell des Formulars binden, hier mal ein komplettes XHTML 2 Beispiel:
<?xml version="1.0"?>
<?xml-stylesheet type="text/css" href="http://example.org/style"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN"
"http://www.w3.org/MarkUp/DTD/xhtml2.dtd">
<html:html xmlns:html="http://www.w3.org/2002/06/xhtml2/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/2002/06/xhtml2/
http://www.w3.org/MarkUp/SCHEMA/xhtml2.xsd"
xmlns:xsd="http://www.w3.org/2001/XMLSchema-datatypes"
xmlns:xforms="http://www.w3.org/2002/xforms"
xmlns:search="http://example.org/mysearch"
xml:lang="de">
<html:head>
<html:title>Suche</html:title>
<xforms:model xml:id="suche"
html:role="search">
<xforms:instance>
<search:searchterm/>
</xforms:instance>
<xforms:bind nodeset="/search:searchterm"
type="xsd:nonEmptySearchString"
required="true()"/>
<xsd:schema>
<xsd:simpleType name="nonEmptySearchString">
<xsd:restriction base="xsd:string">
<xsd:minLength value="1"/>
<xsd:maxLength value="50"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
<xforms:submission action="http://example.com/submit"
xml:id="submit"
method="post"
encoding="utf-8"/>
</xforms:model>
</html:head>
<html:body>
<html:h>Suche</html:h>
<html:section>
<html:p>
<xforms:input model="suche"
ref="search:searchterm">
<xforms:label>Suchterm</xforms:label>
<xforms:help>Geben Sie den Begriff ein, nach dem Sie suchen wollen.</xforms:help>
</xforms:input>
<xforms:submit model="suche"
submission="submit">
<xforms:label>Suchen!</xforms:label>
</xforms:submit>
</html:p>
</html:section>
</html:body>
</html:html>
Eigentlich ganz einfach, wenn man es erstmal überblickt. [2] Und im Prinzip könnte man jetzt auch herausfinden, welches Formular in der Seite das Suchformular ist. ;)
Tim
[1] Screenshot zerstören sich in sagenwirmal drei Wochen selbst, schon allein, weil die an einem Ort rumliegen, wo sie nicht liegen sollten, aber liegen müssen, weil ich Zugriffsprobleme auf eigenen Webspace hatte.
[2] Ich gebe zu, ich hab es vielleicht ein winziges bisschen übertrieben und mich hinreissen lassen. Andererseits erfordert Xforms 1 solchen Krempel - mit ein Grund weswegen ich XHTML 2 und dem Wolkenkuckuckskonsortium derzeit etwas kritisch gegenüber stehe. Seid froh, dass ich dann doch keine Lust mehr auf XML Events hatte - man hätte noch wunderbar Fehlermeldungen für dieses Formular im Quelltext unterbringen können, ohne Javascript nutzen zu müssen.