type="range" - val während des Schiebens

[ralphi]

Hi Leute,

Ein Regler sollte mir einen Sollwert einstellen.
Irgendwie bekomme ich es bei FF und Chrom nicht hin, dass er während des regelns das Change-Event auslöst. Nur beim IE11 klappts.

Also, dass er mir schon während des schieben, nicht erst beim loslassen, der Maustaste, den Val ausgibt.

$("#slider").change(function () {  
        $('#neu_wert').text (this.value);  
});

<div id ="control">  
        <span id="neu_wert" class="text_L"></span><br>  
        <input id="slider" type="range" min="18" max="25" step="0.5" orient="vertical"  />  
</div>

Habs auch schon mit  onchange=”outputUpdate(value)” probiert.
Immer erst beim Loslassen der Maustaste gibt er den Wert aus.

Mal was anderes, dass der IE was macht, was die Anderen nicht können ;-|
Was kann ich machen, dass es bei allen Browsern klappt ?
Viele Grüße aus LA

[1UnitedPower]

Meine Damen und Herren, habe ich Ihre Aufmerksamkeit?

Du suchst vermutlich das input-Event: http://jsfiddle.net/uxzhempy/

[ralphi]

Du suchst vermutlich das input-Event: http://jsfiddle.net/uxzhempy/

krass man - klappt :-)
http://jsfiddle.net/uxzhempy/1/

warum, will ich gar nicht wissen ;-)

Viele Grüße aus LA

[Gunnar Bittersmann]

@@ralphi:

nuqneH

Du suchst vermutlich das input-Event: http://jsfiddle.net/uxzhempy/

krass man - klappt :-)
warum, will ich gar nicht wissen ;-)

Kam gerade übern Ticker: onchange vs. oninput for Range Sliders

Qapla'

[ralphi]

@@Gunnar: Doppelposting

Bleib bitte in deinem Thread.

Hast ja recht.
Denk aber dran, dass auch Besucher von Google kommen.
Da taucht nicht zwangsläufig dieses Posting auf, wenn er Browserweiche eintippt.

benötigt man tatsächlich noch die Info, auf welchem Browser man ist.
Nein.

Trotzdem, auf das Posting antworten und dann sperren, ist inkonsequent und unhöflich :-|

Was meinst du mit nein?
Was machst du dann, wenn es heißt:
„IE11 bug report on missing input event, still unresolved.“

