Ich habe stundenlang versucht zu kapieren, warum ich mit der Gallery 3 keine größeren Bilder hochladen konnte. Alle PHP-Einstellungen waren mehr als großzügig, eine Fehlermeldung gab es nicht. Die Lösung war ziemlich simpel.

Allerdings war ein Umweg nötig. Weil ich keine Lust am Debuggen der Gallery 3 mehr hatte, installierte ich Piwigo. Promt hatte ich das gleiche Problem, allerdings diesmal verbunden mit einer 403-Fehlermeldung: "Request entity too large".

Das hat mich dann darin bestätigt, dass wohl mod security das Problem ist. Ich hatte es geahnt, aber immer an den falschen Stellen geschraubt. Die Lösung ist einfach: in apache2.conf muss der Wert für die Direktive SecRequestBodyLimit erhöht werden. Vorgegeben waren 131072 bytes = 128 kb, jetzt sind es 15728640 bytes = 15 MB.

Apache neu starten - und schon geht's.

Für xarPress5 habe ich jetzt das Standard-Theme "Caparica" komplett überarbeitet. Für die Dokumentation fehlt wie immer die Zeit, hier das Wichtigste in Stichworten.

Das Theme basiert auf dem Perfect 3 Column Liquid Layout (Percentage widths) von Matthew James Taylor.

Das Hauptaugenmerk liegt auf einem extrem flexiblen Grundgerüst für ein, zwei und drei-spaltige Layouts, die zusätzlich durch Kopf und Fußbereiche ergänzt werden können. Das Theme kann als Basis nahezu beliebiger grafischer Designs dienen. Es ist durch eine Vielzahl von Variablen konfigurierbar und verwendet dynamisches CSS - theme, skin variables and dynamic CSS.

Struktur

1. Je nachdem welche Blockgruppen aktiv sind, werden automatisch 1, 2 (Inhalt links oder Inhalt rechts) oder 3 Spalten angezeigt.
2. Die Breite aller drei Spalten sowie der Innenabstand (padding) zwischen den Spalten ist konfigurierbar.
3. Wenn drei Spalten genutzt werden, kann als alternativer Skin "Blog-Style" gewählt werden (der Inhaltsbereich ist links, rechts daneben die beiden Spalten für linke und rechte Blöcke)

Anpassung an mobile Endgeräte

1. Durch media queries wird ab einer Seitenbreite unter 768px jedes dreispaltige Layout automatisch in ein zwei-spaltiges Layout verwandelt und bei einer Seitenbreite von weniger als 600px automatisch ein ein-spaltiges Layout verwendet.

Weitere Features

1. Konfigurierbare Seitenbreite, minimale und maximale Seitenbreite
2. Konfigurierbare Hintergrundfarben für alle Spalten
3. Skip-Links (optional)
4. Login-Link (optional)
5. Benutzer- und Admin-Menü im Kopfbereich (superfish/jquery)
6. Benutzermenü frei gestaltbar
7. Admin-Menüleiste (optional)

Allgemeine Features

1. Reset-Stylesheet
2. Alle Basis-Einstellungen sind konfigurierbar (Farben, Schriften, Schriftgrößen, Maßeinheiten, Links).

In Vorbereitung

1. Konfigurierbares Layout (Hintergrundfarben) für rechte und linke Blöcke.
2. Konfigurierbare media queries.

Das hat man davon, wenn man jedes Experiment gleich mitmacht. Gerade habe ich für xarPress5 maschinenlesbaren Inhalt für das time-Element zusammengebastelt, ist es auch schon wieder verschwunden.

Dafür git es jetzt data, was ich konzeptionell in der Tat klüger finde. Und Mikroformate stehen sowieso auf dem Programmm.

The reason the time element has been replaced is that its primary use has been for marking up machine-readable times and dates in Microdata vocabularies, which is a use that has been requested for many other types of data as well (currency, numbers, location). The data element addresses these use cases in a generic fashion and provides yet another hook for scripts to play with.

