Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.javascript > #4655

Re: Browsereinstellungen abfragen

Show all headers | View raw

Hermann Riemann wrote:

> Thomas 'PointedEars' Lahn schrieb:
>>> An den Hervorhebstellen:
>>> Ein script mit document.write(diverse Abhängigkeiten)
>>> und ein <noscript> mit etwas <h1> bis <h6>
> 
>> Bitte nicht.
> 
> Warum nicht?

- document.write(…) blockiert das Rendern.

  Siehe unter anderem:
  <https://developers.google.com/speed/docs/insights/BlockingJS>

  Man kann das machen, wenn man weiss was man tut.  Ich zum Beispiel
  verwende document.write() intensiv in der ECMAScript Support Matrix,
  wenn andere Möglichkeiten, Inhalte einzufügen, nicht verfügbar sind;
  und in anderen (allerdings in letzter Zeit kaum gewarteten, und damit
  potentiell veralteten) Teilen meiner Website für Alternativtext −
  dort kommt dieser aber nur in einem Segment des Dokuments vor.

- Das noscript-Element hat nichts mit dem Support für eine *spezifische*
  Scriptsprache zu tun.

  Siehe unter anderem:
  <http://webaim.org/techniques/javascript/alternatives>
  <https://www.seroundtable.com/archives/022411.html>

- Die hX-Elemente sind für Überschriften gedacht und nicht (bloss) für
  grosse (bzw. formatierte) Schrift:

  <http://www.w3.org/QA/Tips/Use_h1_for_Title>
  <http://www.w3.org/QA/Tips/headings>

Die *Kombination* dieser Features in Deinem Vorschlag macht ihn zu grobem 
Unfug.

> Hermann
>    der mit document.write Text zeigt,
>    der nur mit eingeschaltetem JavaSript sichtbar ist:
>    siehe:
> http://www.hermann-riemann.de/u/fremd.html
> http://www.hermann-riemann.de/u/fremd.b.js

Mehrfaches document.write[ln]() ist Unfug (Konkatenation und 
Array.prototype.join() existieren), und Elemente mit Scripting zu 
generieren, nur weil sie Event-Handler-Attribute enthalten, auch.

Man kann Event-Handler-Attribute in den originalen HTML-Quelltext schreiben, 
dann werden sie ignoriert, wenn kein Scripting-Support vorhanden ist.  Oder 
man kann Event-Listener dynamisch hinzufügen, dann wird der Code, der sie 
hinzufügt, nicht geladen und/oder nicht ausgeführt, wenn kein Scripting-
Support vorhanden ist.  Der letztere Ansatz, der Teil des insgesamt jedoch 
fragwürdigen Konzepts “Unobtrusive JavaScript” ist, ist dann gerechtfertigt, 
wenn Event-Handler-Attribute den Quelltext aufblähen und somit signifikant 
ineffizienter und/oder wartungsintensiver machen würden, oder wenn auf 
Events reagiert werden muss, die nicht bubblen oder wo ein zentraler Event-
Listener ineffizient oder übermässig komplex wäre.

Deine vielen Formulare sind auch nicht besonders sinnvoll; das kann
man mit *einem* Formular lösen, in dem alle Steuerelemente enthalten und 
mindestens einige geeignet benannt sind.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

Back to de.comp.lang.javascript | Previous | Next — Previous in thread | Find similar

Thread

Re: Browsereinstellungen abfragen Hermann Riemann <nospam.ng@hermann-riemann.de> - 2015-07-27 07:36 +0200
  Re: Browsereinstellungen abfragen Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-07-27 15:22 +0200
    Re: Browsereinstellungen abfragen Axel_Berger@b.maus.de (Axel Berger) - 2015-07-27 20:46 +0200
      Re: Browsereinstellungen abfragen Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-07-28 12:44 +0200
    Re: Browsereinstellungen abfragen Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-07-29 23:02 +0200

csiph-web