nun, ich schreibe jetzt:
if ( checkBrowserName('MSIE') || checkBrowserName('NET') ) {
In der Hoffnung, das NET bei keinem anderen Browser vorkommt.

Viele Grüße aus LA

[MudGuard]

Hi,

if ( checkBrowserName('MSIE') || checkBrowserName('NET') ) {

nicht auf einen Browsernamensteil testen, sondern ob das zu benutzende Feature zur Verfügung steht!

In der Hoffnung, das NET bei keinem anderen Browser vorkommt.

Dann braucht man auch nicht hoffen ...

cu,
Andreas

[Gunnar Bittersmann]

@@MudGuard:

nuqneH

nicht auf einen Browsernamensteil testen, sondern ob das zu benutzende Feature zur Verfügung steht!

Schön wär’s, aber 'oninput' in input* liefert im IE 11 true.

Qapla'

* var input = document.querySelector("input"); wie im Fiddle

[ralphi]

Hi,

Schön wär’s, aber 'oninput' in input* liefert im IE 11 true.

Nun - es funktioniert.
code von Gunnar bei mir:

// Sollwert festlegen *******************************************************  
var input = document.querySelector("input");  
  
function showSliderValue() {  
		if ( val_aktuell != 0 ) {  
			var newValue = this.value;  
			$('#neu_wert').text (newValue); // schreibe aktuellen Wert  
			 data.setValue(row_aktuell, 1, newValue);  
			 data.setValue(row_aktuell, 2, farbe(newValue) );  
			 werte_rechnen(row_aktuell,newValue); // ziehe auch Nachbarbalken mit  
			 chart.draw(data, options); // google Diagram  
		}  
}  // Selected Balken verändern  
input.addEventListener('input', showSliderValue, false);  
input.addEventListener('change', showSliderValue, false);  

tatsächlich wird beim IE beides durchlaufen.
Aber es funktioniert - sowol beim IE11, Firefox und chrom. Die Werte gehen mit dem Slider bei Veränderung sofort mit.

NUR ZUFALL ??

Viele Grüße aus LA

[Gunnar Bittersmann]

@@ralphi:

nuqneH

Schön wär’s, aber 'oninput' in input* liefert im IE 11 true.

Nun - es funktioniert.

War deine Antwort bewusst auf die Zeile darüber bezogen? Du hast 'oninput' in input nirgends eingebaut.

Aber das war es wohl, was MudGuard mit „nicht auf einen Browsernamensteil testen, sondern ob das zu benutzende Feature zur Verfügung steht!“ im Sinn hatte:

if (inputEventSupported)  
{  
  input.addEventListener('input', showSliderValue, false);  
}  
else  
{  
  input.addEventListener('change', showSliderValue, false);  
}

Der Test, ob das input-Event zur Verfügung steht, wäre wohl

var inputEventSupported = 'oninput' in input;  

Nur dass das als Test nicht taugt, weil das auch im IE 11 true liefert, obwohl er das input-Event nicht feuert.

input.addEventListener('input', showSliderValue, false);
input.addEventListener('change', showSliderValue, false);

tatsächlich wird beim IE beides durchlaufen.

In anderen Browsern auch.

Aber es funktioniert - sowol beim IE11, Firefox und chrom. Die Werte gehen mit dem Slider bei Veränderung sofort mit.

NUR ZUFALL ??

Nein, kein Zufall.

Standardkonforme Browser ändern bei jedem input-Event (Ziehen des Sliders) den Wert und danach beim change-Event (Loslassen des Sliders) nochmal. Davon geht die Welt nicht unter.

IE 11 feuert beim Ziehen des Sliders das change-Event (was nicht standardkonform ist) und ändert den Wert. Das input-Event feuert er gar nicht.

Qapla'

[MudGuard]

Hi,

nicht auf einen Browsernamensteil testen, sondern ob das zu benutzende Feature zur Verfügung steht!
Schön wär’s, aber 'oninput' in input* liefert im IE 11 true.

Da paßt ja das Uralt-Zitat, das Du wieder ausgegraben hast, wie die Faust auf's Auge ...

cu,
Andreas

[Gunnar Bittersmann]

@@ralphi:

nuqneH

Denk aber dran, dass auch Besucher von Google kommen.
Da taucht nicht zwangsläufig dieses Posting auf, wenn er Browserweiche eintippt.

Das ist auch gut so. „Browserweiche“ ist auch nicht das Thema. Du suchst eine Lösung für dein Problem. Browserweiche ist keine. Für kein Problem.

Trotzdem, auf das Posting antworten und dann sperren, ist inkonsequent und unhöflich :-|

Es ist konsequent, wie du schon in der Charta gelesen hast. Unhöflich ist es, diese nicht zu beachten.

Was meinst du mit nein?
Was machst du dann, wenn es heißt:
„IE11 bug report on missing input event, still unresolved.“

Die Funktion showSliderValue bei beiden Events aufrufen:

function showSliderValue()  
{  
  // …  
}  
  
input.addEventListener('input', showSliderValue, false);  
input.addEventListener('change', showSliderValue, false);

Keine Browserweiche. Problem gelöst.

Qapla'

PS: Im Übrigen wäre die richtige Methode IE zu erkennen nicht per UA-String, sondern per [link:http://forum.de.selfhtml.org/archiv/2012/1/t208553/#m1418873@title=document.documentMode].

[ralphi]

Trotzdem, auf das Posting antworten und dann sperren, ist inkonsequent und unhöflich :-|

Sorry -  Missverständnis.

Die Funktion showSliderValue bei beiden Events aufrufen:

function showSliderValue()

{
  // …
}

input.addEventListener('input', showSliderValue, false);
input.addEventListener('change', showSliderValue, false);

>   
> Keine Browserweiche. Problem gelöst.  

DIE Antwort ist hilfreich - danke :-)  
  
Viele Grüße aus LA

-- 
ralphi

[Mitleser]

Das ist auch gut so. „Browserweiche“ ist auch nicht das Thema. Du suchst eine Lösung für dein Problem. Browserweiche ist keine. Für kein Problem.

Für "kein Problem" ist falsch.

[Gunnar Bittersmann]

@@Mitleser:

nuqneH

Das ist auch gut so. „Browserweiche“ ist auch nicht das Thema. Du suchst eine Lösung für dein Problem. Browserweiche ist keine. Für kein Problem.

Für "kein Problem" ist falsch.

Du implementierst also eine Browserweiche für … – ja für wen eigentlich?

Für IE 11? Was ist, wenn IE 12 den Bug immer noch hat?

Für IE ab 11? Was ist, wenn IE 12 den Bug nicht mehr hat?

Du siehst, Browserweichen sind selten eine gute Idee. Sie schaffen oft mehr Probleme als sie lösen.

Qapla'

[Mitleser]

Du implementierst also eine Browserweiche für … – ja für wen eigentlich?

Für einen Browser, der wo einen Bug hat.

Für IE 11? Was ist, wenn IE 12 den Bug immer noch hat?

Falls das jetzige Sniffing den IE 12 nicht erkennen wird: weiteres Sniffing, um den IE 12 zu erkennen.

Für IE ab 11? Was ist, wenn IE 12 den Bug nicht mehr hat?

Dann werde ich mich freuen und die Weiche entsprechend anpassen, sollte Sie denn für IE 12 überhaupt anschlagen. Der Bugreport ist eingereicht, es gibt Hoffnung.

Du siehst, Browserweichen sind selten eine gute Idee. Sie schaffen oft mehr Probleme als sie lösen.

"Selten" habe ich nie bestritten, "nie" hingegen schon.

[Gunnar Bittersmann]

@@Mitleser:

nuqneH

Für IE 11? Was ist, wenn IE 12 den Bug immer noch hat?

Falls das jetzige Sniffing den IE 12 nicht erkennen wird: weiteres Sniffing, um den IE 12 zu erkennen.

Für IE ab 11? Was ist, wenn IE 12 den Bug nicht mehr hat?

Dann werde ich mich freuen und die Weiche entsprechend anpassen, sollte Sie denn für IE 12 überhaupt anschlagen. Der Bugreport ist eingereicht, es gibt Hoffnung.

Also immer schön auf dem Laufenden bleiben, ja kein Browserupdate verpassen und bei jeder neuen Browserversion testen und gegebenenfalls das Stylesheet ändern. In allen Projekten.

Wartbarer Code geht anders.

Qapla'

[Mitleser]

Also immer schön auf dem Laufenden bleiben, ja kein Browserupdate verpassen und bei jeder neuen Browserversion testen und gegebenenfalls das Stylesheet ändern. In allen Projekten.

Wartbarer Code geht anders.

Alles schön und gut, sauber auf den Punkt gebracht! Aber hast Du denn für das genannte Beispiel konkret einen besseren Vorschlag? Ich bin gespannt...

[ralphi]

Hi mitleser,

Alles schön und gut, sauber auf den Punkt gebracht! Aber hast Du denn für das genannte Beispiel konkret einen besseren Vorschlag? Ich bin gespannt...

ja hat Gunnar :-)

var input = document.querySelector("input");  
function showSliderValue()  
{  
  // …  
}  
  
input.addEventListener('input', showSliderValue, false);  
input.addEventListener('change', showSliderValue, false);  

Ich denke auch das „NIE“ von Gunnar, bezieht sich auf die Funktionalität des Codes.

Wenn man Layout Probleme zB. mit HTML5 <audio controls>, könnte tatsächlich eine Browserweiche noch nützlich sein.

Viele Grüße aus LA

[Mitleser]

Alles schön und gut, sauber auf den Punkt gebracht! Aber hast Du denn für das genannte Beispiel konkret einen besseren Vorschlag? Ich bin gespannt...

ja hat Gunnar :-)