Roger Johansson hat ein paar Fallen notiert, die man den den Benutzern von Bildschirmvorlesegeräten mit CSS stellen kann.

1. Using display:table on non-table elements to get the visual layout characteristics of an HTML table without actually using one may cause screen readers to act as if there was a real table
2. Using display:block or float on table-related elements may cause screen readers to treat the table as a layout table and ignore its semantics or report an incorrect data structure
3. Using list-style:none to visually remove bullets or numbers from list items may cause screen readers to ignore them too, basically treating list items as paragraphs of text

Vor allem list-style:none dürfte des Öfteren problematisch sein, da so üblicherweise Menüs gestaltet werden.

In xarPress5 haben wir Formulare in allen Modulen nach einem einheitlichen Schema (so genannten Modellen) mit HTML 5 ausgezeichnet. Natürlich sind damit bereits minimale Vorgaben für die Gestaltung gemacht, aber das lässt sich nicht vermeiden.

Alle Templates können außerdem im Theme überrschrieben werden, für die individuelle Gestaltung von Formularen sollte das aber gar nicht notwendig sein.

Generell gehört Layout zu den Aufgaben des Themes. Deswegen werden im Core nur wirklich basale gestalterische Vorgaben gemacht.

Das Stylesheet xarcore-html5.css im Modul base dient vor allem dazu

1. unvermeidliche Probleme zu lösen, um sie nicht in jedem Theme von Neuem angehen zu müssen
2. einige UI-Elemente zu gestalten
3. eine Reihe generischer Standardklassen zu definieren, um sie kontrolliert wiederverwenden zu können

Wir haben das Stylesheet in verschiedene Bereiche unterteilt:

• /* COMMON SYSTEM UI - VENDOR RELATED VALUES */
• /* COMMON SYSTEM UI - NON BEHAVIOUR */
• /* COMMON SYSTEM UI - MESSAGES */
• /* COMMON SYSTEM UI - ELEMENTS */
• /* COMMON SYSTEM UI - GENERIC CLASSES */
• /* COMMON SYSTEM UI - ADDITIONAL CLASSES */
• /* COMMON SYSTEM UI - BEHAVIOUR - JQUERY RELATED CLASSES */
• /* COMMON SYSTEM UI - FORMS */
• /* COMMON SYSTEM UI - IE HACKS */

Die UI-Elemente werden im Core gestaltet, so dass nicht jedes Theme das Rad wieder neu erfinden muss. Auch diese Vorgaben können aber natürlich im Theme überschrieben werden.

Anmerkung: Es kann sein, dass xarcore-html5.css künftig weiter aufgeteilt wird. Theoretisch könnten auch alle gestalterischen Vorgaben an die Themes delegiert werden, so dass in xarcore-html5.css tatsächlich nur die Probleme gelöst werden, die durch die verwendeten HTML5-Modelle entstehen.

Für Gestaltung der Forumlarelemente kann zwischen 4 Stylesheets gewählt werden, mit denen sich jeweils unterschiedliche Positionierungen realisieren lassen:

1. xarcore-html5_forms_center.css
2. xarcore-html5_forms_left_float.css
3. xarcore-html5_forms_left_inline.css
4. xarcore-html5_forms_top.css

Das jeweilige Stylesheet muss im Theme verlinkt werden. Abweichungen vom gewählten Positionierungsmodell können im Stylesheet des Themes vorgenommen werden.

Für das Layout werden vom Core also nur wirklich minimale Voraussetzungen gemacht. Für die weitere Gestaltung sind die Stylesheets des Themes zuständig. Und auch xarcore-html5.css kann im Theme überschieben werden (allerdings müssen dann die Pfade zu Icons angepasst werden).

Standardmäßig sollte die Gestaltung von Formularen (wie auch von Tabellen) in elements.css vorgenommen werden.

