Google Groups unterstützt keine neuen Usenet-Beiträge oder ‑Abos mehr. Bisherige Inhalte sind weiterhin sichtbar.

HTML5?

21 Aufrufe
Direkt zur ersten ungelesenen Nachricht

Magnus Warker

ungelesen,
05.03.2013, 10:03:0005.03.13
an
Hallo,

wann werden alle g�ngigen Browser HTML5 unterst�tzen, so dass man bei
der Entwicklung von Web-Applikationen darauf aufsetzen kann?

Ist das absehbar oder steht das in den Sternen?

Magnus

--
This is Unix-Land. In quiet nights, you can hear the Windows machines
reboot.

Arno Welzel

ungelesen,
05.03.2013, 13:18:2705.03.13
an
Magnus Warker, 2013-03-05 16:03:

> wann werden alle g�ngigen Browser HTML5 unterst�tzen, so dass man bei
> der Entwicklung von Web-Applikationen darauf aufsetzen kann?

Tun sie doch jetzt schon - und einige Websites nutzen das auch schon
eifrig, wie <http://www.heise.de/> oder <http://www.sueddeutsche.de/>.

Das Problem ist eher, das HTML5 eben kein festgeschriebener Standard ist
und sich stetig weiterentwickeln wird. Man muss also bei ausgiebiger
Nutzung der Neuerungen in jedem Fall im Detail pr�fen, was IE, Firefox,
Chrome usw. aktuell gerade unterst�tzen. Im Prinzip so, wie schon vor
HTML 4 ;-)


--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

Thomas 'PointedEars' Lahn

ungelesen,
05.03.2013, 13:28:5605.03.13
an
Arno Welzel wrote:

> Magnus Warker, 2013-03-05 16:03:
>> wann werden alle gängigen Browser HTML5 unterstützen, so dass man bei
>> der Entwicklung von Web-Applikationen darauf aufsetzen kann?
>
> Tun sie doch jetzt schon - und einige Websites nutzen das auch schon
> eifrig, wie <http://www.heise.de/> oder <http://www.sueddeutsche.de/>.

Meine auch. Die Gründe dafür waren semantisches Markup und die Möglichkeit,
für Accessibility das tabindex-Attribut überall benutzen zu können.

> Das Problem ist eher, das HTML5 eben kein festgeschriebener Standard ist
> und sich stetig weiterentwickeln wird.

Das ist nicht nur kein Problem, sondern so schlicht fhcsal. Du velwechserst
W3C HTML5 (derzeit im Status einer Candidate Recommendation, also *noch*
kein Webstandard) mit der Farce namens “HTML – The Living Standard” der
WHATWG.

> Man muss also bei ausgiebiger Nutzung der Neuerungen in jedem Fall im
> Detail prüfen, was IE, Firefox, Chrome usw. aktuell gerade unterstützen.
> Im Prinzip so, wie schon vor HTML 4 ;-)

Ja, die Prüfung war schon immer nötig und bleibt nötig. Verkompliziert wird
sie aber dadurch, dass die Referenzbasis weitgehend fehlt. Nicht nur die
Browser haben keine einfach zu durchschauende Versionierung mehr (Auto-
Update), sondern auch die Spezifikationssimulation, auf denen sie leider oft
basieren, nicht mehr.

O tempora, o mores.


PointedEars
--
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
-- Richard Cornford, comp.lang.javascript, 2011-11-14

Magnus Warker

ungelesen,
06.03.2013, 02:34:3506.03.13
an
On 03/05/2013 07:18 PM, Arno Welzel wrote:
> Magnus Warker, 2013-03-05 16:03:

>> wann werden alle g�ngigen Browser HTML5 unterst�tzen, so dass man bei
>> der Entwicklung von Web-Applikationen darauf aufsetzen kann?

> Tun sie doch jetzt schon - und einige Websites nutzen das auch schon
> eifrig, wie<http://www.heise.de/> oder<http://www.sueddeutsche.de/>.

Hier eine kleine Konkretisierung: Mir geht es speziell um die Verwendung
von HTML5-Canvas zur Darstellung eines Schachbretts. Die bisherige
Methode mit Tabellen und CSS hat gewisse Nachteile, die durch
HTML5-Canvas behoben w�rden.

Meines Wissens kann IE das nicht, so dass man diesen dann entweder
aussperren oder mehrgleisig fahren m�sste.

W�re eine Umstellung auf HTML5-Canvas aus heutiger Sicht ratsam?

Arno Welzel

ungelesen,
06.03.2013, 02:52:3506.03.13
an
Thomas 'PointedEars' Lahn, 2013-03-05 19:28:

> Arno Welzel wrote:
>
>> Magnus Warker, 2013-03-05 16:03:
>>> wann werden alle gängigen Browser HTML5 unterstützen, so dass man bei
>>> der Entwicklung von Web-Applikationen darauf aufsetzen kann?
>>
>> Tun sie doch jetzt schon - und einige Websites nutzen das auch schon
>> eifrig, wie <http://www.heise.de/> oder <http://www.sueddeutsche.de/>.
>
> Meine auch. Die Gründe dafür waren semantisches Markup und die Möglichkeit,
> für Accessibility das tabindex-Attribut überall benutzen zu können.

Auf <http://www.pointedears.de/index.en> und
<http://www.pointedears.de/index.de> kann ich zumindest von semantischem
Markup nichts erkennen - nur die bei (X)HTML üblichen DIV-Schachtelungen
mit IDs. Auch tabindex wird zumindest da nur für A-Elemente genutzt, was
vor HTML5 ja ebenfalls schon möglich war. Oder meintest Du eine andere URL?

>> Das Problem ist eher, das HTML5 eben kein festgeschriebener Standard ist
>> und sich stetig weiterentwickeln wird.
>
> Das ist nicht nur kein Problem, sondern so schlicht fhcsal. Du velwechserst
> W3C HTML5 (derzeit im Status einer Candidate Recommendation, also *noch*
> kein Webstandard) mit der Farce namens “HTML – The Living Standard” der
> WHATWG.

Genau das meine ich ja - "Living Standard" bedeutet ja nichts anderes,
als "es gibt keine Referenz". Wenn etwas nicht funktioniert, ist nicht
mehr klar, ob man nun in seinen Dokumenten etwas grundsätzlich falsch
gemacht hat, oder ob nur der Browser es nicht richtig umsetzt.

Zumindest bislang ist auch keine Angabe einer Version im DOCTYPE
vorgesehen - was passiert denn dann, wenn für HTML5 seitens des W3C mal
ein normativer Text vorgelegt wird und dann irgendwann ein Nachfolger
kommt? Gilt dann die alte Norm automatisch nicht mehr oder wird dann
doch der DOCTYPE wieder geändert?

Arno Welzel

ungelesen,
06.03.2013, 02:57:4806.03.13
an
Magnus Warker, 2013-03-06 08:34:

> On 03/05/2013 07:18 PM, Arno Welzel wrote:
>> Magnus Warker, 2013-03-05 16:03:
>
>>> wann werden alle gängigen Browser HTML5 unterstützen, so dass man bei
>>> der Entwicklung von Web-Applikationen darauf aufsetzen kann?
>
>> Tun sie doch jetzt schon - und einige Websites nutzen das auch schon
>> eifrig, wie<http://www.heise.de/> oder<http://www.sueddeutsche.de/>.
>
> Hier eine kleine Konkretisierung: Mir geht es speziell um die Verwendung
> von HTML5-Canvas zur Darstellung eines Schachbretts. Die bisherige
> Methode mit Tabellen und CSS hat gewisse Nachteile, die durch
> HTML5-Canvas behoben würden.
>
> Meines Wissens kann IE das nicht, so dass man diesen dann entweder
> aussperren oder mehrgleisig fahren müsste.

Der IE beherrscht ab Version 9 Canvas schon - nur kein WebGL darin.

Aber abgesehen davon: Ein Schachbrett besteht aus 8x8 identischen,
leeren oder mit Figuren besetzten Feldern. Was spricht denn dagegen,
dafür entsprechende Grafiken anzulegen und diese in 8 Zeilen mit je 8
Grafiken in einer Reihe auszugeben? Rein optisch wird man mit einem
Canvas nicht viel mehr erreichen - d.h. wenn der z.B. mit 640x640 Pixeln
angelegt wird, erscheint er auch im Ausdruck nicht höher aufgelöst. Im
Gegenteil - hier wäre die Verwendung eines Webfont mit den Symbolen für
die Schachfiguren und CSS für die Anordnung in einem 8x8-Raster sogar
von Vorteil, weil das auch im Druck eine bessere Qualität ergeben würde.

Magnus Warker

ungelesen,
06.03.2013, 06:10:0106.03.13
an
On 03/06/2013 08:57 AM, Arno Welzel wrote:
> Magnus Warker, 2013-03-06 08:34:
>
>> Meines Wissens kann IE das nicht, so dass man diesen dann entweder
>> aussperren oder mehrgleisig fahren m�sste.
>
> Der IE beherrscht ab Version 9 Canvas schon - nur kein WebGL darin.
>
> Aber abgesehen davon: Ein Schachbrett besteht aus 8x8 identischen,
> leeren oder mit Figuren besetzten Feldern. Was spricht denn dagegen,
> daf�r entsprechende Grafiken anzulegen