Auf das von mir skizzierte Problem? Unwahrscheinlich, aber ich bleibe gespannt und voller Hoffnung.

Wenn man Layout Probleme zB. mit HTML5 <audio controls>, könnte tatsächlich eine Browserweiche noch nützlich sein.

Glaube ich jetzt eher nicht. Die einzigen wirklich nötigen Weichen sind IMHO jene zur Umgehung fieser Bugs.

[Gunnar Bittersmann]

@@Mitleser:

nuqneH

Du suchst eine Lösung für dein Problem. Browserweiche ist keine. Für kein Problem.

Für "kein Problem" ist falsch.

Ach was. ;-)

In der Tat ein äußerst merkwürdiges Verhalten des IE 11. Bei 43deg tritt der Fehler auf, bei 42deg nicht, bei 44deg nicht. Bei 43.1deg auch nicht, wohl aber bei 42.9deg. Bei 42.8deg nicht. Weiß der Geier, was da möglicherweise für ein Rundungsfehler im Spiel ist.

Hast du den Bug schon gemeldet?

Bei 'transform: rotate(43deg) scale(1.001)' ist der Rahmen sehen. Wäre das eine Option?

Qapla'

[Mitleser]

In der Tat ein äußerst merkwürdiges Verhalten des IE 11. Bei 43deg tritt der Fehler auf, bei 42deg nicht, bei 44deg nicht. Bei 43.1deg auch nicht, wohl aber bei 42.9deg. Bei 42.8deg nicht. Weiß der Geier, was da möglicherweise für ein Rundungsfehler im Spiel ist.