xarPress5 1.4 beta ist fertig.

Ein Überblick über den Stand der Entwicklung und neue Features folgt demnächst.

Manchmal sind PDF-Dokumente mit Dokumenteinschränkungen versehen, die dazu führen, dass die Texte nur gedruckt und gelesen werden können und das Kopieren von Text unterbunden wird.

Mit GhostScript können die Schutzeinstellungen der Datei leicht umgangen werden.

Als erstes wird GhostScript installiert und dann die PDF-Datei neu erzeugt. Unter Ubuntu geht das so:

$ sudo apt-get install gs
$ gs -q -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=original.pdf kopie.pdf -c quit

Viele Websites stellen innerhalb von Formularen ausführliche  Hilfsangebote zur Verfügung, auf die mit einem Screenreader allerdings gar nicht zugegriffen werden kann.

Denn im Formularmodus lesen Screenreader wie JAWS nur die für Formulare typischen Elemente wie <fieldset>, <legend>, <label> und natürlich <input>.

Wir haben also dann ein Problem, wenn erläuternde Hilfstexte innerhalb von Formularen vorgelesen werden sollen, die aber nicht im label des zugehörigen Feldes mitgeteilt werden.

xarPress5 - Hilfstexte in Formularen

In xarPress5 (Version 1.4 beta) werden Erläuterungen zur Verwendung von Formularanforderungenw auf drei verschiedene Arten für Screenreader zugänglich gemacht:

1. das title-Attribut des label-Elements wird für kurze Erläuterungen zu einem Eingabefeld genutzt
2. allgemeine und längere Hilfstexte, die sich nicht einem einzelnen Eingabefeld zuordnen lassen, werden aus dem Formular genommen und per aria-describedby assoziiert
3. sind längere Hilfstexte im Formular nicht zu vermeiden, werden diese per aria-describedby mit dem zugehörigen Eingabefeld assoziiert

Hilfstexte innerhalb des Formulars werden innerhalb des betreffenden Formularabschnitts div.xar-form-row in einen Absatz <p></p> geschrieben und mit der Klasse xar-form-text versehen. In der Regel steht der erläuternden Absatz nach dem Eingabefeld.

<div class="xar-form-row">
    <xar:data-input type="checkbox" name="cacheenabled" id="cacheenabled" checked="$CachingEnabled" />
    <label aria-describedby="xar-form-text-cacheenabled" for="cacheenabled" title="#xarML('Stores the output in a cache for low latency/low overhead serving.')#">
        <xar:mlstring>Enable Output Caching?</xar:mlstring>
    </label>
    <xar:if condition="$CachingEnabled ne 1 ">
        <p id="xar-form-text-cacheenabled" class="xar-form-text">
            <xar:mlstring>Output caching is disabled. Config options can be modified, but no output caching will happen until enabled. Warning: when you enable output caching here, it will not be disabled if you deactivate or remove the xarCacheManager module.</xar:mlstring>
        </p>
    </xar:if>
</div>

Manchmal sollen Formularfelder vom Benutzer nicht geändert werden. Das kann dann sinnvoll sein, wenn per JavaScript ermittelte Werte angezeigt oder aber Felder mit einem Wert vorbelegt werden sollen.

Mit den Standalone-Attributen readonly und disabled können Eingabefelder deaktiviert werden. Das Eingabefeld ist dann kein Eingabefeld mehr, sondern eigentlich nur ein Ausgabefeld.

Mit dem Standalone-Attribut readonly wird das Eingabefeld auf nur lesen gesetzt. Anwendbar ist das Attribut auf ein- und mehrzeilige Eingabefelder. Bei readonly bleiben alle Funktionen des Eingabefeldes erhalten. Man kann es per Tabulator-Taste ansteuern, es kann ein accesskey festgelegt werden, der Text kann ausgewählt und kopiert, nur kann der Inhalt nicht verändert werden. Die Daten werden mit dem Formular übertragen. Sinnvoll ist diese Angabe, wenn ein Feldwert zwar übertragen werden soll, und wenn der Anwender den Wert auch sehen, aber nicht ändern können soll.