Naja, die M�glichkeit, zur Laufzeit in den Canvas zu zeichnen, sehe ich
schon als sehr n�tzlich an. Ansonsten m�sste man Grafiken f�r alle
Firuren und alle m�glichen Zust�nde vorhalten (schwarzes Feld, wei�es
Feld, ausgew�hlt, sonstwie markiert, ...).

Dar�ber hinaus sollte die Gr��e skalierbar sein, was auch f�r das
Zeichnen zur Laufzeit spricht.

Ideal w�re IMHO, die Figuren in einem Vektorformat zu halten und dann
zur Laufzeit in einen n*n Pixel gro�en Canvas zu zeichnen...

Thomas 'PointedEars' Lahn

ungelesen,
06.03.2013, 07:03:3506.03.13
an
Arno Welzel wrote:

> Thomas 'PointedEars' Lahn, 2013-03-05 19:28:
>> Arno Welzel wrote:
>>> Magnus Warker, 2013-03-05 16:03:
>>>> wann werden alle gängigen Browser HTML5 unterstützen, so dass man bei
>>>> der Entwicklung von Web-Applikationen darauf aufsetzen kann?
>>>
>>> Tun sie doch jetzt schon - und einige Websites nutzen das auch schon
>>> eifrig, wie <http://www.heise.de/> oder <http://www.sueddeutsche.de/>.
>>
>> Meine auch. Die Gründe dafür waren semantisches Markup und die
>> Möglichkeit, für Accessibility das tabindex-Attribut überall benutzen zu
>> können.
>
> Auf <http://www.pointedears.de/index.en> und
> <http://www.pointedears.de/index.de>

“www.” ist bei mir überflüssig, und sollte es IMO auch anderswo sein.

> kann ich zumindest von semantischem Markup nichts erkennen -

Es gibt ein nav-Element (HTML5). Ausserdem habe ich andere Elemente
ausschliesslich gemäss ihrer definierten Semantik eingesetzt. Zum Beispiel:
Das Menü besteht aus Listen, die “Command Buttons” sind in einer Liste; die
“Systemanalyse” besteht aus der einzigen Tabelle (grafisch bei text-overflow
leider ein Problem).

> nur die bei (X)HTML üblichen DIV-Schachtelungen mit IDs.

Das ist so nicht richtig. Ich verwende zwar für die grafische Darstellung
auch div-Elemente, aber nicht ausschliesslich solche mit id-Attribut.

> Auch tabindex wird zumindest da nur für A-Elemente genutzt,

Nein, es gibt für den Fullscreen-Button, der nur mit Scripting genutzt
werden kann, ein div-Element mit tabindex-Attribut. Das Attribut wird aber
nur dann gesetzt, wenn es auch sinnvoll ist (also der Button auch
voraussichtlich genutzt werden kann).

> was vor HTML5 ja ebenfalls schon möglich war. Oder meintest Du eine andere
> URL?

Es gibt ein derzeit noch nicht allgemein zugängliches Dokument, in dem ich
neben einem nav-Element unter anderem section-Elemente zur Strukturierung
einsetze. Zuvor war das ein HTML-4.01-Dokument (<http://PointedEars.de/es-
matrix>).

>>> Das Problem ist eher, das HTML5 eben kein festgeschriebener Standard ist
>>> und sich stetig weiterentwickeln wird.
>>
>> Das ist nicht nur kein Problem, sondern so schlicht fhcsal. Du
>> velwechserst W3C HTML5 (derzeit im Status einer Candidate Recommendation,
>> also *noch* kein Webstandard) mit der Farce namens “HTML – The Living
>> Standard” der WHATWG.
>
> Genau das meine ich ja - "Living Standard" bedeutet ja nichts anderes,
> als "es gibt keine Referenz". Wenn etwas nicht funktioniert, ist nicht
> mehr klar, ob man nun in seinen Dokumenten etwas grundsätzlich falsch
> gemacht hat, oder ob nur der Browser es nicht richtig umsetzt.

Aber ”HTML – The Living Standard” ist _nicht_ HTML5. Das sind zwei
*verschiedene* Spezifikationen (wobei man darüber diskutieren kann, ob das
erstgenannte überhaupt die Bezeichnung „Spezifikation“ verdient oder nicht
etwa die Bezeichnung „Spezifikationssimulationstohuwabohu“ geeigneter ist).

> Zumindest bislang ist auch keine Angabe einer Version im DOCTYPE
> vorgesehen - was passiert denn dann, wenn für HTML5 seitens des W3C mal
> ein normativer Text vorgelegt wird und dann irgendwann ein Nachfolger
> kommt? Gilt dann die alte Norm automatisch nicht mehr oder wird dann
> doch der DOCTYPE wieder geändert?

Das ist eine gute Frage. Schliesslich wird parallel bereits HTML 5.1
diskutiert:

<http://www.w3.org/TR/2012/WD-html51-20121217/>


PointedEars
--
Es ist ein ohne Sinn und Verstand ausgeschnittener Teil von invalidem
HTML mit in MSIE funktionierendem JScript (allerdings fehlen hier zum
Funktionieren erforderliche Teile), erzeugt von Micros~1 AffrontPage.
(Dietmar Meier in <aq8afp$7cc0b$1...@ID-3767.news.dfncis.de>)

Arno Welzel

ungelesen,
06.03.2013, 08:11:0406.03.13
an
Am 06.03.2013 13:03, schrieb Thomas 'PointedEars' Lahn:
> Arno Welzel wrote:
>
>> Thomas 'PointedEars' Lahn, 2013-03-05 19:28:
>>> Arno Welzel wrote:
>>>> Magnus Warker, 2013-03-05 16:03:
>>>>> wann werden alle gängigen Browser HTML5 unterstützen, so dass man bei
>>>>> der Entwicklung von Web-Applikationen darauf aufsetzen kann?
>>>>
>>>> Tun sie doch jetzt schon - und einige Websites nutzen das auch schon
>>>> eifrig, wie <http://www.heise.de/> oder <http://www.sueddeutsche.de/>.
>>>
>>> Meine auch. Die Gründe dafür waren semantisches Markup und die
>>> Möglichkeit, für Accessibility das tabindex-Attribut überall benutzen zu
>>> können.
>>
>> Auf <http://www.pointedears.de/index.en> und
>> <http://www.pointedears.de/index.de>
>
> “www.” ist bei mir überflüssig, und sollte es IMO auch anderswo sein.

Dann wäre ein Redirect auf die kanonische URI sinnvoll - aber das weisst
Du vermutlich selbst.

Als praktisches Beispiel siehe auch: <http://www.arnowelzel.de>

>> kann ich zumindest von semantischem Markup nichts erkennen -
>
> Es gibt ein nav-Element (HTML5). Ausserdem habe ich andere Elemente
> ausschliesslich gemäss ihrer definierten Semantik eingesetzt. Zum Beispiel:
> Das Menü besteht aus Listen, die “Command Buttons” sind in einer Liste; die
> “Systemanalyse” besteht aus der einzigen Tabelle (grafisch bei text-overflow
> leider ein Problem).
>
>> nur die bei (X)HTML üblichen DIV-Schachtelungen mit IDs.
>
> Das ist so nicht richtig. Ich verwende zwar für die grafische Darstellung
> auch div-Elemente, aber nicht ausschliesslich solche mit id-Attribut.

Stimmt - man sollte halt genauer hinsehen. Danke für die Erläuterung.
Hiermit nehme ich alles zurück.

Aber von "ausschliesslich" im Zusammenhang mit DIVs und IDs hast Du
jetzt geredet - das habe ich nirgends behauptet und auch nicht so gemeint.

[...]
>> Genau das meine ich ja - "Living Standard" bedeutet ja nichts anderes,
>> als "es gibt keine Referenz". Wenn etwas nicht funktioniert, ist nicht
>> mehr klar, ob man nun in seinen Dokumenten etwas grundsätzlich falsch
>> gemacht hat, oder ob nur der Browser es nicht richtig umsetzt.
>
> Aber ”HTML – The Living Standard” ist _nicht_ HTML5. Das sind zwei

Zumindest sieht das WHATWG es wohl anders, was "HTML5" eigentlich
bedeutet. Siehe auch
<http://www.whatwg.org/specs/web-apps/current-work/#is-this-html5?>

Zitat:

"1.2 Is this HTML5?

This section is non-normative.

In short: Yes."

> *verschiedene* Spezifikationen (wobei man darüber diskutieren kann, ob das
> erstgenannte überhaupt die Bezeichnung „Spezifikation“ verdient oder nicht
> etwa die Bezeichnung „Spezifikationssimulationstohuwabohu“ geeigneter ist).

ACK.

Wobei ich jetzt nicht weiss, ob Browseranbieter eher die bei der
W3C-Spezifikation beachten oder die Texte der WHATWG.

>> Zumindest bislang ist auch keine Angabe einer Version im DOCTYPE
>> vorgesehen - was passiert denn dann, wenn für HTML5 seitens des W3C mal
>> ein normativer Text vorgelegt wird und dann irgendwann ein Nachfolger
>> kommt? Gilt dann die alte Norm automatisch nicht mehr oder wird dann
>> doch der DOCTYPE wieder geändert?
>
> Das ist eine gute Frage. Schliesslich wird parallel bereits HTML 5.1
> diskutiert:
>
> <http://www.w3.org/TR/2012/WD-html51-20121217/>

