Unsinniges Rendering durch Google Search Console

[Christoph Schneegans]

Hallo allerseits!

Mit

<meta name="viewport" content="width=device-width, initial-scale=1" />

erhalte ich etwa für meine Seite
<https://schneegans.de/windows/activate-administrator/> auf mobilen
Geräten eine m.E. recht brauchbare Darstellung;
<https://schneegans.de/temp/smartphone.jpg> zeigt einen Screenshot von
Chrome auf einem Mittelklasse-Smartphone. Die Schriftgröße stimmt, der
Fließtext wird automatisch umbrochen, und der überbreite Code-Block
wird sichtbar, wenn man die Seite als ganzes scrollt. Ein Desktop-
Browser geht mit Inhalten, die breiter sind als sein Fenster, ja
genauso um. (Ich möchte explizit keine Bereiche mit "overflow: scroll",
die sich unabhängig von der Seite scrollen lassen. Auch möchte ich die
Zeilen im Code-Block nicht automatisch umbrechen lassen.)

So weit, so gut. Die Google Search Console sieht das jedoch anders und
präsentiert mir <https://schneegans.de/temp/search-console.png> als
Vorschau und dazu die folgenden Probleme:

• Text ist zu klein zum Lesen
• Inhalt breiter als Bildschirm
• Anklickbare Elemente liegen zu dicht beieinander

Diese drei Probleme dürften wohl ein und dieselbe Ursache haben – die
Search Console versucht offenbar, auch den breiten Code-Block in den
Viewport zu zwängen, indem die ganze Seite herunterskaliert wird, und
macht dadurch die Schriftgröße absurd winzig.

Irgendwelche Tips?

(Bitte Followup-To-Header beachten.)

--
<https://schneegans.de/lv/> · Validator für BCP 47

[Arno Welzel]

Christoph Schneegans:

> Mit
>
> <meta name="viewport" content="width=device-width, initial-scale=1" />
>
> erhalte ich etwa für meine Seite
> <https://schneegans.de/windows/activate-administrator/> auf mobilen
> Geräten eine m.E. recht brauchbare Darstellung;

Das ist erstmal nur die erste Näherung, da hiermit die Skalierung
mobiler Geräte ausgeschaltet wird und das Display 1:1 so verwendet wird,
wie es ist.

> So weit, so gut. Die Google Search Console sieht das jedoch anders und
> präsentiert mir <https://schneegans.de/temp/search-console.png> als
> Vorschau und dazu die folgenden Probleme:
>
> • Text ist zu klein zum Lesen
> • Inhalt breiter als Bildschirm
> • Anklickbare Elemente liegen zu dicht beieinander

Ja, weil es eben nicht damit getan ist, die Skalierung abzuschalten. Man
muss den Inhalt schon auch an den verfügbaren Viewport anpassen.

Gültiges HTML wäre auch sinnvoll:

<http://validator.w3.org/check?uri=https%3A%2F%2Fschneegans.de%2Fwindows%2Factivate-administrator%2F&charset=%28detect+automatically%29&doctype=Inline&group=0>

Und statt XHTML 1.1 würde ich HTML5 verwenden. XHTML 1.1 ist faktisch
"tot". Ich würde darauf keine Zeit mehr verwenden.

Desweiteren hast Du ein <code>-Element, dessen Breite nicht begrenzt
ist. Dadurch ist das Element ggf. breiter als der Viewport und die ganze
Seite muss deshalb gescrollt werden bzw. mobile Browser fangen an, dann
doch wieder zu skalieren, wenn man es ihnen nicht mit Vorgabe von
minimum-scale und maximum-scale verbietet. Beide Varianten sind aber
nicht ideal.

Eine Lösung wäre, für die mobile Ansicht <code> mit folgender CSS-Regel
zu formatieren, so dass die Ansicht insgesamt nicht gescrollt werden
muss, man den Code-Block aber lokal dennoch scrollen kann, um den ganzen
Inhalt sehen zu können.:

code {
width: 100%;
overflow-x: scroll;
overflow-y: hidden;
}

Siehe z.B. die Anwendung solcher Regeln hier:

<https://arnowelzel.de/tools/speichenlaengenrechner>
<https://arnowelzel.de/tools/dns-abfrage?dns_domain=arnowelzel.de>
<https://arnowelzel.de/greylisting-zur-spamvermeidung>

Das mit den zu dicht beieinanderliegenden Elementen zum Anklicken
bezieht sich vermutlich auf die Fußzeile mit dem Link zum Impressum und
direkt daneben der Link für E-Mail. Das würde ich auch ohne mobile
Ansicht so nicht machen, weil es schlicht irritierend ist - niemand
rechnet damit, dass der erste Link woanders hin führt, als der zweite
Link mit dem "mailto:" - das wirkt eher so, als wäre der Name ebenfalls
nur ein "mailto:"-Link.