Mit dem Standalone-Attribut disabled geht im Gegensatz zu readonly gar nichts mehr. Kein tabindex, keine accesskey und die Daten werden auch nicht mit dem Formular übertragen. Erlaubt ist das Attribut in allen Formularfeldtypen. Das Element wird vom Browser in irgendeiner Form blasser dargestellt, um zu signalisieren, dass es nicht bearbeitet werden kann. Sinnvoll ist diese Angabe, wenn ein Feldwert allein zu Informationszwecken dargestellt, aber nicht per Formular übertragen werden soll.

<input type="text" name="blubb" id="first" value="Bla" disabled="disabled" />
<input type="text" name="blubb" id="second" value="More Bla" readonly="readonly" />

Was das Verhalten der Screenreader angeht, ist das Verhalten ziemlich konfus: Screen Reader Support For Disabled & Read Only Form Fields.

Die Kunden sind vom richtigen Kurs abgekommen? Eher schon wurde bei Nokia versäumt, dafür Sorge zu tragen, dass nicht länger gültige Adressen auch weiterhin noch zum Ziel führen.

Statt sozu tun, als sei der Kunde der Dumme, könnten entweder vernünftige Fehlermeldungen oder noch besser: sinnvolle Weiterleitungen geschaltet werden.

So far, we have rewritten over 1000 Xaraya/Xarigami templates and style sheets with focus on standardization and accessibility.

Standardization

• CSS standardization
• HTML5 standardization

Restructuring

• restructured page elements (page, modules, menus, navigation, block groups, blocks)
• restructured html elements (forms, tables)
• redefined purpose of base style sheets
• restructured anatomy of a module (module body and header)
• new default theme (xarpress5)
• new base style sheet (xarcore-html5.css)
• more module and block style sheets

Cleaning

• removed redundant title attributes
• removed accesskeys (no need for them)
• removed size attributes (deprecated)
• removed hard coded styles
• removed xaraya pseudo classes (nothing but hard coded styles)
• removed all inline floating/clearing

Focus on Accessiblity

• moved text messages out of form
• added Aria roles, states, and properties

Eine kurze und knappe Beschreibung der Roadmap zu xarPress5.

Description

With xarPress5 we're starting a project to make Xaraya/Xarigami fit our needs regarding (X)HTML templates and style sheets. We're going go rewrite all core and some module templates and define a new set of base CSS classes.

Objective

Make Xaraya/Xarigami fit our needs in respect of

• themability
• accessibility

Standards

• HTML5
• CSS 2.1/CSS 3
• WAI–ARIA 1.0
• WCAG 2.0

Steps

Renaming project.

Some steps to take ... written in non-chronological order.

I. Research

• research CSS
• research (X)HTML template files
• status quo and critical points

Done

II. Cleaning

• fix css
• clean unused css
• make all pages valid xhtml 1.0 strict

Canceled

III. Sketching

• write example layout models (tables, forms)
• write example layout structures (page, block, module, menu, overview)
• list new classes in base.css

IV Preparation

• register xarPress5
• add html doctype to blocklayout.xsl (feature request)
• add xarcore-html5.css

V. Testing

• build page layout skeleton based on models
• add base and role templates to xarPress use override templates for testing some new ideas
• test all base DD properties
• define browser support (HTML5)
• define browser support (CSS)

VI. Building (Core)

• rewrite core templates - in progress
• write new base.css - in progress (99%)

VII. Building (Extensions)

• rewrite xarPress templates
• if necessary add further classes to base.css

VIII. Theming & Styling

• build admin theme based on xarPress5
• port some other themes

IX. Microformats

• Some thoughts about Microdata and Microformats, better not too late ...

X. Backport to XHTMLO 1.0 strict