Yep - und da ist ebenfalls keine Version vorgesehen:

<http://www.w3.org/TR/2012/WD-html51-20121217/syntax.html#the-doctype>

D.h. wir erleben wieder die Renaissance alter Zeiten... "HTML" ist das,
was die Browser gerade so unterstützen. Es kann HTML 5 sein, oder
irgendwann auch HTML 5.1 oder das, was das WHATWG als HTML betrachtet... :-/

Arno Welzel

ungelesen,
06.03.2013, 08:12:2606.03.13
an
Am 06.03.2013 12:10, schrieb Magnus Warker:
> On 03/06/2013 08:57 AM, Arno Welzel wrote:
>> Magnus Warker, 2013-03-06 08:34:
>>
>>> Meines Wissens kann IE das nicht, so dass man diesen dann entweder
>>> aussperren oder mehrgleisig fahren müsste.
>>
>> Der IE beherrscht ab Version 9 Canvas schon - nur kein WebGL darin.
>>
>> Aber abgesehen davon: Ein Schachbrett besteht aus 8x8 identischen,
>> leeren oder mit Figuren besetzten Feldern. Was spricht denn dagegen,
>> dafür entsprechende Grafiken anzulegen
>
> Naja, die Möglichkeit, zur Laufzeit in den Canvas zu zeichnen, sehe ich
> schon als sehr nützlich an. Ansonsten müsste man Grafiken für alle
> Firuren und alle möglichen Zustände vorhalten (schwarzes Feld, weißes
> Feld, ausgewählt, sonstwie markiert, ...).
>
> Darüber hinaus sollte die Größe skalierbar sein, was auch für das
> Zeichnen zur Laufzeit spricht.
>
> Ideal wäre IMHO, die Figuren in einem Vektorformat zu halten und dann
> zur Laufzeit in einen n*n Pixel großen Canvas zu zeichnen...

Warum nicht gleich SVG? Das wäre dann auch im Ergebnis ein Vektorformat,
das verlustfrei in beliebiger Auflösung darstellbar ist.

Magnus Warker

ungelesen,
06.03.2013, 10:02:5006.03.13
an
On 03/06/2013 02:12 PM, Arno Welzel wrote:
> Am 06.03.2013 12:10, schrieb Magnus Warker:
>> On 03/06/2013 08:57 AM, Arno Welzel wrote:
>>> Magnus Warker, 2013-03-06 08:34:

>> Dar�ber hinaus sollte die Gr��e skalierbar sein, was auch f�r das
>> Zeichnen zur Laufzeit spricht.
>>
>> Ideal w�re IMHO, die Figuren in einem Vektorformat zu halten und dann
>> zur Laufzeit in einen n*n Pixel gro�en Canvas zu zeichnen...
>
> Warum nicht gleich SVG? Das w�re dann auch im Ergebnis ein Vektorformat,
> das verlustfrei in beliebiger Aufl�sung darstellbar ist.

Hm, ich hatte tats�chlich auch SVG im Visier, aber bisher ging ich immer
davon aus, dass ich dieses zur Laufzeit in ein Bitmap mappen muss.

Oder anders formuliert: Ich h�tte es f�r eine gr��ere H�rde f�r die
verwendeten Browser gehalten, SVGs direkt zu unterst�tzen, als
HTML5-Canvas zu k�nnen.

Wie w�rde man das konkret machen?

Arno Welzel

ungelesen,
06.03.2013, 11:29:0706.03.13
an
Soll das ganze "interaktiv" sein, also per z.B. JavaScript dynamisch
ge�ndert erzeugt oder ge�ndert werden oder geht es nur um die statische
Darstellung?

Als Anregung, wie das SVG daf�r grunds�tzlich aussehen kann:

<http://upload.wikimedia.org/wikipedia/commons/a/a7/Chess_board_blank.svg>

Quelle: <http://commons.wikimedia.org/wiki/File:Chess_board_blank.svg>

<http://upload.wikimedia.org/wikipedia/commons/b/bb/AAA_SVG_Chessboard_and_chess_pieces_01.svg>

Quelle:
<http://commons.wikimedia.org/wiki/File:AAA_SVG_Chessboard_and_chess_pieces_01.svg>

Dar�ber hinaus kann man auch mit JavaScript das SVG-DOM �ndern, neue
Elemente hinzuf�gen usw..

Als Einstieg, siehe z.B. hier:

<http://www.carto.net/svg/manipulating_svg_with_dom_ecmascript/>

HTH

Gustaf Mossakowski

ungelesen,
06.03.2013, 11:46:4906.03.13
an
Arno Welzel schrieb:

> Am 06.03.2013 13:03, schrieb Thomas 'PointedEars' Lahn:
>> Arno Welzel wrote:
>>> Auf <http://www.pointedears.de/index.en> und
>>> <http://www.pointedears.de/index.de>
>>
>> �www.� ist bei mir �berfl�ssig, und sollte es IMO auch anderswo sein.
>
> Dann w�re ein Redirect auf die kanonische URI sinnvoll - aber das weisst
> Du vermutlich selbst.

Momentan leitet es auf <http://pointedears.de/index.de.php> um, also mit
.php am Ende, aber die Website ist eh aufgrund der Schrift fast
unlesbar, das ist wohl etwas, das erst sp�ter angepackt wird.

>>> Zumindest bislang ist auch keine Angabe einer Version im DOCTYPE
>>> vorgesehen - was passiert denn dann, wenn f�r HTML5 seitens des W3C
>>> mal ein normativer Text vorgelegt wird und dann irgendwann ein
>>> Nachfolger kommt? Gilt dann die alte Norm automatisch nicht mehr
>>> oder wird dann doch der DOCTYPE wieder ge�ndert?
>>
>> Das ist eine gute Frage. Schliesslich wird parallel bereits HTML 5.1
>> diskutiert:
>>
>> <http://www.w3.org/TR/2012/WD-html51-20121217/>
>
> Yep - und da ist ebenfalls keine Version vorgesehen:
>
> <http://www.w3.org/TR/2012/WD-html51-20121217/syntax.html#the-doctype>
>
> D.h. wir erleben wieder die Renaissance alter Zeiten... "HTML" ist das,
> was die Browser gerade so unterst�tzen. Es kann HTML 5 sein, oder
> irgendwann auch HTML 5.1 oder das, was das WHATWG als HTML betrachtet... :-/

Nun, das war bei HTML 4 auch nicht anders. Dort gab es nur �ber einen
langen Zeitraum Stabilit�t dadurch, dass Weiterentwicklungen durch das
W3C von den Browserherstellern nur wenig unterst�tzt wurden.

Letztlich wird ein Browser immer abw�rtskompatibel sein m�ssen, also
auch veraltete oder nicht mehr im Sprachstandard enthaltene Elemente
darstellen. Und das W3C und die WHATWG werden darauf achten, Elemente
und Attribute nicht grundlegend neu zu definieren. Insofern ergibt eine
Versionsnummer bei HTML, wenn man das ganze von praktischer Seite aus
betrachtet, wirklich keinen Sinn.

Letztlich hatte bisher meiner Erinnerung nach die DOCTYPE auch nur
Auswirkungen, ob eine Seite korrekt oder mit den bisherigen
Interpretationsfehlern der Browser dargestellt werden sollte. Und f�r so
etwas ist sie m. E. nicht geeignet.

Viele Gr��e
Gustaf

Thomas 'PointedEars' Lahn

ungelesen,
06.03.2013, 11:54:5206.03.13
an
Arno Welzel wrote:

> Am 06.03.2013 13:03, schrieb Thomas 'PointedEars' Lahn:
>> Arno Welzel wrote:
>>> Thomas 'PointedEars' Lahn, 2013-03-05 19:28:
>>>> Arno Welzel wrote:
>>>>> Magnus Warker, 2013-03-05 16:03:
>>>>>> wann werden alle gängigen Browser HTML5 unterstützen, so dass man bei
>>>>>> der Entwicklung von Web-Applikationen darauf aufsetzen kann?
>>>>> Tun sie doch jetzt schon - und einige Websites nutzen das auch schon
>>>>> eifrig, wie <http://www.heise.de/> oder <http://www.sueddeutsche.de/>.
>>>> Meine auch. Die Gründe dafür waren semantisches Markup und die
>>>> Möglichkeit, für Accessibility das tabindex-Attribut überall benutzen
>>>> zu können.
>>> Auf <http://www.pointedears.de/index.en> und
>>> <http://www.pointedears.de/index.de>
>>
>> “www.” ist bei mir überflüssig, und sollte es IMO auch anderswo sein.
>
> Dann wäre ein Redirect auf die kanonische URI sinnvoll - aber das weisst
> Du vermutlich selbst.

Ja. Das stand schon länger auf meiner TODO-Liste, jedoch aus aktuellem
Anlass:

[x] done

Geholfen haben dabei
<http://support.google.com/webmasters/bin/answer.py?hl=en&hlrm=en&answer=139066>
pp.

bzw. hierzugruppe
<http://support.google.com/webmasters/bin/answer.py?hl=de&hlrm=en&answer=139066>
ff.