> Diese drei Probleme dürften wohl ein und dieselbe Ursache haben – die
> Search Console versucht offenbar, auch den breiten Code-Block in den
> Viewport zu zwängen, indem die ganze Seite herunterskaliert wird, und
> macht dadurch die Schriftgröße absurd winzig.

Das macht nicht nur die Search Console - auch manche mobile Browser
machen das so.


--
Arno Welzel
https://arnowelzel.de

[Arno Welzel]

Arno Welzel:

> Christoph Schneegans:
>
>> Mit
>>
>> <meta name="viewport" content="width=device-width, initial-scale=1" />
>>
>> erhalte ich etwa für meine Seite
>> <https://schneegans.de/windows/activate-administrator/> auf mobilen
>> Geräten eine m.E. recht brauchbare Darstellung;
>
> Das ist erstmal nur die erste Näherung, da hiermit die Skalierung
> mobiler Geräte ausgeschaltet wird und das Display 1:1 so verwendet wird,
> wie es ist.
>
>> So weit, so gut. Die Google Search Console sieht das jedoch anders und
>> präsentiert mir <https://schneegans.de/temp/search-console.png> als
>> Vorschau und dazu die folgenden Probleme:

[...]

> Eine Lösung wäre, für die mobile Ansicht <code> mit folgender CSS-Regel
> zu formatieren, so dass die Ansicht insgesamt nicht gescrollt werden
> muss, man den Code-Block aber lokal dennoch scrollen kann, um den ganzen
> Inhalt sehen zu können.:
>
> code {
> width: 100%;
> overflow-x: scroll;
> overflow-y: hidden;
> }

Ingrid erinnerte mich daran, dass Du kein "lokales" Scrollen willst. Das
ist aber mittlerweile die übliche Lösung für solche Probleme, weil es
auch sehr irritiert, wenn man die ganze Seite wegen einer überbreiten
Tabelle horizontal scrollt, danach dann nach oben oder unten scrollt und
dort nur noch weißen Hintergrund sieht, weil der Text darüber und
darunter eben nur so breit ist, wie der initial sichtbare Viewport.

Siehe auch hier:
<https://nextcloud.0x0c.de/s/EX6wb6AGbY5KXRR/preview>

[Christoph Schneegans]

Arno Welzel schrieb:

> Gültiges HTML wäre auch sinnvoll:

Mein XHTML ist gültig.

> <http://validator.w3.org/check?uri=https://schneegans.de/windows/activate-administrator/>