• search & replace to make templates valid XHTMLO 1.0 strict
• change doctype

XI. Documentation

• add some infos and docs

Appendix A

List of Core Modules

Appendix B

List of xarPress Modules

Kurzer Beschluss einer langen Diskussion: ich gehe davon aus, dass HTML5 (für einige Zeit) die Zukunft gehören wird.

Die für mich ausschlaggebenden Argumente:

• die offensichtlich vorhandene Aufmerksamkeit, die mehr als heiße Luft ist
• die (im Gegensatz zu anderen Arbeitsgruppen) sehr aktive WHATWG
• die Unterstützung der Browser-Hersteller (inkl. Microsoft)
• Geld und infrastrukturelle Hegemonie (Google)
• ein in großen Teilen, auch durch die Integration von Web Forms 2.0, sinnvolles Konzept

Und, ja, ich schreibe auch lieber XHTML, aber was soll's.

Warum das nichts wird mit Alternativen zu HTML5, ist in dieser kurzen Bemerkung zusammengefasst:

Bei der XHTML2-Kindergarten -Arbeitsgruppe werden hingegen vier Entwürfe zurückgezogen, weil in der vorangegangenen Phase der Publizierung bestehende Einwände gegen die Entwürfe nicht beachtet wurden. Im einzelnen sind dies: XHTML™ 1.1 - Module-based XHTML - Second Edition, XHTML™ Basic 1.1 - Second Edition, XHTML-Print - Second Edition sowie XHTML 1.0. Hintergründe zu dieser Entscheidung kann man evtl. in dieser E-Mail von Bjoern Hoehrmann an die W3C-Mailingliste nachlesen.

Lesesnwert vor allem die Mail von Bjoern Hoehrmann.

.

Wenn man bei der Installation von Drupal 6 die folgende Fehlermeldung bekommt, dann wurde die Datei default.settings.php nicht nach settings.php kopiert, sondern einfach umbenannt. Es müssen also beide Dateien, default.settings.php und settings.php, vorhanden sein, damit die Installation weitergehen kann.

Warning: fopen(./sites/default/default.settings.php) [function.fopen]: failed to open stream: No such file or directory in /home/karsten/www/drupal/drupal-6.11/includes/install.inc on line 188
Warning: Cannot modify header information - headers already sent by (output started at /home/karsten/www/drupal/drupal-6.11/includes/install.inc:188) in /home/karsten/www/drupal/drupal-6.11/includes/install.inc on line 618
Warning: Cannot modify header information - headers already sent by (output started at /home/karsten/www/drupal/drupal-6.11/includes/install.inc:188) in /home/karsten/www/drupal/drupal-6.11/includes/install.inc on line 619 6)

Das Web spricht in Zukunft HTML5 - mittlerweile kann man darauf wetten. Eine (noch) unsortierte Liste mit Links zu Referenzen, Darstellungen, Einführungen, Artikeln und Einwürfen zu HTML5.

Bruce Lawson: Marking up a blog with HTML 5 (part 2)

Bruce Lawson beschreibt ausführlich, wie ein Blog mit HTML5 gestaltet wird.

Bruce Lawson: Redesigning with HTML 5 and WAI-ARIA

Layout mit HTML5, vor allem strukturelle Elemente werden besprochen. Außer neue Formularattribute.

Tobias Otte: Semantik in HTML 5

Dieser Artikel ist eine freie Übersetzung von Semantics in HTML 5, geschrieben im Januar 2009 von John Allsopp für A List Apart.

Google Code: webforms2

A cross-browser implementation of the WHATWG Web Forms 2.0 specification. This specification is currently a mature working draft and has been adopted by the W3C HTML Working Group to serve as a starting point for the next version of HTML. This implementation will follow the HTML 5 specification that evolves from the W3C process.

CMSBlog: HTML 5 Ein kleiner Einstieg in HTML 5

Einführung und vergleiche mit HTML4 und XHTML.