>>> nur die bei (X)HTML üblichen DIV-Schachtelungen mit IDs.
>>
>> Das ist so nicht richtig. Ich verwende zwar für die grafische
>> Darstellung auch div-Elemente, aber nicht ausschliesslich solche mit
>> id-Attribut.
>
> […]
> Aber von "ausschliesslich" im Zusammenhang mit DIVs und IDs hast Du
> jetzt geredet - das habe ich nirgends behauptet und auch nicht so gemeint.

ACK.

Ein weiterer Grund für die Wahl von HTML5 für meine Website (derzeit jedoch
nur auf der Homepage) war die dadurch eröffnete Möglichkeit, nun auch gemäss
W3C-Validator gültige audio-Elemente verwenden zu können. Diese lassen sich
besser formatieren und programmieren als pluginabhängige OBJECT- bzw. EMBED
Elemente und somit zum Beispiel für authentische Geräusche der
Benutzeroberfläche verwenden; vor allem bei Benutzeraktionen.

> [...]
>>> Genau das meine ich ja - "Living Standard" bedeutet ja nichts anderes,
>>> als "es gibt keine Referenz". Wenn etwas nicht funktioniert, ist nicht
>>> mehr klar, ob man nun in seinen Dokumenten etwas grundsätzlich falsch
>>> gemacht hat, oder ob nur der Browser es nicht richtig umsetzt.
>>
>> Aber ”HTML – The Living Standard” ist _nicht_ HTML5. Das sind zwei
>
> Zumindest sieht das WHATWG es wohl anders, was "HTML5" eigentlich
> bedeutet. Siehe auch
> <http://www.whatwg.org/specs/web-apps/current-work/#is-this-html5?>
>
> Zitat:
>
> "1.2 Is this HTML5?
>
> This section is non-normative.
>
> In short: Yes."

Da geht es noch weiter. Relevant ist hierbei jedoch nicht, was der/die
Verfasser von “HTML – The Living Standard” behauptet, sondern was die
Verfasser von “HTML5” schreiben:

<http://www.w3.org/TR/2012/CR-html5-20121217/introduction.html#history-0>

>> *verschiedene* Spezifikationen (wobei man darüber diskutieren kann, ob
>> das erstgenannte überhaupt die Bezeichnung „Spezifikation“ verdient oder
>> nicht etwa die Bezeichnung „Spezifikationssimulationstohuwabohu“
>> geeigneter ist).
>
> ACK.
>
> Wobei ich jetzt nicht weiss, ob Browseranbieter eher die bei der
> W3C-Spezifikation beachten oder die Texte der WHATWG.

Ja, das ist – ausser bei Microsoft – nicht ganz klar.

>>> Zumindest bislang ist auch keine Angabe einer Version im DOCTYPE
>>> vorgesehen - was passiert denn dann, wenn für HTML5 seitens des W3C mal
>>> ein normativer Text vorgelegt wird und dann irgendwann ein Nachfolger
>>> kommt? Gilt dann die alte Norm automatisch nicht mehr oder wird dann
>>> doch der DOCTYPE wieder geändert?
>>
>> Das ist eine gute Frage. Schliesslich wird parallel bereits HTML 5.1
>> diskutiert:
>>
>> <http://www.w3.org/TR/2012/WD-html51-20121217/>
>
> Yep - und da ist ebenfalls keine Version vorgesehen:
>
> <http://www.w3.org/TR/2012/WD-html51-20121217/syntax.html#the-doctype>
>
> D.h. wir erleben wieder die Renaissance alter Zeiten... "HTML" ist das,
> was die Browser gerade so unterstützen. Es kann HTML 5 sein, oder
> irgendwann auch HTML 5.1 oder das, was das WHATWG als HTML betrachtet...
> :-/

Fast so wie ich es damals erwartet hatte. Es hätte schlimmer kommen
können – wenn nämlich das W3C die weitere Entwicklung von HTML allein der
WHATWG überlassen hätte. Schade ist nur, dass XHTML dafür geopfert wurde;
man hätte durchaus beides haben können. Jetzt haben wir HTML5, das ein
bisschen wie XHTML ist (die XML-SHORTTAG-Syntax ist für leere Elemente
erlaubt, SVG und MathML können standardkonform eingebettet werden), aber
längst nicht so mächtig (das war es dann nämlich, es sei denn, man macht den
Irrsinn namens “XHTML5” mit).

Interessant in diesem Zusammenhang ist, dass Chris Wilson von Microsoft bei
der WHATWG nicht dabei ist, weil die WHATWG *keine* Patentrichtlinien hat.
Demgegenüber gilt für W3C-Standards, dass sie ohne Lizenzgebühr
implementierbar sein müssen:

<http://blogs.msdn.com/b/cwilso/archive/2007/01/10/you-me-and-the-w3c-aka-
reinventing-html.aspx>


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>

Thomas 'PointedEars' Lahn

ungelesen,
06.03.2013, 12:05:0906.03.13
an
Gustaf Mossakowski wrote:

> Arno Welzel schrieb:
>> Am 06.03.2013 13:03, schrieb Thomas 'PointedEars' Lahn:
>>> Arno Welzel wrote:
>>>> Auf <http://www.pointedears.de/index.en> und
>>>> <http://www.pointedears.de/index.de>
>>> ³www.² ist bei mir überflüssig, und sollte es IMO auch anderswo sein.
>>
>> Dann wäre ein Redirect auf die kanonische URI sinnvoll - aber das weisst
>> Du vermutlich selbst.
>
> Momentan leitet es auf <http://pointedears.de/index.de.php> um, also mit
> .php am Ende,

Ja, inzwischen ist Zeit vergangen. Die Umleitung von index.de zu
index.de.php bei „falscher“ Domain ist ein ungewolltes Ergebnis von

RewriteCond %{HTTP_HOST} !^pointedears\.de [NC]
RewriteCond %{HTTP_HOST} !^$
RewriteRule ^/?(.*) http://pointedears.de/$1 [L,R=permanent,NE]

Meine URIs sollen _nicht_ technologiespezifisch sein.

<http://www.w3.org/QA/Tips/uri-choose>

> aber die Website ist eh aufgrund der Schrift fast unlesbar,

Wie bitte?

> das ist wohl etwas, das erst später angepackt wird.

Etwas Feintuning ist noch nötig (z. B. eine .eot für Kindernet Exploder),
aber grundsätzlich bleibt die authentische LCARS-Schriftart.


PointedEars
--
Von "funktionieren" kann also hier keine Rede sein. Ursache für Deinen
Irrtum ist wohl, dass auch Du annimmst, dass Ausprobieren von Spaghetticode
auf einem System oder wenigen Systemen ein sinnvoller Ersatz für saubere
Syntax und richtige Tests sei. -- Dietmar Meier in dcljs

Gustaf Mossakowski

ungelesen,
06.03.2013, 12:35:3706.03.13
an
Thomas 'PointedEars' Lahn schrieb:

[Umleitung <http://www.pointedears.de/index.de> auf
<http://pointedears.de/index.de>]

> Ja, inzwischen ist Zeit vergangen. Die Umleitung von index.de zu
> index.de.php bei "falscher" Domain ist ein ungewolltes Ergebnis von
>
> RewriteCond %{HTTP_HOST} !^pointedears\.de [NC]
> RewriteCond %{HTTP_HOST} !^$

Nur als Frage, wofür ist das? Soweit ich mich erinnere, kann man deine
Website doch sowieso nicht ohne Angabe des Host-Headers erreichen.

> RewriteRule ^/?(.*) http://pointedears.de/$1 [L,R=permanent,NE]
>
> Meine URIs sollen _nicht_ technologiespezifisch sein.

Der Server gibt bei Anfrage nach oben genannter URL u. a.

| Content-Location: index.de.php

zurück.

Vielleicht hilft

RewriteCond %{HTTP_HOST} !^pointedears\.de [NC]
RewriteRule ^/?(.*).php http://pointedears.de/$1 [L,R=permanent,NE]

RewriteCond %{HTTP_HOST} !^pointedears\.de [NC]
RewriteRule ^/?(.*) http://pointedears.de/$1 [L,R=permanent,NE]

weiter?

>> aber die Website ist eh aufgrund der Schrift fast unlesbar,
>
> Wie bitte?

<http://www.koenige.org/temp/schrift.png>

Viele Grüße, Gustaf

Thomas 'PointedEars' Lahn

ungelesen,
06.03.2013, 13:39:5206.03.13
an
Gustaf Mossakowski wrote:

> Thomas 'PointedEars' Lahn schrieb:
>
> [Umleitung <http://www.pointedears.de/index.de> auf
> <http://pointedears.de/index.de>]
>
>> Ja, inzwischen ist Zeit vergangen. Die Umleitung von index.de zu
>> index.de.php bei "falscher" Domain ist ein ungewolltes Ergebnis von
>>
>> RewriteCond %{HTTP_HOST} !^pointedears\.de [NC]
>> RewriteCond %{HTTP_HOST} !^$
>
> Nur als Frage, wofür ist das?

Lies mal Deine Zusammenfassung des Zitats.

> Soweit ich mich erinnere, kann man deine Website doch sowieso nicht ohne
> Angabe des Host-Headers erreichen.

So wie auch kaum, wenn inzwischen überhaupt noch, eine andere Website.

>> RewriteRule ^/?(.*) http://pointedears.de/$1 [L,R=permanent,NE]
>>
>> Meine URIs sollen _nicht_ technologiespezifisch sein.
>
> Der Server gibt bei Anfrage nach oben genannter URL u. a.
>
> | Content-Location: index.de.php
>
> zurück.
>
> Vielleicht hilft
>
> RewriteCond %{HTTP_HOST} !^pointedears\.de [NC]
> RewriteRule ^/?(.*).php http://pointedears.de/$1 [L,R=permanent,NE]
>
> RewriteCond %{HTTP_HOST} !^pointedears\.de [NC]
> RewriteRule ^/?(.*) http://pointedears.de/$1 [L,R=permanent,NE]
>
> weiter?

Sicher nicht. Ich mach doch nicht Content Negotiation, damit ich mir
nachher mit doppelter Umleitung wieder in den Fuss schiesse. Offensichtlich
hast Du nicht verstanden, was diese Zeilen tun. RTFM.

>>> aber die Website ist eh aufgrund der Schrift fast unlesbar,
>>
>> Wie bitte?
>
> <http://www.koenige.org/temp/schrift.png>

Übereifriges Anti-Aliasing. Das liegt eher nicht an mir, sondern an Dir
bzw. Deinem Browser (Safari? Version?). Die Schrift wird lesbarer, wenn Du
das Anti-Aliasing passend (auch zu Deinem Monitor) einstellst.

Vielleicht könnte ich aber eine passende CSS-Direktive für bestimmte WebKit-
basierte Browser einbauen, die sie zu moderatem Anti-Aliasing zwingt. Die
ganz authentische Adobe-Schriftart, die sich auf Macs auch eher installiert
findet, wollte ich ohnehin noch testen. Mal sehen.


PointedEars
--
Nimm VerBrecherSCRIPT, denn das ist kein JavaScript-Objekt, wird also bei
keinem vernünftigen Browser geschweige denn auf einer vernünftigen Plattform
funktionieren, so daß Du auch [...] gleich mit VBSCRIPT arbeiten kannst und
dies auch tun solltest. -- Georg Maaß in dcljs

Gustaf Mossakowski

ungelesen,
06.03.2013, 13:58:0706.03.13
an
Thomas 'PointedEars' Lahn schrieb:

> Gustaf Mossakowski wrote:
>> Thomas 'PointedEars' Lahn schrieb:
>>
>> [Umleitung <http://www.pointedears.de/index.de> auf
>> <http://pointedears.de/index.de>]
>>
>>> Ja, inzwischen ist Zeit vergangen. Die Umleitung von index.de zu
>>> index.de.php bei "falscher" Domain ist ein ungewolltes Ergebnis von
>>>
>>> RewriteCond %{HTTP_HOST} !^pointedears\.de [NC]
>>> RewriteCond %{HTTP_HOST} !^$
>>
>> Nur als Frage, wof�r ist das?
>
> Lies mal Deine Zusammenfassung des Zitats.

Ich bezog mich hier auf die zweite Zeile, unter die ich meine Frage
schrieb.

>> Soweit ich mich erinnere, kann man deine Website doch sowieso nicht
>> ohne Angabe des Host-Headers erreichen.
>
> So wie auch kaum, wenn inzwischen �berhaupt noch, eine andere Website.

Also ist �RewriteCond %{HTTP_HOST} !^$� vermutlich �berfl�ssig. Es sei
denn, es gibt noch irgendwelche Bedingungen, bei denen der HTTP_HOST
nicht gesetzt wird und das aus Kompatibilit�tsgr�nden ber�cksichtigt
werden mu�. In die Richtung zielte meine Frage. Kennt da jemand einen
Sonderfall?

>>> Meine URIs sollen _nicht_ technologiespezifisch sein.
>>
>> Der Server gibt bei Anfrage nach oben genannter URL u. a.
>>
>> | Content-Location: index.de.php
>>
>> zur�ck.
>>
>> Vielleicht hilft
>>
>> RewriteCond %{HTTP_HOST} !^pointedears\.de [NC]
>> RewriteRule ^/?(.*).php http://pointedears.de/$1 [L,R=permanent,NE]
>>
>> RewriteCond %{HTTP_HOST} !^pointedears\.de [NC]
>> RewriteRule ^/?(.*) http://pointedears.de/$1 [L,R=permanent,NE]
>>
>> weiter?
>
> Sicher nicht. Ich mach doch nicht Content Negotiation, damit ich mir
> nachher mit doppelter Umleitung wieder in den Fuss schiesse. Offensichtlich
> hast Du nicht verstanden, was diese Zeilen tun. RTFM.

[L] bedeutet, dass keine weitere Umschreibung der URL mehr stattfindet.
Beim erneuten Aufruf der .htaccess nach der Umleitung [R=permanent]
findet keine der beiden Regeln (RewriteRule) mehr Anwendung, da die
Bedingung (RewriteCond) nicht mehr zutrifft. Es findet keine doppelte
Umleitung statt.

Viele Gr��e, Gustaf

Thomas 'PointedEars' Lahn

ungelesen,
06.03.2013, 14:56:5806.03.13
an
Gustaf Mossakowski wrote:

> Thomas 'PointedEars' Lahn schrieb:
>> Gustaf Mossakowski wrote:
>>> Thomas 'PointedEars' Lahn schrieb:
>>>
>>> [Umleitung <http://www.pointedears.de/index.de> auf
>>> <http://pointedears.de/index.de>]
>>>
>>>> Ja, inzwischen ist Zeit vergangen. Die Umleitung von index.de zu
>>>> index.de.php bei "falscher" Domain ist ein ungewolltes Ergebnis von
>>>>
>>>> RewriteCond %{HTTP_HOST} !^pointedears\.de [NC]
>>>> RewriteCond %{HTTP_HOST} !^$
>>>
>>> Nur als Frage, wofür ist das?
>> […]
>>> Soweit ich mich erinnere, kann man deine Website doch sowieso nicht
>>> ohne Angabe des Host-Headers erreichen.
>>
>> So wie auch kaum, wenn inzwischen überhaupt noch, eine andere Website.
>
> Also ist »RewriteCond %{HTTP_HOST} !^$« vermutlich überflüssig. Es sei
> denn, es gibt noch irgendwelche Bedingungen, bei denen der HTTP_HOST
> nicht gesetzt wird und das aus Kompatibilitätsgründen berücksichtigt
> werden muß. In die Richtung zielte meine Frage. Kennt da jemand einen
> Sonderfall?

Ich könnte mir vorstellen, dass man in der Anleitung berücksichtigen wollte,
dass kein Virtual Host benutzt werden *muss*. Ich werde die Zeile also
stehen lassen, damit ich später keinen Ärger habe.

<http://httpd.apache.org/docs/2.2/rewrite/remapping.html#canonicalhost>

>>>> Meine URIs sollen _nicht_ technologiespezifisch sein.
>>>
>>> Der Server gibt bei Anfrage nach oben genannter URL u. a.
>>>
>>> | Content-Location: index.de.php
>>>
>>> zurück.
>>>
>>> Vielleicht hilft
>>>
>>> RewriteCond %{HTTP_HOST} !^pointedears\.de [NC]
>>> RewriteRule ^/?(.*).php http://pointedears.de/$1 [L,R=permanent,NE]
>>>
>>> RewriteCond %{HTTP_HOST} !^pointedears\.de [NC]
>>> RewriteRule ^/?(.*) http://pointedears.de/$1 [L,R=permanent,NE]
>>>
>>> weiter?
>>
>> Sicher nicht. Ich mach doch nicht Content Negotiation, damit ich mir
>> nachher mit doppelter Umleitung wieder in den Fuss schiesse.
>> Offensichtlich hast Du nicht verstanden, was diese Zeilen tun. RTFM.
>
> […] Es findet keine doppelte Umleitung statt.

Stimmt. Aber das löst das Problem entweder nur teilweise oder völlig fhcsal
(es muss *mindestens* “…\.php” heissen).


PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann

Gustaf Mossakowski

ungelesen,
06.03.2013, 15:19:5806.03.13
an
Thomas 'PointedEars' Lahn schrieb:

[RewriteRule ^/?(.*).php http://pointedears.de/$1 [L,R=permanent,NE]]
>> [...] Es findet keine doppelte Umleitung statt.
>
> Stimmt. Aber das löst das Problem entweder nur teilweise oder völlig fhcsal
> (es muss *mindestens* "...\.php" heissen).

Jupp, den umgekehrten Schrägstrich hatte ich vergessen. (Ich kann dir ja
auch nicht alles vorkauen ;-)) Was meinst du mit »teilweise«?

Viele Grüße, Gustaf

Thomas 'PointedEars' Lahn

ungelesen,
06.03.2013, 15:44:3506.03.13
an
Gustaf Mossakowski wrote:

> Thomas 'PointedEars' Lahn schrieb:
>
> [RewriteRule ^/?(.*).php http://pointedears.de/$1 [L,R=permanent,NE]]
>>> [...] Es findet keine doppelte Umleitung statt.
>>
>> Stimmt. Aber das löst das Problem entweder nur teilweise oder völlig
>> fhcsal (es muss *mindestens* "...\.php" heissen).
>
> Jupp, den umgekehrten Schrägstrich hatte ich vergessen. (Ich kann dir ja
> auch nicht alles vorkauen ;-))

Auf die meisten Deiner Vorkauereien kann *ich* gut verzichten. Ich mach das
([LW]AMP & Co.) schliesslich nicht erst seit gestern.

> Was meinst du mit »teilweise«?

1. foo(\.css)?
2. foo(\.php)?\?bar(=baz(&bla)?)?(#blubb)?

Das Beste wäre, wenn man mod_negotiation abgewöhnen könnte, seltsame
Response-Headerfelder zu generieren. Die machen irgendwie nur Probleme, zum
Beispiel auch mit IE 9 bei der serverseitigen dynamischen Erzeugung von CSS:

<http://blog.s9y.org/archives/227-ie9-has-trouble-with-css-content-
types.html>
<http://blogs.msdn.com/b/ieinternals/archive/2011/03/27/http-406-not-
acceptable-php-ie9-standards-mode-accepts-only-text_2f00_css-for-
stylesheets.aspx>

Deshalb kann ich die Stylesheets mit Content Negotiation nicht in eine
Response packen, obwohl das mit serverseitigem PHP durchaus möglich wäre
(nämlich so wie bei den clientseitigen Scripts, siehe builder.php).


PointedEars
--
Mozilla ist ein Webbrowser. Das ist ein Programm, dass es ermoeglicht,
Webseiten anzusehen. Das ist nicht sowas wie ein Programm, das es
Webdesignern erlaubt, den Nutzer zu belaestigen, indem man seine
Arbeitsumgebung unsinnig manipuliert. -- Boris 'pi' Piwinger in dcljs

Gustaf Mossakowski

ungelesen,
06.03.2013, 16:08:3806.03.13
an
Thomas 'PointedEars' Lahn schrieb:

> Gustaf Mossakowski wrote:
>
>> Thomas 'PointedEars' Lahn schrieb:
>>
>> [RewriteRule ^/?(.*).php http://pointedears.de/$1 [L,R=permanent,NE]]
>>>> [...] Es findet keine doppelte Umleitung statt.
>>>
>>> Stimmt. Aber das löst das Problem entweder nur teilweise oder völlig
>>> fhcsal (es muss *mindestens* "...\.php" heissen).
>>
>> Jupp, den umgekehrten Schrägstrich hatte ich vergessen. (Ich kann
>> dir ja auch nicht alles vorkauen ;-))
>
> Auf die meisten Deiner Vorkauereien kann *ich* gut verzichten. Ich mach das
> ([LW]AMP & Co.) schliesslich nicht erst seit gestern.

Nur als Hinweis: Diese Aussage steht konträr zu:
| Die Umleitung von index.de zu
| index.de.php bei “falscher³ Domain ist ein ungewolltes Ergebnis [...]
Message-ID: <4113310.z...@PointedEars.de>

>> Was meinst du mit »teilweise«?
>
> 1. foo(\.css)?

Das dürfte eher theoretisch notwendig sein, da keiner direkt auf
CSS-Dateien zugreift.

> 2. foo(\.php)?\?bar(=baz(&bla)?)?(#blubb)?

Das ist sinnfrei. Query strings werden von der oben genannten Regel
erfaßt; Anker kann man nicht umleiten, da alles hinter dem # gar nicht
zum Server gesendet wird.

> Das Beste wäre, wenn man mod_negotiation abgewöhnen könnte, seltsame
> Response-Headerfelder zu generieren.

Oder du nutzt gleich für alles mod_rewrite, wenn es eh schon mal an ist.

Viele Grüße, Gustaf

Thomas 'PointedEars' Lahn

ungelesen,
06.03.2013, 19:42:2406.03.13
an
Gustaf Mossakowski wrote:

> Thomas 'PointedEars' Lahn schrieb:
>> Gustaf Mossakowski wrote:
>>> Thomas 'PointedEars' Lahn schrieb:
>>> [RewriteRule ^/?(.*).php http://pointedears.de/$1 [L,R=permanent,NE]]
>>>>> [...] Es findet keine doppelte Umleitung statt.
>>>> Stimmt. Aber das löst das Problem entweder nur teilweise oder völlig
>>>> fhcsal (es muss *mindestens* "...\.php" heissen).
>>> Jupp, den umgekehrten Schrägstrich hatte ich vergessen. (Ich kann
>>> dir ja auch nicht alles vorkauen ;-))
>>
>> Auf die meisten Deiner Vorkauereien kann *ich* gut verzichten. Ich mach
>> das ([LW]AMP & Co.) schliesslich nicht erst seit gestern.
>
> Nur als Hinweis: Diese Aussage steht konträr zu:
> | Die Umleitung von index.de zu
> | index.de.php bei “falscher³ Domain ist ein ungewolltes Ergebnis [...]
> Message-ID: <4113310.z...@PointedEars.de>

Du irrst. Und verstümmelst Zeichen.

>>> Was meinst du mit »teilweise«?
>>
>> 1. foo(\.css)?
>
> Das dürfte eher theoretisch notwendig sein, da keiner direkt auf
> CSS-Dateien zugreift.

[_] Du kennst Dich aus.

>> 2. foo(\.php)?\?bar(=baz(&bla)?)?(#blubb)?
>
> Das ist sinnfrei. Query strings werden von der oben genannten Regel
> erfaßt;

Faszinierend. Nun, auch ein blindes Huhn findet mal ein Korn.

> Anker kann man nicht umleiten, da alles hinter dem # gar nicht
> zum Server gesendet wird.

Eben.

>> Das Beste wäre, wenn man mod_negotiation abgewöhnen könnte, seltsame
>> Response-Headerfelder zu generieren.
>
> Oder du nutzt gleich für alles mod_rewrite, wenn es eh schon mal an ist.

[_] Du kennst Dich aus.


PointedEars
--
Snowboarder können gar kein JavaScript. Sie klicken in Dreamweaver
'was zusammen und glauben, das sei "Programmieren".

-- Andreas Hollmann in dciwam

Magnus Warker

ungelesen,
07.03.2013, 01:52:1007.03.13
an
On 03/06/2013 05:29 PM, Arno Welzel wrote:
> Am 06.03.2013 16:02, schrieb Magnus Warker:
>> On 03/06/2013 02:12 PM, Arno Welzel wrote:
>>> Am 06.03.2013 12:10, schrieb Magnus Warker:
>>>> On 03/06/2013 08:57 AM, Arno Welzel wrote:
>>>>> Magnus Warker, 2013-03-06 08:34:

>> Hm, ich hatte tats�chlich auch SVG im Visier, aber bisher ging ich immer
>> davon aus, dass ich dieses zur Laufzeit in ein Bitmap mappen muss.
>>
>> Oder anders formuliert: Ich h�tte es f�r eine gr��ere H�rde f�r die
>> verwendeten Browser gehalten, SVGs direkt zu unterst�tzen, als
>> HTML5-Canvas zu k�nnen.
>>
>> Wie w�rde man das konkret machen?
>
> Soll das ganze "interaktiv" sein, also per z.B. JavaScript dynamisch
> ge�ndert erzeugt oder ge�ndert werden oder geht es nur um die statische
> Darstellung?
>
> Als Anregung, wie das SVG daf�r grunds�tzlich aussehen kann:

Danke f�r die Links! Sieht gut aus auf den ersten Blick.
Aber: K�nnen das die "g�ngigen" Browser?

(Wenn nicht, w�re es wie bei HTML5-Canvas fraglich, ob es Sinn macht,
eine Technologie einzusetzen, die nicht alle (unterst�tzten) Browser
k�nnen).

Es handelt sich um einen Schach-Server auf der Basis von GWT. Das Brett
wird derzeit als Tabelle realisiert und die Figuren sind von fester
Gr��e. Ich w�rde auf ein skalierbares Format umsteigen, wenn es von den
"g�ngigen" Browsern unterst�tzt w�rde.

(Bei Interesse k�nnen wir gerne mal eine Partie wagen. :-))

Markus Grob

ungelesen,
07.03.2013, 02:38:0807.03.13
an
Magnus Warker schrieb:

> Es handelt sich um einen Schach-Server auf der Basis von GWT. Das Brett
> wird derzeit als Tabelle realisiert und die Figuren sind von fester
> Gr��e. Ich w�rde auf ein skalierbares Format umsteigen, wenn es von den
> "g�ngigen" Browsern unterst�tzt w�rde.

Nun, die Frage stellt sich (wie immer): Was bezeichnest Du als g�ngige
Browser?
Wie viel Prozent Deiner "Kundschaft" verwendet einen Browser, welcher
veraltet ist und die nicht wegen Deiner Seite umsteigen m�chte?

Du kannst ja einen Versuch wagen und unterhalb einen Link auf die alte
Version machen und dazu schreiben, dass die veraltete Seite bald
abgestellt wird und die Personen aus Sicherheitsgr�nden umsteigen sollen
auf einen neueren Browser.


> (Bei Interesse k�nnen wir gerne mal eine Partie wagen. :-))

Ich w�rde mich bereit erkl�ren :-)

Gruss, Markus

Arno Welzel

ungelesen,
07.03.2013, 03:31:2307.03.13
an
Thomas 'PointedEars' Lahn, 2013-03-06 19:39:

> Gustaf Mossakowski wrote:
>
>> Thomas 'PointedEars' Lahn schrieb:
>>
[...]
>>>> aber die Website ist eh aufgrund der Schrift fast unlesbar,
>>>
>>> Wie bitte?
>>
>> <http://www.koenige.org/temp/schrift.png>
>
> Übereifriges Anti-Aliasing. Das liegt eher nicht an mir, sondern an Dir
> bzw. Deinem Browser (Safari? Version?). Die Schrift wird lesbarer, wenn Du
> das Anti-Aliasing passend (auch zu Deinem Monitor) einstellst.

Soviel zum Thema "Webfonts sind problemlos benutzbar"... ;-)

Ok, ich nutze mittlerweile auch eine eigenen Schrift für
<http://arnowelzel.de>. Aber diese extrem schmale LCARS-Schrift *ist*
schwer lesbar, auch bei korrektem Antialiasing. Als Design-Spielerei für
die Startseite mag es ja ok sein - aber spätestens bei längeren Texten
ist das eine echte Zumutung:

<http://arnowelzel.de/samples/pointedears-ufpdb.png>

Arno Welzel

ungelesen,
07.03.2013, 03:39:4007.03.13
an
Magnus Warker, 2013-03-07 07:52:

> On 03/06/2013 05:29 PM, Arno Welzel wrote:
>> Am 06.03.2013 16:02, schrieb Magnus Warker:
>>> On 03/06/2013 02:12 PM, Arno Welzel wrote:
>>>> Am 06.03.2013 12:10, schrieb Magnus Warker:
>>>>> On 03/06/2013 08:57 AM, Arno Welzel wrote:
>>>>>> Magnus Warker, 2013-03-06 08:34:
>
>>> Hm, ich hatte tats�chlich auch SVG im Visier, aber bisher ging ich immer
>>> davon aus, dass ich dieses zur Laufzeit in ein Bitmap mappen muss.
>>>
>>> Oder anders formuliert: Ich h�tte es f�r eine gr��ere H�rde f�r die
>>> verwendeten Browser gehalten, SVGs direkt zu unterst�tzen, als
>>> HTML5-Canvas zu k�nnen.
>>>
>>> Wie w�rde man das konkret machen?
>>
>> Soll das ganze "interaktiv" sein, also per z.B. JavaScript dynamisch
>> ge�ndert erzeugt oder ge�ndert werden oder geht es nur um die statische
>> Darstellung?
>>
>> Als Anregung, wie das SVG daf�r grunds�tzlich aussehen kann:
>
> Danke f�r die Links! Sieht gut aus auf den ersten Blick.
> Aber: K�nnen das die "g�ngigen" Browser?

Ich hatte ja schon mal darauf hingewiesen: <http://caniuse.com/>

Wenn man als "g�ngig" IE ab Version 9, oder aktuelle Versionen von
Firefox oder Chrome annimmt - ja.

[...]
> (Bei Interesse k�nnen wir gerne mal eine Partie wagen. :-))

Der gro�e Schachspieler bin nicht nicht - aber von mir aus gerne. Meine
Absenderadresse funktioniert und wird auch gelesen ;-)

Susanne Jäger

ungelesen,
07.03.2013, 03:49:4107.03.13
an
Arno Welzel schrieb am 07.03.2013 09:39:

> Ich hatte ja schon mal darauf hingewiesen: <http://caniuse.com/>
>
> Wenn man als "g�ngig" IE ab Version 9, oder aktuelle Versionen von
> Firefox oder Chrome annimmt - ja.

IE9 als Voraussetzung hat halt das Problem, dass man damit die IE-Nutzer
aussperrt, die noch XP nutzen. F�r Grundfunktionalit�t mag ich das noch
nicht, aber f�r ein Spiel oder eine ausgefuchstere Anwendung l�sst sich
das sicher rechtfertigen - ggf mit einem Hinweis �ber die
Voraussetzungen und Alternativen versehen.

Gru�
Susanne

Arno Welzel

ungelesen,
07.03.2013, 04:15:1507.03.13
an
Grunds�tzlich stimmte ich Dir da schon zu - aber der IE8 ist nun auch
schon 4 Jahre alt (erste Ver�ffentlichung war im M�rz 2009). Wer sowas
nutzt, muss ohnehin mit Einschr�nkungen rechnen und es ist ja kein
Problem, auch unter Windows XP aktueller Browser, wie Firefox, zu verwenden.

Alexander Schestag

ungelesen,
07.03.2013, 08:10:3607.03.13
an
Am 07.03.2013 09:49, schrieb Susanne Jäger:

> IE9 als Voraussetzung hat halt das Problem, dass man damit die IE-Nutzer
> aussperrt, die noch XP nutzen. Für Grundfunktionalität mag ich das noch
> nicht,

Mittlerweile ist es eine Minderheit. Und deren Rechner sind eh über kurz
oder lang - eher kurz - offline, weil kompromittiert.

SCNR,

Alex

--
http://www.schestag.de

Susanne Jäger

ungelesen,
07.03.2013, 08:20:4807.03.13
an
Alexander Schestag schrieb am 07.03.2013 14:10:
> Am 07.03.2013 09:49, schrieb Susanne Jäger:
>
>> IE9 als Voraussetzung hat halt das Problem, dass man damit die IE-Nutzer
>> aussperrt, die noch XP nutzen. Für Grundfunktionalität mag ich das noch
>> nicht,
>
> Mittlerweile ist es eine Minderheit. Und deren Rechner sind eh über kurz
> oder lang - eher kurz - offline, weil kompromittiert.

Minderheit sicher, aber zu vernachlässigen?
Ich habe keine Statistiken zur Hand, aber in meinem privaten Umfeld ist
XP noch sehr weit verbreitet. IE6 auslisten lasse ich mir ja gefallen,
aber 8 finde ich noch nicht gerechtfertigt - wie gesagt für
Grundfunktionalität. Wenn es um spezielle - begründbare Anwendungen
geht, oder bestimmte Zusatzeffekte geht, kann das ganz anders aussehen.

Gruß
Susanne


Alexander Schestag

ungelesen,
07.03.2013, 08:36:0007.03.13
an
Am 07.03.2013 14:20, schrieb Susanne Jäger:
> Alexander Schestag schrieb am 07.03.2013 14:10:
>> Am 07.03.2013 09:49, schrieb Susanne Jäger:
>>
>>> IE9 als Voraussetzung hat halt das Problem, dass man damit die IE-Nutzer
>>> aussperrt, die noch XP nutzen. Für Grundfunktionalität mag ich das noch
>>> nicht,
>>
>> Mittlerweile ist es eine Minderheit. Und deren Rechner sind eh über kurz
>> oder lang - eher kurz - offline, weil kompromittiert.
>
> Minderheit sicher, aber zu vernachlässigen?
> Ich habe keine Statistiken zur Hand, aber in meinem privaten Umfeld ist
> XP noch sehr weit verbreitet. IE6 auslisten lasse ich mir ja gefallen,
> aber 8 finde ich noch nicht gerechtfertigt

Ähm, du sprachst von XP-Usern, nicht von IE8-Usern per se. Es gibt schon
auch noch IE8-User auf Windows 7. Aber XP-User, die auch IE 6 oder 7
haben können - daher war das nicht eindeutig - sollten langsam
aussterben. Das System wird nicht mal mehr mit Sicherheits-Updates
versorgt. Das regelt also sowieso die freie Wildbahn.

Alex

--
http://www.schestag.de

Susanne Jäger

ungelesen,
07.03.2013, 08:55:2007.03.13
an
Alexander Schestag schrieb am 07.03.2013 14:36:
> Am 07.03.2013 14:20, schrieb Susanne Jäger:
>> Alexander Schestag schrieb am 07.03.2013 14:10:
>>> Am 07.03.2013 09:49, schrieb Susanne Jäger:
>>
>> Minderheit sicher, aber zu vernachlässigen?
>> Ich habe keine Statistiken zur Hand, aber in meinem privaten Umfeld ist
>> XP noch sehr weit verbreitet. IE6 auslisten lasse ich mir ja gefallen,
>> aber 8 finde ich noch nicht gerechtfertigt
>
> Ähm, du sprachst von XP-Usern, nicht von IE8-Usern per se. Es gibt schon
> auch noch IE8-User auf Windows 7.

Auf IE8-Nutzer bei Win7 bin ich aber noch weniger bereit Rücksicht zu
nehmen. Die *könnten* ja problemlos updaten. XP-Nutzer müssen Geld in
die Hand nehmen

> Aber XP-User, die auch IE 6 oder 7
> haben können - daher war das nicht eindeutig - sollten langsam
> aussterben.

sollten vielleicht, aber langsam kann sich meiner Wahrnehmung nach noch
'ne ganze Weile hinziehen.

Gruß
Susanne

Magnus Warker

ungelesen,
07.03.2013, 09:20:1807.03.13
an
On 03/07/2013 08:38 AM, Markus Grob wrote:
> Magnus Warker schrieb:

> Nun, die Frage stellt sich (wie immer): Was bezeichnest Du als gängige
> Browser?

Ich weiß, daher hatte ich das ja in Anführungszeichen gesetzt. Ich würde
mal spontan sagen: FF, Chrome, IE, Safari... Auch die Browser von KDE
und Gnome wären nicht schlecht.

> Wie viel Prozent Deiner "Kundschaft" verwendet einen Browser, welcher
> veraltet ist und die nicht wegen Deiner Seite umsteigen möchte?

Die neueste Version würde ich voraussetzen.

Ich möchte lediglich auf ein gemeldetes Problem eine angemessene Antwort
geben können (z. B. "bitte upgraden").

> Du kannst ja einen Versuch wagen und unterhalb einen Link auf die alte
> Version machen und dazu schreiben, dass die veraltete Seite bald
> abgestellt wird und die Personen aus Sicherheitsgründen umsteigen sollen
> auf einen neueren Browser.

So würde ich es auch machen. Aber nochmal zurück zu SVG: Kann man etwas
zur Unterstützung in den Browsern sagen, vielleicht auch im Vergleich zu
HTML5-Canvas?

>> (Bei Interesse können wir gerne mal eine Partie wagen. :-))
> Ich würde mich bereit erklären :-)

