[Bug] Tabel achtergrond niet zwart op mobiel

[Saturnus]

Het AMD Zen overkloktopic

De hele topicstart zit in een tabel met bgcolor=black, echter op mobiel (in mijn geval iPhone 6S Plus) krijgt het gedeelte waarvoor je naar rechts moet scrollen geen zwarte achtergrond. Dit expliciet aangeven in de [td]'s maakt het werkend, maar hoort dit niet nu al te werken?

[ACM]

Dat ziet er uit als een browser-bug en dus niet als iets dat wij kunnen oplossen, hooguit omheen werken.

Zoals je al aangeeft heeft de hele tabel een zwarte achtergrond met witte tekst en de losse rijen, kolommen en cellen niets meer. Dus dat zou inderdaad gewoon zwart moeten zijn. Bovendien is die cel van Moederborden en eronder steeds één cel, die zou dus sowieso niet zomaar na 80% van de breedte van achtergrondkleur mogen veranderen.

In mijn Xperia Z5 compact gaat het in ieder geval goed.

De door jou voorgestelde oplossing is helaas ook geen optie.

Die is vziw technisch best lastig, volgens specificaties onnodig (sterker nog, in html5 is bgcolor niet meer toegestaan, maar een losse herhaalde style= zou wel mogen) en zorgt voor bloat in de gegenereerde (en dus opgeslagen) html.

[Saturnus]

Akkoord. Ik had ook al het vermoeden dat de browser iets fout deed maar wist niet zeker of de Tweakers-engine misschien de UBB zou opvangen en dat er in de vertaalslag naar HTML iets mis ging.

Zojuist geprobeert met 1px zwarte png achtergrond. Werkt helaas ook niet. En bij wel werken zou de tekst in de tabel zwart zijn geweest.

Wie weet nog een workaround?

[Luuk1983]

Ik heb voor de compleetheid (en om cache aan jouw kant uit te sluiten) even een check uitgevoerd en dezelfde pagina in Browser Stack op een iPhone 7S Plus gegooid, maar het probleem speelt ook daar inderdaad.

Als ik de HTML validate, dan zie ik wel dat er wat fouten in de tabel zitten:

Warning: A table row was 11 columns wide, which is less than the column count established by the first row (12).
From line 249, column 2374; to line 249, column 2378
>65 W</td></tr><tr><t
Warning: A table row was 11 columns wide, which is less than the column count established by the first row (12).
From line 249, column 2536; to line 249, column 2540
>65 W</td></tr><tr><t

[ Voor 52% gewijzigd door Luuk1983 op 27-07-2017 16:10 ]

[ACM]

De 'hoofdtabel' is volgens mij niet 11 kolommen breed (of breder) maar zo te zien iets van 3 breed. Ik heb verder geen poging gedaan in die brij te zoeken en ga dat ook niet doen.

Als de (rml voor de) tabel in dat topic niet klopt is dat verder de verantwoordelijkheid van de topicstarter en eventueel moderators van dat forum.

Vooralsnog lijkt het me alsnog een browserbug (de tabel heeft tenslotte de background, niet de indivuele cellen) die eventueel vermeden kan worden door de structuur van die grote tabel te verbeteren. Dat is dan verder geen bug in het forum, maar domweg dan een set fouten gemaakt door de beheerders van dat topic

[crisp]

Volgens mij heeft het te maken met overflow. Dat er horizontaal gescrolled moet worden zou eigenlijk zoveel mogelijk vermeden moeten worden, maar dat is soms erg lastig wanneer er tables gebruikt worden...

[Saturnus]

Luuk1983 schreef op donderdag 27 juli 2017 @ 16:07:
Ik heb voor de compleetheid (en om cache aan jouw kant uit te sluiten) even een check uitgevoerd en dezelfde pagina in Browser Stack op een iPhone 7S Plus gegooid, maar het probleem speelt ook daar inderdaad.

Als ik de HTML validate, dan zie ik wel dat er wat fouten in de tabel zitten:

Warning: A table row was 11 columns wide, which is less than the column count established by the first row (12).
From line 249, column 2374; to line 249, column 2378
>65 W</td></tr><tr><t
Warning: A table row was 11 columns wide, which is less than the column count established by the first row (12).
From line 249, column 2536; to line 249, column 2540
>65 W</td></tr><tr><t

Bedankt. Toevallig heb ik die avond geüpdatet. Dat zojuist nog eens gecontroleerd. Het hoort nu sowieso goed te zijn.

---

Het probleem zit inderdaad in het horizontaal scrollen. Het weglaten van de grote tabel lost het probleem op. De grote tabel alleen testen resulteert weer in het probleem.