New elements in HTML 5

Ausführliche Erläuterungen neuer Elemente.

ReadWriteWeb: 5 Exciting Things to Look Forward to in HTML 5

Ausführliche Darstellung neuer Elemente.

Opera Developer Community: Improve your forms using HTML5!

Formulare mit HTML5 gestalten. Neue Elemente, Validierung und CSS.

ARIA in HTML5 Integration: Document Conformance (Draft, Take Two)

Integration von ARIA in HTML5.

456 Berea Street: Another look at HTML 5

Kritischer Artikel und Empfehlungen zut HTML5.

WHATWG Wiki: FAQ

FAQ der Web Hypertext Application Technology Working Group.

WHATWG Wiki: Implementations in Web browsers

Welche Browser unterstützen welche Elemente aus HTML5 und Web Forms 2.0?

Bruce Lawson: HTML 5 elements test

Knappe Anmerkungen zur Browser-Unterstützung von HTML5.

HTML 5 Reference

Referenz.

I’m Mike: XHTML 2 vs. HTML 5

Despite its late start, the HTML 5 working group seems to have more industry support, and is further along in the recommendation process. Their goal is to have a complete spec, with multiple interoperable implementations, by late 2010 (as I said before, though, the W3C has already missed some milestones in the approval process). With industry support from most of the major browser vendors (the only notable exception being Microsoft) it’s likely that this specification will be implemented quickly and consistently once it’s reached a stable state.

Nimbupani Designs: The Long Road from XHTML to HTML

Description of what is available with HTML 5, and discusses the issues/problems of using XHTML 2. Here is the answer to the ultimate question of HTML 5 vs XHTML 2, which will win?

(X)HTML 5 und XHTML 2 im Vergleich – Übersetzung von Jens Meiert

Deutsche Fassung von "X/HTML 5 Versus XHTML 2".

Interview with Ian Hickson, editor of the HTML 5 specification

Interview with Ian Hickson.

HTML 5 Reference

Referenz für Autoren.

A List Apart: A Preview of HTML 5

Artikel über neue Elemente, Vor- und Nachteile werden kurz angerissen.

Test new HTML 5 elements

Live neue Elemente testen.

12 resources for getting a jump on HTML 5

Kommentierte Linksammlung.

Boblet: HTML5 id/class name cheatsheet

The mapping of HTML5 structural elements to id and class names for use with <div>s.

Bruce Lawson: Accessibility of HTML 5 video and audio elements

Accessibility of HTML 5 video and audio elements.

Preparing for HTML5 with Semantic Class Names

Preparing for HTML5 with Semantic Class Names.

For A Beautiful Web: More on developing naming conventions, Microformats and HTML5

Developing naming conventions, Microformats and HTML5.

HTML 5: The Markup Language

This specification describes the fifth major version of the HTML vocabulary. It provides the details necessary for producers of HTML content to create conformant documents. By design, it does not define related APIs nor attempt to specify how consumers of HTML content are meant to process documents.

Validator.nu

Validiert HTML5.

HTML5 enabling script

Skript um HTML5-Elemente zu aktivieren.

A-Tag '08: Die Zukunft ist heute

Site in HTML5.

Adactio: Journal—The Rise of HTML5

Re-Design mit HTML5.

Eric Meyer: An Event Apart and HTML 5

Über das Re-design von An Event Apart mit HTML5.

An Event Apart: The Design Conference For People Who Make Web Sites

Site in HTML5.

Jeffrey Zeldman: An Event Apart redesigned

Über das Re-design von An Event Apart mit HTML5.

yatil: Das HTML5-Jahr

Knappes Statement.

HTML5 - Was geht heute schon, was geht nicht? Der große Überblick.

Was geht schon in HTML5? An sich spricht nichts gegen den Einsatz von HTML5 in Websites von heute. Man muss nur sehen, wie viel HTML5 man einsetzt.

Jens Meiert: Yes, You Can Use HTML 5