Schön! Bitte einen Nickname und E-Mail-Adresse an m...@alpenjodel.de. :)

Susanne Jäger

ungelesen,
07.03.2013, 09:28:0007.03.13
an
Magnus Warker schrieb am 07.03.2013 15:20:

> So würde ich es auch machen. Aber nochmal zurück zu SVG: Kann man etwas
> zur Unterstützung in den Browsern sagen, vielleicht auch im Vergleich zu
> HTML5-Canvas?

caniuse wurde doch jetzt schon mehrfach genannt:
http://caniuse.com/#search=svg
http://caniuse.com/#search=canvas

Gruß
Susanne

Alexander Schestag

ungelesen,
07.03.2013, 09:45:2207.03.13
an
Am 07.03.2013 15:20, schrieb Magnus Warker:
> On 03/07/2013 08:38 AM, Markus Grob wrote:
>> Magnus Warker schrieb:
>
>> Nun, die Frage stellt sich (wie immer): Was bezeichnest Du als gängige
>> Browser?
>
> Ich weiß, daher hatte ich das ja in Anführungszeichen gesetzt. Ich würde
> mal spontan sagen: FF, Chrome, IE, Safari... Auch die Browser von KDE
> und Gnome wären nicht schlecht.

Wenn du Letztere nennst, nimm bitte auch Opera inklusive seiner mobilen
Varianten dazu. Die User-Base dürfte insbesondere mobil um ein
Vielfaches größer sein.