Sowas in der Richtung wird es sein. Die Drehung _alleine_ ist es allerdings nicht. Der Bug tritt (für mich) unvorhersehbar in irgendwelchen Kombinationen aus Breite/Höhe/Rotation(ausgenommen die "geraden" Winkel 0, 90, 180) auf. Ändert man dann _einen_ der Parameter "oft genug", erscheint das Rahmenbild.

Hast du den Bug schon gemeldet?

Ja, die Herrschaften haben ihn auch mit der Standardantwort "Thank you for your feedback. We will be investigating this issue further." akzeptiert. Im IE12 wird das wohl behoben sein, schätze ich.

Bei 'transform: rotate(43deg) scale(1.001)' ist der Rahmen sehen. Wäre das eine Option?

Damit wäre es für genau die Gradzahl/Breite/Höhe behoben. Tatsächlich passiert die ganze Aktion innerhalb einer Gui. Die Parameter sind daher beliebig und das Rahmenbild (als animierte Grafik) wichtig, keine Verzierung oder ähnliches. Ich hatte mich bereits an einer Heuristik versucht, um die Situation zu erkennen. Wie zu erwarten war: erfolglos. Selbst wenn, wäre das eigentlich Mist: unnötige Penalty für alle anderen Clients.

Würde der Fallback der Rahmenfarbe bei Eintritt des Bugs greifen, wäre es egal. Mit einig Programmiererempathie durchaus logisch, dass er nicht greift. Wenn nun aber weder Animation noch statischer Rahmen erscheine, ist es für den User halt schlicht ein Fail. Da fiel mir nur noch sniffen ein: dann eben kein border-image für IE11.

Qapla'

Bleibt die Frage: wie löse ich das denn jetzt ohne die "never ever nötige" Browserweiche? Häh? ;-)

[Gunnar Bittersmann]

@@Mitleser:

nuqneH

Bei 'transform: rotate(43deg) scale(1.001)' ist der Rahmen sehen. Wäre das eine Option?

Damit wäre es für genau die Gradzahl/Breite/Höhe behoben.

Die Frage ist: Tritt der Bug dann noch für andere Drehwinkel/Breiten/Höhen auf?

Selbst wenn, wäre das eigentlich Mist: unnötige Penalty für alle anderen Clients.

Ändert sich denn der Drehwinkel ständig? Die Transformationsmatrix muss ja für die Drehung sowieso berechnet werden. Für die Skalierung käme lediglich einmalig (für einen Drehwinkel) eine Matrixmultiplikation hinzu; das sollte zu verschmerzen sein.

Da fiel mir nur noch sniffen ein

Wie man das mit JavaScript tut, hatte ich bereits verlinkt (im PS) und auf Risiken & Nebenwirkungen hingewiesen.

Bleibt die Frage: wie löse ich das denn jetzt ohne die "never ever nötige" Browserweiche? Häh? ;-)

scale(1.001). Bitteschöngerngeschehen. ;-)

Qapla'

[Mitleser]

Die Frage ist: Tritt der Bug dann noch für andere Drehwinkel/Breiten/Höhen auf?

Ja, beliebig viele. Ich vergaß eben noch die Positionswerte als weitere Variablen.

Ändert sich denn der Drehwinkel ständig? Die Transformationsmatrix muss ja für die Drehung sowieso berechnet werden. Für die Skalierung käme lediglich einmalig (für einen Drehwinkel) eine Matrixmultiplikation hinzu; das sollte zu verschmerzen sein.