[Hero of Time]

crisp schreef op zondag 30 juli 2017 @ 22:39:
Volgens mij heeft het te maken met overflow. Dat er horizontaal gescrolled moet worden zou eigenlijk zoveel mogelijk vermeden moeten worden, maar dat is soms erg lastig wanneer er tables gebruikt worden...

Dat is sowieso een bug bij jullie. Ik zie hetzelfde probleem als ik de diff bekijk van een bewerkt bericht. De achtergrondkleur loopt niet door en er wordt een tabel gebruikt voor weergave.

[Saturnus]

Is hier nog iets uitgekomen?

[Saturnus]

Kick.

(Probleem wordt weer relevant in het nieuwe Zen 2 topic.)

[Saturnus]

@ACM @crisp @Hero of Time
Is dit een browser bug? Tweaker bug? RML bug?

Tips voor een oplossing?

[ACM]

Saturnus schreef op zaterdag 6 juli 2019 @ 13:40:
Tips voor een oplossing?

Ik heb geen idee, het was toen dusdanig complexe rml (en daardoor html) dat ik ook niet een behoefte voel (en voelde) dat te ontcijferen om te bekijken of het correcte rml is.

Al met al wordt het dan erg veel werk om dat uit te zoeken, terwijl de kans vrij groot is dat de rml uiteindelijk fouten bevat. Als jij zeker weet dat dat niet zo is, kunnen we wellicht verder gaan kijken.

De tips voor oplossing is uiteraard minder complexe rml maken
Maar of dat ook het gewenste resultaat geeft weet ik niet.

Dat het ook niet in alle mobiele weergaves misgaat maakt het extra lastig om e.e.a. uit te zoeken. In mobiele browsers is het sowieso lastig, soms onmogelijk, om te debuggen.

[ Voor 12% gewijzigd door ACM op 06-07-2019 13:46 ]

[Saturnus]

ACM schreef op zaterdag 6 juli 2019 @ 13:45:
[...]

Ik heb geen idee, het was toen dusdanig complexe rml (en daardoor html) dat ik ook niet een behoefte voel (en voelde) dat te ontcijferen om te bekijken of het correcte rml is.

Al met al wordt het dan erg veel werk om dat uit te zoeken, terwijl de kans vrij groot is dat de rml uiteindelijk fouten bevat. Als jij zeker weet dat dat niet zo is, kunnen we wellicht verder gaan kijken.

De tips voor oplossing is uiteraard minder complexe rml maken
Maar of dat ook het gewenste resultaat geeft weet ik niet.

Dat het ook niet in alle mobiele weergaves misgaat maakt het extra lastig om e.e.a. uit te zoeken. In mobiele browsers is het sowieso lastig, soms onmogelijk, om te debuggen.

Ik ben in de overtuiging dat de RML correct is, maar het zou inderdaad jammer zijn als dat niet zo blijkt te zijn. Dus ik heb de code gereduceerd tot het onderstaande.

code:

[table bgcolor=black border=0 bordercolor=white width=100%]

    [tr]
        [td width=100][/td]
        [td align=justify]Dit topic is bedoeld om ...[/td]
        [td width=100][/td]
    [/tr]

    [tr][td colspan=3][br][hr=noshade][/td][/tr]

    [tr][td colspan=3][h1=nostyle][red][anchor=amd3]PROCESSOREN[/red][/h1][/td][/tr]

    [tr]
        [td width=100][/td]
        [td][red][b]Ryzen 3000-serie[/b][/red][/td]
        [td width=100][/td]
    [/tr]
    
    [tr]
        [td colspan=3]
            [table bgcolor=black border=1 bordercolor=white width=100%]
                [tr]
                    [td][b]Serie[/b][/td]
                    [td][b]Model[/b][/td]
                    [td][b]Kernen[/b][/td]
                    [td][b]SMT[/b][/td]
                    [td][b]Basisklok[/b][/td]
                    [td][b]Boostklok[/b][/td]
                    [td][b]XFR[/b][/td]
                    [td][b]L1 cache[/b][/td]
                    [td][b]L2 cache[/b][/td]
                    [td][b]L3 cache[/b][/td]
                    [td][b]TDP[/b][/td]
                    [td][b][url="https://tweakers.net/pricewatch/"]PW[/url][/b][/td]
                [/tr]
            [/table]
        [/td]
    [/tr]

[/table]

Lijkt mij in orde.

Resultaat:

	Dit topic is bedoeld om ...
PROCESSOREN
	Ryzen 3000-serie