Grüße,

Alex


--
http://www.schestag.de

Oliver Betz

ungelesen,
07.03.2013, 11:36:1207.03.13
an
Alexander Schestag schrieb:

>Ähm, du sprachst von XP-Usern, nicht von IE8-Usern per se. Es gibt schon
>auch noch IE8-User auf Windows 7. Aber XP-User, die auch IE 6 oder 7
>haben können - daher war das nicht eindeutig - sollten langsam
>aussterben. Das System wird nicht mal mehr mit Sicherheits-Updates
>versorgt. Das regelt also sowieso die freie Wildbahn.

ein gutes Jahr noch.

http://gs.statcounter.com/ meint, dass zur Zeit in Europa 7,6% IE8
unterwegs sind. Linear extrapoliert sind es in einem Jahr ca. 3%.
Weltweit ist der IE8-Anteil noch größer.

Servus

Oliver
--
Oliver Betz, Munich
despammed.com is broken, use Reply-To:

Gustaf Mossakowski

ungelesen,
07.03.2013, 11:39:2707.03.13
an
Magnus Warker schrieb:

> Es handelt sich um einen Schach-Server auf der Basis von GWT. Das Brett
> wird derzeit als Tabelle realisiert und die Figuren sind von fester
> Größe. Ich würde auf ein skalierbares Format umsteigen, wenn es von den
> "gängigen" Browsern unterstützt würde.

