progress – Bug in Chrome?

[Gunnar Bittersmann]

@@alle:

nuqneH

Habe as Fallback fürs progress-Element im Stylesheet:
progress::after { content: attr(value) }

Browser, die progress kennen, zeigen den Balken; die es nicht tun, zeigen den Wert (es sei denn, sie können gar keinen generierten Inhalt).

So ist’s im Fuchs, so war’s in Chrome – bis vor Kurzem. Jetzt stellt Chrome beides dar. Darf der das?

Sollte <progress value="0.42"></progress> mit diesem Stylesheet nicht äquivalent sein zu <progress value="0.42"><_after>0.42</_after></progress>?

Wenn der Inhalt des progress-Elements nicht per CSS generiert wird, sondern im HTML steht, stellt Chrome diesen richtigerweise nicht dar.

Wie kriege ich Chrome dazu, auch CSS-generierten Inhalt nicht anzuzeigen?

Qapla'

[Felix Riesterer]

Lieber Gunnar Bittersmann,

Chrome kann jetzt per Update Werbung und Malware (via fefe). Warum sollte man tatsächlich für diesen Browser noch irgendeinen Finger krumm machen?

Oder meintest Du Chromium?

Liebe Grüße,

Felix Riesterer.

[Gagamehl]

Lieber Gunnar Bittersmann,

Chrome kann jetzt per Update Werbung und Malware (via fefe). Warum sollte man tatsächlich für diesen Browser noch irgendeinen Finger krumm machen?

Oder meintest Du Chromium?

Gibt es bei Chromium kein Auto-Update für die Extensions?

[Felix Riesterer]

Lieber Gagamehl,

Gibt es bei Chromium kein Auto-Update für die Extensions?

das weiß ich nicht, weil ich diesen Browser nicht verwende.

Liebe Grüße,

Felix Riesterer.

[M.]

Mahlzeit,

das weiß ich nicht, weil ich diesen Browser nicht verwende.

Der macht es genau so wie Chrome. Am besten wir benutzen jetzt gar keine OS-Software mehr, die sind doch, aufgrund deines verlinkten Artikels, praktisch pauschal böse, weil bei JEDER Software gleiches Verhalten auftreten kann.

Verdammt, das trifft ja nicht nur auf OS zu sondern auf alles. Also am besten jede Software meiden und alle Computer verbrennen.

[Gagamehl]

Gibt es bei Chromium kein Auto-Update für die Extensions?

das weiß ich nicht, weil ich diesen Browser nicht verwende.

Dann hast Du, indem Du impliziert hast, dass Chromium das Problem mit den gekauften Extensions nicht hat, sehr unglücklich ausgedrückt.

[molily]

Hallo,

Chrome kann jetzt per Update Werbung und Malware (via fefe). Warum sollte man tatsächlich für diesen Browser noch irgendeinen Finger krumm machen?

Hast du den Artikel eigentlich gelesen?

Dasselbe könnte im Prinzip genauso bei Firefox, Internet Explorer oder Safari passieren. Dort ist auch nicht ausgeschlossen, dass jemand die Developer-Accounts für Extensions an jemand anderen verkauft und dieser den Code verändert. Wieso sollte man die an sich harmlose und legitime technische Möglichkeit, eine Extension für andere Developer zu öffnen oder komplett zu übertragen, auch limitieren? Das passiert täglich tausendfach ohne die Absicht, Benutzern Malware unterzujubeln.

Mathias

[M.]

Mahlzeit,

Warum sollte man tatsächlich für diesen Browser noch irgendeinen Finger krumm machen?

Juchu .... endlich wieder Browserbashing ....
Also mein FF fragt zwar ob er nach Updates suchen soll, aber wenn der Besitzer gewechselt hat oder Malware enthalten ist, bekomm ich das auch nicht mit.

Welchen Browser darf man denn dann noch nutzen?

[molily]

Hallo,

Der Inhalt des progress-Elements selbst ist mit dem Shadow-DOM umgesetzt. Warum Textknoten, die Geschwister des Shadow-Roots sind, versteckt werden, aber ::before/::after mit content gezeigt werden, kann ich mir nicht erklären. Ich bezweifle, dass es im Rahmen von HTML und CSS da einen Workaround gibt.