Meiert gibt den Startschuss. I hope that this adds to the overall excitement about HTML 5, and that it helps consoling for the expected 2010 release date of the final specification, anticipating additional years for it to be broadly implemented: Yes, we can!

Why the Alt Attribute May Be Omitted

Zur Diskussion um das alt-Attribut.

Robert Nyman: Thoughts on HTML 5

Kritischer Artikel.

HTML 5 and accessibility

Juicy Studio: The HTML Scope/Headers Debate

Tabellen in HTML5.

The WHATWG Blog: How HTML5 can be used today

Fragen und Antworten zu HTML5.

The Slow Erosion of XHTML

Kritische Diagnose.

456 Berea Street: Help keep accessibility and semantics in HTML

Kritischer Einwurf - Zugänglichkeit und Semantik mit HTML5 bewahren.

HTML 5: eine Verneigung vor allen Unwägbarkeiten und Problemstellen

456 Berea Street startet einen Hilferuf zur Aufrechterhaltung von Barrierefreiheit und Semantik in HTML.

An Overview of HTML 5

Genaue Einführung un Überblick.

Webstandardblog - HTML5 vs. oder feat. XHTML2.0

Diskussion zu HTML5 und XHTML2.0

X/HTML 5 Versus XHTML 2

Ausführliche Darstellung. he competition to become the next markup language for the Web is heating up. This article takes a look at what's cool and what's uncool about the competing technologies. Deutsche Fassung s. Meiert.

Conversation With X/HTML 5 Team

Ausführliches Gespräch mit Ian Hickson. Viele Details.

The WHATWG Forums

Forum der WHATWG.

The WHATWG Blog

BLOG der WHATWG.

HTML5 Elements and Attributes

Element- und Attributreferenz.

In den nächsten Tagen werde ich diese Seite vollständig umbauen. Es hat sich gezeigt, dass die aktuelle Struktur nicht flexibel genug ist, um schnell und effektiv publizieren zu können; und das Layout ist nicht sonderlich gut geeignet, um umfangreichere Texte lesbar darzustellen.

(Und, ehrlich gesagt, die Kategorisierung der Inhalte war ein Schuss in Knie.)

Vor allem habe ich keine Lust mehr, meine Aktivitäten auf zwei, drei Seiten zu verteilen, die Trennung in technische und, sagen wir, kulturelle Notizen ist mir einfach (zu blöd und) umständlich - und sie ist auch falsch, da diese Trennung auch in professioneller Hinsicht schlicht nicht stimmt und die aktuelle Seite nie gedacht war als rein berufliche Plattform. Ich werde deswegen versuchen, soviel wie möglich (einige Datenbankakrobatik vorausgesetzt) unter dem neuen Dach zusammenzufassen.

Auch die URI wird sich (vermutlich) ändern - die virtuelle Präsenz wird mit der realen synchronisiert. (Die Abteilung "Support" wird aber auf jeden Fall weiter über die gegenwärtige Adresse erreichbar sein.

Eigentlich wollte ich nur ein solides Theme für die Administration erstellten, dann ist aber doch ein vollständiges Theme entstanden, das mit Xaraya oder Xarigami verwendet werden kann.

Da ich Xarayas Stylesheets für aufgeblasen und konzeptionell nicht wirklich geglückt halte, habe ich probiert, wie weit man ohne die internen Standardklassen kommt - und siehe da, die meisten Klasssen werden nicht benötigt, um ein vernünftiges Layout zu gestalten.

Das Theme kann auf xarPress angeschaut und ausprobiert werden. Zum Download wird es freigegeben, wenn ich mit dem Umzug dieser Seite hier fertig bin.

Eine Liste mit den Bugs.

Eine Liste der Macken, die man nicht unbedingt Bugs nennen muss, die sich aber bei der Arbeit als störend erweisen.

• nested input-wrapper
• no reason to make xar-block-[ ] required classes