Skalieren die SVG-Dateien denn ordentlich? Ggf. kannst du auch einen
Webfont nehmen, der mit Zeichen aus einer Diagramm-Schriftart arbeitet.
Die skalieren vermutlich bei kleinen Schrifgrößen besser als
SVG-Grafiken.

Wenn du die Schrift so auf die Buchstaben mappst, dass das Schachbrett
auch ohne die Schriftart lesbar ist, können auch Leute mit älteren
Browsern etwas anfangen. Etwa KDTLSB für weiße Figuren und kdtlsb für
schwarze, leere Felder als Punkt. Ich hab das als alt-Texte für Grafiken
z. B. auf <http://www.schach-bremen.de/lehrbuch/italienisch.html>
verwendet. Dadurch kann man die Diagramme auch in Lynx lesen.

Viele Grüße
Gustaf

Arno Welzel

ungelesen,
07.03.2013, 12:24:3907.03.13
an
Susanne J�ger, 2013-03-07 14:20:

> Alexander Schestag schrieb am 07.03.2013 14:10:
>> Am 07.03.2013 09:49, schrieb Susanne J�ger:
>>
>>> IE9 als Voraussetzung hat halt das Problem, dass man damit die IE-Nutzer
>>> aussperrt, die noch XP nutzen. F�r Grundfunktionalit�t mag ich das noch
>>> nicht,
>>
>> Mittlerweile ist es eine Minderheit. Und deren Rechner sind eh �ber kurz
>> oder lang - eher kurz - offline, weil kompromittiert.
>
> Minderheit sicher, aber zu vernachl�ssigen?
> Ich habe keine Statistiken zur Hand, aber in meinem privaten Umfeld ist
> XP noch sehr weit verbreitet. IE6 auslisten lasse ich mir ja gefallen,
> aber 8 finde ich noch nicht gerechtfertigt - wie gesagt f�r
> Grundfunktionalit�t. Wenn es um spezielle - begr�ndbare Anwendungen
> geht, oder bestimmte Zusatzeffekte geht, kann das ganz anders aussehen.

XP vielleicht - aber auch XP mit IE?

Wenn ich mir die Statistiken meiner Website so ansehe, komme ich f�r den
IE 8 auf einen Anteil von etwa 7% (bei derzeit etwa 2000 Besuchern pro
Tag). "Weit verbreitet" w�rde ich das nicht gerade nennen. Auch �ber
alle Versionen zusammen kommt der IE kaum �ber 17% hinaus.

XP hat da auch nur noch einen Anteil von etwa 20% - und nein, ich
schreibe auf meiner Website nicht nur Computerthemen - eigentlich kommen
die meisten Leute wegen der Fahrrad-Artikel.

Arno Welzel

ungelesen,
07.03.2013, 12:26:1107.03.13
an
Susanne Jäger, 2013-03-07 14:55:

> Alexander Schestag schrieb am 07.03.2013 14:36:
>> Am 07.03.2013 14:20, schrieb Susanne Jäger:
>>> Alexander Schestag schrieb am 07.03.2013 14:10:
>>>> Am 07.03.2013 09:49, schrieb Susanne Jäger:
>>>
>>> Minderheit sicher, aber zu vernachlässigen?
>>> Ich habe keine Statistiken zur Hand, aber in meinem privaten Umfeld ist
>>> XP noch sehr weit verbreitet. IE6 auslisten lasse ich mir ja gefallen,
>>> aber 8 finde ich noch nicht gerechtfertigt
>>
>> Ähm, du sprachst von XP-Usern, nicht von IE8-Usern per se. Es gibt schon
>> auch noch IE8-User auf Windows 7.
>
> Auf IE8-Nutzer bei Win7 bin ich aber noch weniger bereit Rücksicht zu
> nehmen. Die *könnten* ja problemlos updaten. XP-Nutzer müssen Geld in
> die Hand nehmen

Nö - die müssen einfach nur einen anderen Browser installieren. Es gibt
genügend Alternativen, die auch unter XP gut funktionieren.

>> Aber XP-User, die auch IE 6 oder 7
>> haben können - daher war das nicht eindeutig - sollten langsam
>> aussterben.
>
> sollten vielleicht, aber langsam kann sich meiner Wahrnehmung nach noch
> 'ne ganze Weile hinziehen.

Diese Weile sind vielleicht noch 1-2 Jahre, wenn überhaupt.

Arno Welzel

ungelesen,
07.03.2013, 12:30:4107.03.13
an
Magnus Warker, 2013-03-05 16:03:

> Hallo,
>
> wann werden alle gängigen Browser HTML5 unterstützen, so dass man bei
> der Entwicklung von Web-Applikationen darauf aufsetzen kann?
>
> Ist das absehbar oder steht das in den Sternen?

Ergänzend zu den übrigen Beiträgen dazu:

<http://mip.noekeon.org/HTMLTTChess/index.html>

Auch wenn man das Paket nicht komplett so benutzen will - der Font ist
auf jeden Fall interessant und Freeware.

G.Bundschuh

ungelesen,
10.03.2013, 09:13:2510.03.13
an
Magnus Warker schrieb:

> Hier eine kleine Konkretisierung: Mir geht es speziell um die Verwendung
> von HTML5-Canvas zur Darstellung eines Schachbretts. Die bisherige Methode
> mit Tabellen und CSS hat gewisse Nachteile, die durch HTML5-Canvas behoben
> würden.

<https://developer.mozilla.org/en-US/demos/detail/chess>

Bin gerade zufällig über das hier gestoßen. Habe es mir nicht
näher angesehen, vielleicht das was Du suchst?

mfg Gerd

0 neue Nachrichten