Potentiell ja, es ist eine Gui: der User kann beliebige Kombinationen erzeugen. Pauschal scale 1.001 hilft nicht, auch damit kann man den Bug provozieren, sobald man die Variablen ändert. Wenn Du mir die passende Formel für die Matrix nennen kannst, immer her damit. Mein aktueller Ansatz lautet so: "scale = (Quadratwurzel aus pi * breite + cos höhe / rotation hoch top) - 42"

Da fiel mir nur noch sniffen ein
Wie man das mit JavaScript tut, hatte ich bereits verlinkt (im PS)

Das ist schön, war aber nicht die Frage. Eigentlich mag ich den auch nicht, weil er nicht die Version des Browsers, sondern den aktuellen Kompatibilitätsmodus bestimmt. Für den hiesigen Fall wäre er aber geeignet, danke für den Input.

und auf Risiken & Nebenwirkungen hingewiesen.

Seufzt, ja hast Du. Mit Recht. Inwiefern hilft das hier weiter?

Bleibt die Frage: wie löse ich das denn jetzt ohne die "never ever nötige" Browserweiche? Häh? ;-)
scale(1.001). Bitteschöngerngeschehen. ;-)

Vielen Dank, es ist aber leider nicht die Lösung. Der bislang beste Kompromiss lautet weiterhin sniffen, so böse das auch ist. Ja, Du hast gut erklärt, warum es böse ist ;-)

[Mitleser]

Vielen Dank, es ist aber leider nicht die Lösung. Der bislang beste Kompromiss lautet weiterhin sniffen, so böse das auch ist. Ja, Du hast gut erklärt, warum es böse ist ;-)

Bis zum Beweis des Gegenteils halten wir also fest: ja, es gibt Fälle, in denen Browserweichen Sinn machen.

[Gunnar Bittersmann]

@@Mitleser:

nuqneH

Ändert sich denn der Drehwinkel ständig? Die Transformationsmatrix muss ja für die Drehung sowieso berechnet werden. Für die Skalierung käme lediglich einmalig (für einen Drehwinkel) eine Matrixmultiplikation hinzu; das sollte zu verschmerzen sein.

Potentiell ja, es ist eine Gui: der User kann beliebige Kombinationen erzeugen.

Was auch egal wäre. Die Transformationsmatrix wird einmalig bei Änderung des Drehwinkels berechnet und dann auf alle Punkte angewandt.

Pauschal scale 1.001 hilft nicht, auch damit kann man den Bug provozieren, sobald man die Variablen ändert.

Womit die Idee hinfällig ist. Schade, hätte ja sein können.

Wenn Du mir die passende Formel für die Matrix nennen kannst, immer her damit. Mein aktueller Ansatz lautet so: "scale = (Quadratwurzel aus pi * breite + cos höhe / rotation hoch top) - 42"

Das ist nur geringfügig genauer als π × 👍.

Richtig genau wird’s so.

Qapla'

[Matthias Apsel]

Om nah hoo pez nyeetz, ralphi!

Trotzdem, auf das Posting antworten und dann sperren, ist inkonsequent und unhöflich :-|

Antworter und Sperrer waren zwei verschiedene Personen.

Warum sollte es inkonsequent sein? Hätte dir eine Sperre ohne jeglichen Hinweis besser gefallen?

Matthias

[ralphi]

Antworter und Sperrer waren zwei verschiedene Personen.

Falsche Schlussfolgerung. @gunnar - sorry

Warum sollte es inkonsequent sein? Hätte dir eine Sperre ohne jeglichen Hinweis besser gefallen?

Nein - Hinweis ist natürlich OK.
ZB. „Diese Frage beinhaltet das vorherigen Posting xy und kann dort geklärt werden“
und dann sperren - klar.

Meine Absicht war nicht, eine Antwort zu nötigen. Dachte nur, dass Browserweichen und das derzeit übliche Vorgehen unabhängig von Slidern, ein eigenes Thema rechtfertigt.

Wie sich rausstellt, sind die Antworten jetzt sehr hilfreich - danke.
Ob es sich lohnt, dass als eigenen Thread durchgehen zu lassen - weiß jetzt auch nicht mehr ;-)

Viele Grüße aus LA