Mal wieder ein Fehler in der modularisierten XHTML-1.1-DTD. xml:space
ist in den XHTML-1.0-DTDs (etwa
<https://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd>) sinnigerweise für
die Elemente script, style und pre definiert. In der XHTML-1.1-DTD
erscheint es plötzlich wegen

<!ENTITY % Core.attrib
"%XHTML.xmlns.attrib;
%id.attrib;
%class.attrib;
%title.attrib;
xml:space ( preserve ) #FIXED 'preserve'
%Core.extra.attrib;"
>

in <https://www.w3.org/TR/xhtml-modularization/dtd_module_defs.html>
plötzlich bei zahlreichen weiteren Elementen. Ein minimales Dokument,
das gültig gegen die kaputte DTD ist, müsste deshalb bekloppterweise so
aussehen:

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.1//EN' 'http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd' []>
<html xmlns="http://www.w3.org/1999/xhtml" version="-//W3C//DTD XHTML 1.1//EN">
<head>
<title>…</title>
</head>
<body xml:space="preserve">
<p xml:space="preserve">…</p>
</body>
</html>

Das ist offensichtlich nicht die Intention der XHTML-Spezifikation.

> Desweiteren hast Du ein <code>-Element, dessen Breite nicht begrenzt
> ist. Dadurch ist das Element ggf. breiter als der Viewport und die ganze
> Seite muss deshalb gescrollt werden bzw. mobile Browser fangen an, dann
> doch wieder zu skalieren, wenn man es ihnen nicht mit Vorgabe von
> minimum-scale und maximum-scale verbietet. Beide Varianten sind aber
> nicht ideal.

Testweise habe ich in
<https://schneegans.de/windows/activate-administrator/>

<meta name="viewport" content="width=device-width, initial-scale=1, minimum-scale=1" />

geschrieben und Google die Seite neu indizieren lassen. Die Search
Console zeigt nun das Rendering
<https://schneegans.de/temp/search-console-2.png>, das ich durchaus als
angenehm empfinde (und ja auch dem Chrome-Rendering aus
<https://schneegans.de/temp/smartphone.jpg> entspricht), auch wenn das
natürlich nicht zur "mobile friendly"-Medaille genügt.

>> Diese drei Probleme dürften wohl ein und dieselbe Ursache haben – die
>> Search Console versucht offenbar, auch den breiten Code-Block in den
>> Viewport zu zwängen, indem die ganze Seite herunterskaliert wird, und
>> macht dadurch die Schriftgröße absurd winzig.
>
> Das macht nicht nur die Search Console - auch manche mobile Browser
> machen das so.

Welche denn zum Beispiel? Damit zu testen wäre erheblich einfacher als
nach jeder Änderung auf den Googlebot zu warten…

[Arno Welzel]

On 04.02.20 03:58, Christoph Schneegans wrote:

> Arno Welzel schrieb:
>
>> Gültiges HTML wäre auch sinnvoll:
>
> Mein XHTML ist gültig.
>
>> <http://validator.w3.org/check?uri=https://schneegans.de/windows/activate-administrator/>
>
> Mal wieder ein Fehler in der modularisierten XHTML-1.1-DTD. xml:space
> ist in den XHTML-1.0-DTDs (etwa

[...]

Du benutzt aber kein XHTML 1.0 sondern 1.1:

Aus deiner Website:

<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.1//EN'
'http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd' []>

Das würde ich heutzutage nicht mehr verwenden.

> Das ist offensichtlich nicht die Intention der XHTML-Spezifikation.

Aus diesen Gründen wäre es sinnvoll, von XHML 1.1 auf HTML5 umzustellen.

[Anpassung der Skalierung bei Bedarf durch Browser]

>> Das macht nicht nur die Search Console - auch manche mobile Browser
>> machen das so.
>
> Welche denn zum Beispiel? Damit zu testen wäre erheblich einfacher als
> nach jeder Änderung auf den Googlebot zu warten…

Praktisch alle, die Chromium als Basis haben, wie Chrome, Vivaldi, Edge,
Dolphin...

[Claus Reibenstein]

Christoph Schneegans schrieb am 04.02.2020 um 03:58:

> Arno Welzel schrieb:
>
>> Gültiges HTML wäre auch sinnvoll:
¯¯¯¯

> Mein XHTML ist gültig.

¯¯¯¯¯

Du siehst den Unterschied?

Gruß
Claus

[Christoph Schneegans]

Arno Welzel schrieb:

> [Anpassung der Skalierung bei Bedarf durch Browser]

[Zusammenquetschen durch die Browser-Simulation einer Suchmaschine]

>>> Das macht nicht nur die Search Console - auch manche mobile Browser
>>> machen das so.
>>
>> Welche denn zum Beispiel? Damit zu testen wäre erheblich einfacher als
>> nach jeder Änderung auf den Googlebot zu warten…
>
> Praktisch alle, die Chromium als Basis haben, wie Chrome, Vivaldi, Edge,
> Dolphin...

Ich teste von Anfang an in Chrome und habe jetzt auch Vivaldi, Edge und
Dolphin auf mehreren Geräten installiert. Alle zeigen das Dokument
wunschgemäß in lesbarer Schriftgröße und ggf. mit horizontaler
Bildlaufleiste an. Kein einziger von denen macht es so wie die Search
Console und quetscht das Dokument auf Teufel komm raus in den Viewport.

Ich find's ja auch nicht überraschend, dass Browser-Entwickler mehr
davon verstehen als ihre Kollegen von der Suchmaschine.

--
<https://schneegans.de/sv/> · Schema-Validator für XML

[Arno Welzel]

On 04.02.20 17:36, Christoph Schneegans wrote:

> Arno Welzel schrieb:
>
>> [Anpassung der Skalierung bei Bedarf durch Browser]
>
> [Zusammenquetschen durch die Browser-Simulation einer Suchmaschine]
>
>>>> Das macht nicht nur die Search Console - auch manche mobile Browser
>>>> machen das so.
>>>
>>> Welche denn zum Beispiel? Damit zu testen wäre erheblich einfacher als
>>> nach jeder Änderung auf den Googlebot zu warten…
>>
>> Praktisch alle, die Chromium als Basis haben, wie Chrome, Vivaldi, Edge,
>> Dolphin...
>
> Ich teste von Anfang an in Chrome und habe jetzt auch Vivaldi, Edge und
> Dolphin auf mehreren Geräten installiert. Alle zeigen das Dokument
> wunschgemäß in lesbarer Schriftgröße und ggf. mit horizontaler
> Bildlaufleiste an. Kein einziger von denen macht es so wie die Search
> Console und quetscht das Dokument auf Teufel komm raus in den Viewport.

Jetzt hast Du ja auch den Viewport-Zoom festgenagelt auf einen
Minimalwert. Hast Du es auch ohne Vorgabe für den minimalen
Viewport-Zoom getestet?

> Ich find's ja auch nicht überraschend, dass Browser-Entwickler mehr
> davon verstehen als ihre Kollegen von der Suchmaschine.

Ich schon, da es die selbe Firma ist.