Ich würde das einfach als Bug melden. Ich vermute aber, dass das u.U. sogar gewolltes Verhalten ist. Die Annahme, dass ::after/content *nicht* dargestellt wird, halte ich zwar für folgerichtig, aber man kann auch anderer Ansicht sein.

Ein brauchbarer Workaround wäre wahrscheinlich nur, die Unterstützung von progress mit JavaScript abzufragen.

Mathias

[Gunnar Bittersmann]

@@molily:

nuqneH

Ein brauchbarer Workaround wäre wahrscheinlich nur, die Unterstützung von progress mit JavaScript abzufragen.

Oder einfach mit JavaScript den value-Wert in den Elementinhalt kopieren (dieser wird ja von Chrome nicht dargestellt):

for (var progressElements = document.querySelectorAll("progress"), i = 0; i < progressElements.length; i++)  
{  
  progressElements[i].innerHTML = progressElements[i].value;  
}

Dann kann man auch gleich in Prozent umrechnen und auch max ungleich 1 berücksichtigen:

for (var progressElements = document.querySelectorAll("progress"), i = 0; i < progressElements.length; i++)  
{  
  progressElements[i].innerHTML = Math.round(parseFloat(progressElements[i].value / (progressElements[i].max || 1)) * 100) + "%";  
}

Qapla'

[Gunnar Bittersmann]

@@Gunnar Bittersmann:

nuqneH

Die Rechnung hab ich ohne Browser gemacht, die progress nicht kennen, damit auch nicht deren value. Die liefern im ersten Fall undefined, im zweiten dann "NaN%".

Mit progressElements[i].getAttribute("value") statt progressElements[i].value geht’s dann.

Qapla'

[Gunnar Bittersmann]

@@Gunnar Bittersmann:

nuqneH

progressElements[i].innerHTML = Math.round(parseFloat(progressElements[i].value / (progressElements[i].max || 1)) * 100) + "%";

Das parseFloat() ist an der Stelle natürlich auch unsinnig. Aber wem erzähle ich das?

Qapla'

[Tim Tepaße]

Browser, die progress kennen, zeigen den Balken; die es nicht tun, zeigen den Wert (es sei denn, sie können gar keinen generierten Inhalt). So ist’s im Fuchs, so war’s in Chrome – bis vor Kurzem. Jetzt stellt Chrome beides dar. Darf der das?

Ich würde sagen ja. Setzt man sich den Taucherhelm auf und schreitet hinab in die Tiefen des Web Inspector, sieht man ja, dass der Balken von <progress> durch die Methoden von Web Components, sprich des Shadow DOMs erstellt wird. Liest man diese sagenhaft unlesbare Spec quer, dann fällt eines auf: die ganze schattige Geschichte ist a) unfassbar kompliziert und b) passiert nur auf der Ebene des DOMs. Um das zu rekapitulieren:

• <progress> wird (in Chromium/Blink irgendwo bei der tree-construction-Phase zu einem shadow host umfunktioniert und in diesen werden die shadow-tree-Elemente eingefügt.

• Beim Deklarieren eines shadow roots bei einem Elementes wird dieses zu einem shadow host. Sobald das geschieht, werden dessen Kindelemente nicht mehr förmlich gerendert (denn das übernimmt der shadow root) und werden in einen Pool für die shadow roots eingefügt, existieren aber weiterhin in einem merkwürdigen Zwischenreich noch auf DOM-Ebene, sozusagen als eine Form von API, um Inhalte in einem shadow tree einfügen zu können. Bei einem <x-carousel> z.B. die Bilder.

• Eine shadow-DOM-Implementierung von <progress> hat per Spec keine Einfügepunkte für Kindelemente, also sind diese durch schattige Magie einfach weg.

• Das gilt aber nicht für Pseudoelemente. Der ganze Styling-Prozess passiert ja „später“ als die Shadowifizierung. Diese kann, weil auf dem DOM arbeitend, keine Aussagen über spätere Pseudoelemente treffen und sollte es vermutlich auch nicht. Schließlich sind Pseudoelemente ein beliebtes Stylingmittel unter Autoren und man kann sich dazu halbwegs sinnvolle Anwendungsfälle vorstellen. Das ist wiederum die Sicht von aussen auf ein progress-Element, dessen shadow-DOM-Implementierung man nicht sieht, es sich also wie älteres replaced element anfühlt, bei dem Pseudoelemente ja auch nicht verboten wären.

• Meinem Halbwissen zufolge, nachdem ich jetzt anderthalb Stunden mit dieser ekligen Spec und Rumgoogelei verbracht habe, wäre also Chrome hier richtig und Safari und Firefox lägen falsch.

ALLERDINGS … geschieht hier noch etwas Merkwürdiges, das ich natürlich nach all obiger Recherche entdeckt habe: Die CSS-Eigenschaften des shadow-Trees sind nicht wirklich der Style, den der Balken dann hat, sondern etwas, das vermutlich wie früher durch -webkit-appearance:progress-bar kommt. Und das greift auf das natives Rendering und das OS-Toolkit zurück. Das dürfte dann auch die merkwürdige Positionierung einer ::after-Pseudoklasse am Anfang eines Elementes erklären. Aber das erklärt wiederum nicht, weshalb diese Pseudoklasse bei einem progress:indeterminate nicht gerendert wird.

Diese ganze Shadow-DOM-Geschichte aktuell in Browsern ist noch ein merkwürdiges Schattenreich. Es existieren die DOM-Strukturen, aber das unnötigerweise. Die Spec ist zu kompliziert. Es dürften auf der Welt vermutlich nur drei oder vier Leute (nämlich bei den Browserherstellern) geben, die das ganze derzeitige Zusammenspiel im Browser zwischen progress als replaced Element und progress als Shadow-DOM-Element kapieren. Ich bin es nicht. Für Otto Normal-Webdeveloper gibt es da keine Grundlage, auf der man über so etwas räsonieren und zu verlässliches Ergebnissen kommen kann. Um wirklich zu wissen zu kommen, solltest Du eventuell wirklich mal einen Bugreport schreiben.

Für Dein Problem: Ich halte es für sinnvoller, das Fallback nicht als Pseudoelement sondern als normales Kindelement auszuzeichnen. Es wird angezeigt, wenn das progress-Element nicht verstanden wird; wenn es als replaced Element verstanden wird, wird es nicht angezeigt, im derzeitigen Chaos wird es wiederum nicht angezeigt und sollte irgendwann eine richtige shadow-DOM-Variante kommen wird es auch nicht angezeigt. Und in den hypothetischen Browsern, die zwar kein CSS, aber JS können, würde es dann auch angezeigt und aktualisiert. ;)

Gruß,
Tim

[Tim Tepaße]

Diese ganze Shadow-DOM-Geschichte aktuell in Browsern ist noch ein merkwürdiges Schattenreich. Es existieren die DOM-Strukturen, aber das unnötigerweise.

Weitere Forschungen dazu: Ich habe mich erinnert, dass in früheren Shadow-DOM-Spezifikationen für Bestandteile des shadow trees eigens definierte Peudo-Elemente zum Styling frei geben kann. In Chromes progress-Shadow-DOM geht das im Prinzip auch …

~~~css progress::-webkit-progress-bar {
    background-color: red;
  }

  
… man sieht die Auswirkungen aber nur im Web Inspector, nicht im Renderung.  
  
Dann erinnerte ich mich an [uralte Planungen](https://www.webkit.org/blog/17/the-new-form-controls-checkbox-2/) zum Rendering von Controls in Webkit, nämlich, dass damalige Proto-Shadow-DOM erst dann aktiv wird, setzt man das bepräfixte appearance-property von Webkit auf none. Dies gilt jetzt auch für Blink, d.h. Shadow Dom existiert in etwa:  
  
  ~~~css
progress {  
    -webkit-appearance: none;  
  }  
  
  progress::-webkit-progress-bar {  
    background-color: red;  
  }  
  
  progress::-webkit-progress-value::before {  
    content: "foo";  
    color: white;  
  }

Die Eigenschaft appearance, obwohl in Browsern genutzt ist nicht spezifiziert, auch nicht in Zusammenhang mit Shadow DOM. Das ganze bleibt ein Chaos.

[Gunnar Bittersmann]

@@Tim Tepaße:

nuqneH

Danke für deine Erläuterungen. Dann begebe ich mich mal ins Reich der Schatten um zu sehen, was da so abgeht.

Qapla'