Ich bin mir nicht sicher, ob dies beabsichtigtes Verhalten oder ein Fehler ist, aber die %-Buttons zum Skalieren von Bildern und die eigentliche Skalierung funktionieren nicht mehr, wenn ein Bild keinen Alternativtext hat. Das funktionierte vor einem kürzlichen (ca. einer Woche?) Update noch.
Wenn in einem Beitrag mehrere Bilder vorhanden sind und eines davon keinen Alternativtext hat, ändert das Klicken auf dessen %-Buttons die Skalierung für ein anderes Bild, das einen Alternativtext hat (EDIT: Ich habe die Kategorie gerade zu bug geändert, denn selbst wenn der Alternativtext erforderlich wäre, sollte dies nicht passieren).
Das funktioniert nicht, funktionierte aber früher: 
Das Hinzufügen des alt|-Teils vor der Bildgröße behebt das Problem, wie erwartet.
Ich muss einige Themen aktualisieren, um mich daran anzupassen – andernfalls wären diese Bilder bei einer späteren Neuberechnung zu 100 % groß. Mir ist aufgefallen, dass dies auch bei anderen der Fall sein könnte, daher dieser Beitrag.
Es hat funktioniert, ich habe mehrere Themen in meiner Instanz mit der korrekten Skalierung, denen jedoch der Alt-Text fehlt. Wenn ich eines davon neu bereite, ist die Skalierung weg.
Ich konnte jedoch nichts finden, das den Unterschied beim Kochen von Beiträgen erklären würde.
Es macht mir nichts aus, diese Themen zu bearbeiten, aber andere könnten ebenfalls auf diese Situation stoßen, und die Größenanpassungssteuerelemente für das Bild ohne alt-Attribut sollten die Skalierung eines anderen Bildes nicht ändern.
Ja, sieht so aus, als käme das von meiner Änderung. Ich ging davon aus, dass die vorherige Implementierung ein Fehler war. Alle unsere Tests gehen davon aus, dass die Dimensionen nach einem |-Zeichen stehen:
Ich könnte uns auf das alte Verhalten zurücksetzen und einen Test hinzufügen, um sicherzustellen, dass es weiterhin funktioniert. Das würde jedoch bedeuten, dass man niemals ein Bild mit Alt-Text wie 123x123 haben könnte.
@renato, weißt du, wie es dazu kam, dass im Markdown kein Pipe-Zeichen enthalten ist? Soweit ich weiß, sollten alle UI-Optionen eines mit einem Pipe-Zeichen generieren
Ja, die Beiträge, bei denen ich dieses Verhalten bemerkt habe, wurden alle über die API erstellt, wobei ein voreingestellter Rohinhalt verwendet wurde, der zuvor in der UI getestet worden war. Ich habe absichtlich die Alternativtexte zweier Bilder entfernt, die für einen Screenreader wenig Sinn ergeben würden.
Es macht mir nichts aus, mich an das neue Verhalten anzupassen, falls ihr euch dafür entscheidet.
Off-Topic: Darf ich nach einer Plugin-Empfehlung fragen, die [etwas] in einen Rohinhalt umwandelt, als Inspiration für ein eigenes Plugin? Auf diese Weise könnte ich einfach eine weitere Bearbeitung aller dieser Themen vornehmen, und falls ich sie später erneut ändern muss, wäre ein Neubearbeiten (Rebake) ausreichend.
Ja, ich denke, es ist besser, sich hier an die neue Vorgehensweise anzupassen. Wir haben nie wirklich vor gehabt, dies zu unterstützen. Eine breitere Unterstützung für mehr Formate bedeutet mehr Code im Backend und mehr Tests.
OK, ich werde den Vorschlag beibehalten, die Skalierungstasten nur bei Bildern anzuzeigen, die skaliert werden können.
Ah ja, für diese spezifische Änderung kann ich das tun, danke. Übrigens ist dies nicht der einzige Ort, an dem ich einen voreingestellten Rohinhalt habe, der von einem externen Dienst verwaltet wird. Vielleicht könnte ich mir Ideen aus poll holen – oder falls dir ein einfacheres Beispiel einfällt, lass es mich bitte wissen.
Vielen Dank und entschuldige das ganze Getöse wegen dieses kleinen Problems.