Serie Model Kernen SMT Basisklok Boostklok XFR L1 cache L2 cache L3 cache TDP PW

Het probleem blijft.

[Hero of Time]

Het probleem zit 'm in de overflow, want op m'n computer maak ik de inhoud van posts breder waardoor de tabel hierboven er prima uit ziet. Al 'sloop' ik met mijn eigen css de achtergrondkleur die is opgegeven, het is ipv zwart voor mij grijs. Maar dat is mijn probleem.

Ik had 't een tijd terug in een ander topic nog eens genoemd en toen kwam naar voren dat de css selectors voor de styling niet 100% in orde waren, iig bij mij. Iets zegt mij dat dat hier ook het geval is. Ik kan het nu echter niet meer herproduceren met de custom css die ik nu heb. Geen idee of ik dat stukje code eruit heb gehaald of dat het anders is opgelost. Maar de diff waar ik het over had, waar ik het zag, zie ik het nu iig zo snel niet meer.

[ACM]

Saturnus schreef op zaterdag 6 juli 2019 @ 14:14:
Het probleem blijft.

Wat is precies het probleem? Want in een normale desktopbrowser met 'mobiele weergave' werkt het goed en ik heb hier geen iphone.

Heb je trouwens custom css?

Ah via BrowserStack een iPhone 6S Plus gepakt. Daar zie je inderdaad dat de geneste tabel aan de rechterkant uitsteekt en de rest van de tabel niet meegaat in achtergrond. Op de iPhone XS gaat het ook mis.

Op een Galaxy S10 met Android 9 en Chrome gaat het wel goed.

Ik heb nu dus nog steeds geen idee of dit een browser bug is of niet

[ Voor 37% gewijzigd door ACM op 06-07-2019 14:53 ]

[Saturnus]

@ACM het probleem is in de topicstart te zien. In Firefox responsive design mode is het probleem er inderdaad niet. Custom css, ja, maar maakt geen verschil.

[Saturnus]

@ACM
Getest op Safari desktop. Bij het verkleinen van het scherm is het probleem ook aanwezig.
Safari gerelateerd probleem?

IE, Edge, Firefox geen problemen.

[ACM]

Saturnus schreef op zaterdag 6 juli 2019 @ 14:53:
@ACM het probleem is in de topicstart te zien. In Firefox responsive design mode is het probleem er inderdaad niet. Custom css, ja, maar maakt geen verschil.

Het komt zo te zien alleen in Safari (zowel desktop als mobile) voor. Edge, Firefox, Chrome en Chrome mobile doen het allemaal goed.

Dat maakt het wel lastig om dit als bug bij ons te kwalificeren. Verder is mijn kennis op dit vlak te beperkt om er echt zeker van te zijn of het aan Safari ligt of aan onze css in combinatie met de html.

Saturnus schreef op zaterdag 6 juli 2019 @ 15:05:
@ACM
Getest op Safari desktop. Bij het verkleinen van het scherm is het probleem ook aanwezig.
Safari gerelateerd probleem?

IE, Edge, Firefox geen problemen.

Zit je nou vrijwel hetzelfde te typen als ik?!

[ Voor 21% gewijzigd door ACM op 06-07-2019 15:05 ]

[Saturnus]

ACM schreef op zaterdag 6 juli 2019 @ 15:05:
[...]

Het komt zo te zien alleen in Safari (zowel desktop als mobile) voor. Edge, Firefox, Chrome en Chrome mobile doen het allemaal goed.

Dat maakt het wel lastig om dit als bug bij ons te kwalificeren. Verder is mijn kennis op dit vlak te beperkt om er echt zeker van te zijn of het aan Safari ligt of aan onze css in combinatie met de html.


[...]

Zit je nou vrijwel hetzelfde te typen als ik?!

@Hero of Time had het over overflow. Misschien moet er zo'n (css?) optie geactiveerd worden die voor Safari de boel fixt maar voor de andere browsers in principe niet nodig is omdat die het zelf automatisch toepasten?

[Hero of Time]

Nee, ik had het over overflow omdat er dan een iets andere class mogelijk is om te stylen. Ik had hier zelf ook last van, maar kan het dus niet meer reproduceren. Of dat komt door een update aan de kant van Tweakers, m'n browser, of dat ik de custom css die dit veroorzaakte heb aangepast weet ik niet.

Wat wel duidelijk is, is dat het bij Safari iig niet goed gaat. Omdat het momenteel de enige browser is waarbij dit gebeurt, zou je redelijk kunnen concluderen dat het aan die specifieke browser ligt. Het verleden heeft aangetoond dat Safari wel vaker gekke dingen doet.