Schepp und Peter nahmen die Veröffentlichung der Safari Technology Previews 161 und 162 zum Anlass, die dort frisch implementierten Features zu diskutieren und zu kommentieren.

Schaunotizen

[00:01:25] Best of Safari Technology Preview
Los geht es mit neuen Media-Query-Features, speziell prefers-reduced-motion und prefers-contrast (die in den Previews nicht neu sind, aber jetzt besser debugged werden können). Wir diskutieren die Hürden im praktischen Einsatz dieser Features (sowie von prefers-color-scheme) und erinnern an Hotdog Stand. Die Unterstützung von @property fehlt nach den neuesten Safari-Updates nun nur noch in Firefox, aber insgesamt sieht es für das CSS Typed OM und das Houdini-Projekt eher nicht so glänzend aus (Working Draft berichtete bereits). Über Fragen des Umgangs mit immer komplexerem CSS kommen wir zum Thema Selektor-Performance von :has(), die sich mit dem Profi-Profiling-Tool von Chrome messen lässt. Die Unterstützung von :user-invalid und :user-valid feiern wir marginal enthusiastischer als die von Lookbehind Assertions in Regulären Ausdrücken und wir nehmen die (beinahe) bestehende Existenz des ResizableArrayBuffer zur Kenntnis. Safari wird nun als letzter fehlender Browser Unterstützung für OffscreenCanvas bekommen, was Peter dazu bringt, seine jüngsten Abenteuer rund um willReadFrequently nochmal wiederzugeben. Zum Ende hin quatschen wir noch über margin-trim, CSS Subgrids, Declarative Shadow DOM, E4X, HTMLElement.attachInternals() bzw. Form-associated custom elements, globale Event Handler und die Zukunft von Safari und der ganzen weiten Browserwelt.
Transkript
WEBVTT

00:00.000 --> 00:06.360
Bist du einer der reduced motion referiert oder eher nicht und ich brauche es nicht

00:07.040 --> 00:11.040
Preverse reduced motion ist ja ein feature dass wir als webentwicklerinnen

00:12.120 --> 00:13.520
verwenden können

00:13.520 --> 00:18.320
Und die frage ist wenn ich jetzt jemand bin der darauf angewiesen ist dass die motion reduced ist so wie du es gerade beschrieben hast

00:19.200 --> 00:25.360
Dann kann ich doch webentwickler die ja tendenziell dazu neigen über lange animationen zu machen und zu verspielt zu werden doch nicht über einen

00:25.360 --> 00:31.360
Weg trauen oder?

00:31.360 --> 00:33.360
und

00:51.040 --> 00:54.000
working draught revision 557

00:54.000 --> 01:02.520
diese revision von working draught wird euch präsentiert von höhrerinnen und höhrern wie euch auf patreon.com

01:03.160 --> 01:09.360
Working draught könnt ihr uns ein paar euro in den hut werfen aus euren beiträgen und unseren gelinglichen werbeeinnahmen bezahlen wir allerleit

01:09.360 --> 01:12.280
höhere software bus und das honorar unserer audio produceren

01:12.560 --> 01:15.200
Wenn ihr euch auch beteiligen wollt könnt ihr das unter patreon.com

01:15.200 --> 01:23.760
Slashworking draught sehr gerne machen wir danken euch tausendfach für die unterstützung und fürs weitere zuhören

01:25.760 --> 01:30.960
Wir sind heute zu zweit und zwar während er zum ein der peter

01:31.520 --> 01:35.000
moin moin und ich bin der cheb und wir

01:35.680 --> 01:37.680
haben uns überlegt dass wir

01:37.680 --> 01:40.280
anlässlich der letzten safari

01:40.800 --> 01:42.320
technology previews

01:42.320 --> 01:45.320
technik previews technologie previews

01:45.320 --> 01:48.320
einfach mal wieder ein bisschen über webkit reden

01:48.320 --> 01:50.320
und

01:50.320 --> 01:53.320
was da so alles neues passiert

01:53.320 --> 01:58.320
weil das doch schon so einiges ist und auch ein paar coole sachen

01:58.320 --> 02:04.320
genau wo hingegen wir festgestellt haben dass im safari 16.3 der jetzt ja gerade

02:04.320 --> 02:08.320
irgendwie diese woche also in dieser aufnahmewoche ausgerollt wurde

02:08.320 --> 02:15.320
dass da im grunde nur bug fixes drin sind genau was auch cool ist die semantik versioning oder irgendwie so was ist das normal

02:15.320 --> 02:24.320
die versionsnummer von safari ist ja glaube ich immer gekoppelt an die versionsnummer das betrachten ja das kann auch nicht sein

02:24.320 --> 02:28.320
weil ich glaube also zumindest an die ios version

02:28.320 --> 02:32.320
genau das war auch mein eindruck aber beim desktop weiß ich nichts

02:32.320 --> 02:35.320
ja ich glaube desktop ist anders

02:35.320 --> 02:36.320
genau

02:36.320 --> 02:39.320
ja muss ja die aktuelle ist irgendwie

02:39.320 --> 02:41.320
ja

02:41.320 --> 02:44.320
wir sind doch echt die falschen leute für fragen zu macOS

02:44.320 --> 02:46.320
definitiv ja

02:46.320 --> 02:48.320
google das jetzt nochmal schnell

02:48.320 --> 02:51.320
aktuelle version wir bräuchten jetzt chatgbt

02:51.320 --> 02:53.320
also

02:53.320 --> 02:55.320
10.14.6

02:55.320 --> 02:57.320
ist wohl die aktuelle

02:57.320 --> 03:01.320
was überhaupt gar nichts mit der versionnummer von safari zu tun hat

03:01.320 --> 03:03.320
das stimmt

03:03.320 --> 03:09.320
gut aber auf jeden fall ist die 16.3 nur ein bug fix release deswegen

03:09.320 --> 03:15.320
übersehen wir das einfach weil da gibt es halt nichts spannendes außer dass Dinge die sowieso funktionieren sollten funktionieren

03:15.320 --> 03:19.320
genau und im webkit Bereich ist es natürlich trotzdem

03:19.320 --> 03:23.320
schön also man freut sich über darüber das zu lesen weil

03:23.320 --> 03:28.320
die haben ja viele coole features aber leider ja auch öfters mal ganz ganz merkwürdige bugs

03:28.320 --> 03:34.320
genau das heißt also da ist einiges hoffentlich stabiler und besser als vorher

03:37.320 --> 03:44.320
gut aber ich würde sagen wir gehen mal durch die beiden technologie previews durch die wir da haben 161 und 162

03:44.320 --> 03:49.320
und machen im prinzip so eine art non random glücksrad

03:49.320 --> 03:53.320
gucken wir mal was uns so zu den einzelnen features und

03:53.320 --> 03:58.320
Sachen so einfällt die da jetzt aktiviert wurden implementiert wurden oder etwas

03:58.320 --> 04:01.320
und bug fix wurden oder wo es halt eben einfach auch nur

04:01.320 --> 04:07.320
Änderungen gibt in irgendwelchen developer tools das kann uns ja eventuell auch dazu verleiten irgendwie

04:07.320 --> 04:09.320
ja

04:09.320 --> 04:13.320
irgendwas auf die themenplatte zu setzen ich würde direkt mal aufschlagen

04:13.320 --> 04:18.320
ja gerne mit dem ersten feature dass sie in der technologie preview 161

04:18.320 --> 04:24.320
geführt haben nämlich emulation toggles für css media features und zwar

04:24.320 --> 04:28.320
pre first reduced motion und pre first contrast

04:28.320 --> 04:32.320
erstmal ist natürlich sinnvoll dass man das irgendwie in seinen dev tools

04:32.320 --> 04:36.320
bekommt sonst kann man ja nicht testen was man da macht aber jetzt würde ich natürlich

04:36.320 --> 04:39.320
erstmal so die frage an dich schäbstellen

04:39.320 --> 04:44.320
hast du die im einsatz und wie entscheidet man sich dazu die einzusetzen in welchem

04:44.320 --> 04:48.320
rahmen oder so weil das fällt ja so in die gleiche kategorie von so user

04:48.320 --> 04:53.320
preferences umsetzen wie ein dark mode rein also pre first color scheme oder wie das heißt

04:53.320 --> 04:58.320
ja und das kriege ich ja noch so einig einigermaßen so in meinem cortex so

04:58.320 --> 05:01.320
vorgehalten es gibt irgendwie so die helle seite die dunkle seite das wissen

05:01.320 --> 05:05.320
wir schon seit lux skywalker und das kriege ich irgendwie so alles rein aber

05:05.320 --> 05:11.320
wie handhabt man so als man an der front diese preferred reduced motion und diese

05:11.320 --> 05:16.320
ganzen anderen preferences die man da so umsetzen kann ja bevor ich darauf

05:16.320 --> 05:20.320
antworte wollte ich noch vorab schicken du hast treffenerweise gesagt dass das

05:20.320 --> 05:26.320
ja media features sind kannst du noch kurz sagen was der unterschied warum du

05:26.320 --> 05:31.320
nicht media query gesagt hast ich glaube technisch gesehen ist es so media query

05:31.320 --> 05:34.320
ist ja so die gesamtheit von ad media und dann kommt da ihr kommt da irgendwelche

05:34.320 --> 05:38.320
regeln und dann gibt es darin die types und die features und die features sind

05:38.320 --> 05:42.320
im prinzip die wenn ich das so mal hinsetzen darf das sind im prinzip die

05:42.320 --> 05:47.320
parametrisierbaren varianten wo man irgendwie sagen kann breite bis oder

05:47.320 --> 05:52.320
color scheme dieses oder jenes und die alten waren die media features mit den

05:52.320 --> 05:57.320
vorgegebenen im prinzip geräteklassen von wegen es gibt ein mir type tv es gibt

05:57.320 --> 06:01.320
ein mir type handheld zuzeiten als es eine klare trennung gab zwischen zum

06:01.320 --> 06:04.320
beispiel einem handheld device und nicht wo das ja heutzutage irgendwie

06:04.320 --> 06:09.320
hybridgeräte sein können und wo ihr auch ein fernseher definitiv ein bestimmtes

06:09.320 --> 06:13.320
benutzungsmodell und niedrig auflösenden röhrenschirm und so was ähnliches

06:13.320 --> 06:19.320
vorausgesetzt hat so in der richtung ja genau ja die weil tatsächlich diese

06:19.320 --> 06:24.320
media features sind ja eben nur quasi ein baustein einer media query und diese

06:24.320 --> 06:29.320
media features kannst du ja auch in html bei ganz vielen elementen benutzen also

06:29.320 --> 06:38.320
bei dem source zum beispiel oder also für das picture element und bei video

06:38.320 --> 06:46.320
und bei link rel jetzt zum beispiel preload das ist dann eben das media feature

06:46.320 --> 06:51.320
und in css mit der ad media rule und dem ganzen schnick und schnack dadurch

06:51.320 --> 06:56.320
dadurch wird es erst so media query genau habe ich auch irgendwie lange gar nicht

06:56.320 --> 07:00.320
so drauf geachtet ist jetzt auch nicht unbedingt was also es ist jetzt nicht

07:00.320 --> 07:05.320
super wichtig dass man es weiß aber war dann irgendwann ist es mir das mal

07:05.320 --> 07:10.320
aufgefallen dass es eben doch zwei paar schuhe sind ja aber ich meine im prinzip

07:10.320 --> 07:14.320
ist ja das einzige also die einzigen zwei media types die ja noch relevant sind

07:14.320 --> 07:20.320
sind ja tatsächlich screen also der default und print maximal noch ja und das

07:20.320 --> 07:23.320
sind ja im prinzip wenn man jetzt mal so die analogie wieder her nimmt von wegen die

07:23.320 --> 07:27.320
feature sind parametrisierbare varianten könntest du ja im prinzip genauso gut

07:27.320 --> 07:31.320
sagen dass die types einfach nullstellige funktionen sind und dann kannst du das

07:31.320 --> 07:34.320
durchaus alles in einen top werfen und rumrühren weil ich glaube am ende

07:34.320 --> 07:37.320
interessiert das nicht so wirklich also da gibt es keinen druck die und zu

07:37.320 --> 07:43.320
unterscheiden glaube ich wenn man spezifikationen ja genau und um dann

07:43.320 --> 07:48.320
deine frage zu beantworten also tatsächlich also prefers contrast ist was

07:48.320 --> 07:54.320
dass ich momentan oder auch in der vergangenheit gar nicht bisher irgendwie

07:54.320 --> 08:00.320
bakere genau ich glaube da würde ich wahrscheinlich auch noch mal irgendwie

08:00.320 --> 08:05.320
mich einlesen wollen bevor ich da einfach ad hoc irgendwas mit baue im

08:05.320 --> 08:11.320
grunde genommen wünscht sich da eben der die besuchende oder der besucher

08:11.320 --> 08:18.320
einfach einen höheren kontrast es gibt ja noch diesen high contrast mode zum

08:18.320 --> 08:23.320
Beispiel in windows der sieht auch richtig also der ist schon echt übel so

08:23.320 --> 08:28.320
für ihr meintest du meinst hotdog stand richtig ist das hotdog stand ich glaube

08:28.320 --> 08:32.320
das glaube ich das war so ein theme das konnte man einsteigen hotdog stand war

08:32.320 --> 08:36.320
das halt eben das knallrote mit knallgelben ja ich glaube so der

08:36.320 --> 08:40.320
kontrast modus den du meinst nee aber so von der wirkung her auf jeden fall

08:40.320 --> 08:45.320
ähnlich da weiß ich jetzt gerade nicht ob das ob das das gleiche ist wie

08:45.320 --> 08:50.320
prefers contrast und deswegen sage ich also wenn ich dieses fällt irgendwie

08:50.320 --> 08:55.320
anfangen zu barkern würde ich mich da wahrscheinlich erstmal einlesen wollen

08:55.320 --> 09:02.320
genau prefers reduced motion das setze ich ein aber eigentlich eigentlich

09:02.320 --> 09:08.320
falsch weil was ich damit mache ist dass ich immer sozusagen alle animationen

09:08.320 --> 09:15.320
wieder wegnehme wenn jemand dieses diese preference gesetzt hat und ich glaube

09:15.320 --> 09:22.320
korrekt darf händis wenn ich die animationen in so ein prefers reduced motion

09:22.320 --> 09:30.320
hineinwickeln wo jemand sagt er möchte oder sie weil das dann quasi so ein

09:30.320 --> 09:36.320
art progressive enhancement ist und wer eben einen alten browser hat indem man das

09:36.320 --> 09:42.320
eben so nicht melden kann an die webseite dann dann hat man auch trotzdem fällt

09:42.320 --> 09:46.320
man eben zurück auf man hat keine animationen und wenn man eben dann eine

09:46.320 --> 09:51.320
betroffenen person ist und einen älteren browser hat dann braucht man eben kein

09:51.320 --> 09:57.320
kotz einwand neben seinem rechner wenn man die webseite betrachtet aber dann

09:57.320 --> 10:03.320
könnte man doch theoretisch einfach ganz ans ende von allem doch für alle

10:03.320 --> 10:09.320
elemente alle animationen und transitions auf aufschalten wird das nicht funktionieren

10:09.320 --> 10:16.320
genau so so mache ich das aber ich glaube ich finde also im infekt ist das jetzt

10:16.320 --> 10:20.320
das feinheiten ich glaube ich finde den umgekehrten ansatz besser wo man eben

10:20.320 --> 10:27.320
animationen hinzufügt wenn jemand prefers reduced motion ausgeschaltet hat

10:27.320 --> 10:33.320
genau und so wie du es gerade gesagt hast so mache ich das und so machen das

10:33.320 --> 10:38.320
glaube ich auch viele dass dass man dann einfach animation nun transition dann

10:38.320 --> 10:43.320
und dann noch important genau und die dinge dann nachträglich wieder

10:43.320 --> 10:50.320
abschaltet bist du einer der reduced motion preferiert oder er nicht

10:50.320 --> 10:58.320
und ich brauche es nicht also das ist ja dann es gibt weiß gar nicht vestibular

10:58.320 --> 11:04.320
oder motion sickness irgendwie dann ist dein gleichgewichtsorgan gestört glaube

11:04.320 --> 11:09.320
ich und es gibt so bestimmte arten von animationen die die du dann einfach nicht

11:09.320 --> 11:15.320
gut verträgst also wir wird zwar in der barn schlecht wenn ich arbeite und im

11:15.320 --> 11:20.320
auto wenn ich lese aber da da habe ich jetzt keine probleme ich finde aber

11:20.320 --> 11:26.320
manchmal tatsächlich wenn Sachen so zu verspielt und zu langartig animiert sind

11:26.320 --> 11:35.320
dann also dann finde ich das doof irgendwie schnell vorwärts kommen will ja gut

11:35.320 --> 11:39.320
aber das geht uns ja allen so die frage auf die ich halt hinaus möchte ist die

11:39.320 --> 11:45.320
first reduced motion ist ja ein feature dass wir als webentwicklerin verwenden

11:45.320 --> 11:49.320
können und die frage ist wenn ich jetzt jemand bin der darauf angewiesen ist

11:49.320 --> 11:52.320
dass die motion reduced ist so wie du es gerade beschrieben hast dann kann ich

11:52.320 --> 11:56.320
doch webentwickler die ja tendenziell dazu neigen über lange animationen zu

11:56.320 --> 12:00.320
machen und zu verspielt zu werden doch nicht über den weg trauen oder also für

12:00.320 --> 12:05.320
wen ist dieses feature ich kann mich ja wenn ich jetzt sozusagen den kurz einmal

12:05.320 --> 12:09.320
brauche wenn das wenn ich zu viel animationen habe kann ich mich ja nicht

12:09.320 --> 12:12.320
darauf verlassen dass das vernünftige webentwickler in weiser voraussicht

12:12.320 --> 12:15.320
abschalten sondern ich muss doch eigentlich andere wege finden das zu

12:15.320 --> 12:19.320
machen mit meinen user style sheets alle transitions abschalten oder mein

12:19.320 --> 12:24.320
betriebssystem irgendwie einrichten oder ähnliches ist das nicht so ja also

12:24.320 --> 12:29.320
wahrscheinlich wäre das der sichere weg genau also was genau und dann kann

12:29.320 --> 12:33.320
es vielleicht noch sein dass irgendwelche javascript gesteuerten animationen

12:33.320 --> 12:41.320
da da könnte man ja dann so ein match media abfrage machen genau die frage

12:41.320 --> 12:45.320
ist ob das überhaupt jemand macht aber das ist wieder sehr schön dass du wieder

12:45.320 --> 12:48.320
auf die webentwickler perspektive gehst und in meinem kopf sofort der

12:48.320 --> 12:52.320
entsprechende prototype override gebaut wurde mit dem ich halt irgendwie element

12:52.320 --> 12:56.320
und animate überschreiben kann mit das macht einfach nichts ich traue den

12:56.320 --> 13:03.320
webentwickler nicht ich glaube da hast du recht genau weil ich meine wenn ich

13:03.320 --> 13:05.320
jetzt so in meinen alltag reingucke ich muss letztens irgendwie dark mode

13:05.320 --> 13:08.320
implementieren habe halt allein schon festgestellt das klappt schon allein

13:08.320 --> 13:12.320
deshalb nicht weil auf linux der chrome die user preference ist einfach nicht

13:12.320 --> 13:16.320
umsetzt so ich stelle mein betriebssystem ein ich hätte gern dark mode das geht

13:16.320 --> 13:19.320
mit firefox auch aber chrome sagt halt eben nicht kriege ich sie halt trotzdem hier

13:19.320 --> 13:23.320
light mode und selbst dann habe ich festgestellt dass wenn ich webseiten

13:23.320 --> 13:26.320
nutze ich das gerne hin und wieder einfach auch manuell umschalte mit halt dem

13:26.320 --> 13:29.320
ding was die leute da in der ecke meistens haben also ein switch damit man

13:29.320 --> 13:33.320
das halt eben umschalten kann zwischen dark und light und wenn man schon so was

13:33.320 --> 13:36.320
bauen muss dann ist es ja eigentlich nur umso schwieriger geworden das ordentlich

13:36.320 --> 13:39.320
zu machen wenn man halt eben auch diese preference damit rein rechnen muss

13:39.320 --> 13:43.320
weil du hast ja entweder eine explizite einstellung oder ein media query switch

13:43.320 --> 13:46.320
halt eben über die preferences vom betriebssystem und wie findest du da jetzt

13:46.320 --> 13:54.320
raus was jemand wirklich haben möchte ja so ein bisschen so wie so das welche

13:54.320 --> 14:00.320
lokalisierte version meiner seite soll ich jetzt weiter leiten also macht das

14:00.320 --> 14:05.320
nur also die besuchende personen über über so ein umschalter oder gucke ich

14:05.320 --> 14:11.320
auf die quasi sprache die im http da übermittelt wird

14:11.320 --> 14:16.320
ja und selbst dann kannst du ja längst noch nicht alles umschalten irgendwie so

14:16.320 --> 14:22.320
ja ja das kommen wir da in input type number und ähnliche späße ja das ist

14:22.320 --> 14:27.320
auf jeden fall komplex und ich finde auch je mehr dieser dinge man einbaut

14:27.320 --> 14:34.320
desto mehr also multiversen hat man dann sozusagen die man testen muss neben

14:34.320 --> 14:40.320
auch noch quasi desktop und vielleicht tablet und mobile allen dazwischen dann

14:40.320 --> 14:45.320
hat man noch leitmotor dark mode und das ganze dann noch mal multipliziert mit

14:45.320 --> 14:50.320
einmal mit motion einmal ohne und also das finde ich schon sehr schwer und ich

14:50.320 --> 14:53.320
finde auch so ein dark mode ein anständigen zu bauen das ist auch richtig

14:53.320 --> 14:58.320
arbeit das gibt ja hier diesen dark mode für arme wo man quasi über css filter

14:58.320 --> 15:03.320
dann die die seite invertiert und dann alle bildelemente sich nimmt und die wieder

15:03.320 --> 15:08.320
zurück invertiert und dann noch quasi am fahrbrat dreht damit rot das nach

15:08.320 --> 15:12.320
dem invertieren grün geworden ist dann auch wieder quasi zurück ins rot gedreht

15:12.320 --> 15:18.320
wird da kommt man aber eben nur also das dann wieder pareto prinzip mit wenig

15:18.320 --> 15:23.320
aufwand schafft 80 prozent der strecke aber so richtig cool ist es nicht ist es

15:23.320 --> 15:26.320
nicht aber zum beispiel auf meinem firefox den ich auf meinem mobilgerät

15:26.320 --> 15:30.320
verwende habe ich eine extension installiert die macht halt sowas in

15:30.320 --> 15:34.320
der richtung weil ich halt den webseiten nicht zu trauen kann dass sie meine

15:34.320 --> 15:38.320
preferences irgendwie ernst nehmen und ich krieg wirklich schleuder trauma wenn

15:38.320 --> 15:41.320
ich irgendwie so mein dunkles betriebssystem habe und dann plötzlich so

15:41.320 --> 15:46.320
bamm knallweise seite es geht halt nicht sieht halt jetzt doof aus und manchmal

15:46.320 --> 15:52.320
ist auch wirklich zeug ernsthaft unlesbar aber was will man machen die web

15:52.320 --> 15:56.320
entwickeln entwickeln setzen das halt auch nicht richtig um und das wenn sie es

15:56.320 --> 15:59.320
unrichtig umsetzen wollen die zugangsdaten zu ihren jugendzünden von vor 20

15:59.320 --> 16:03.320
jahren haben sie halt auch nicht mehr und dann sind die halt so wie sie sind ja ich

16:03.320 --> 16:08.320
finde das schon also schon grundsätzlich sinnvoll dass man dass man sich

16:08.320 --> 16:15.320
dann selber hilft mit eigen user styles also die sind ja tatsächlich auch bei

16:15.320 --> 16:21.320
design vorgesehen dass die gibt und dass die genau die glaube die genau die

16:21.320 --> 16:28.320
override ja per default in der kaskade auch die website styles richtig und nur

16:28.320 --> 16:33.320
bei importen dreht sich das wenn sie importen haben haben sie die haben

16:33.320 --> 16:36.320
sie die haben sie das letzte wort aber sonst ist das irgendwie noch komplizierter

16:36.320 --> 16:40.320
aber auch das ist halt wieder das sind dann in multiversen wieder durch die halt

16:40.320 --> 16:48.320
keiner durchsteigt ja genau ja vielleicht auch einfach nochmal hier an die höhere

16:48.320 --> 16:54.320
abgegeben wie wie macht ihr das vielleicht wollte uns da mal irgendwie was

16:54.320 --> 17:01.320
schreiben in unserem community slack unter draft.community da findet ihr den

17:01.320 --> 17:06.320
weg dahin genau also ich finde das alles auch gut ich finde auch gut dass es

17:06.320 --> 17:14.320
gibt aber ich das macht halt die arbeit nicht einfacher beileibe nicht

17:14.320 --> 17:19.320
aber hey dafür kriegen wir neue neue power tools mit denen wir die arbeit noch

17:19.320 --> 17:26.320
interessanter gestalten können ja das wäre es CSS custom properties und damit

17:26.320 --> 17:31.320
meine ich jetzt nicht die ganz normalen CSS variablen mit zwei dashes davor für

17:31.320 --> 17:35.320
irgendwie so theming und so das ist ja im prinzip nur langweilige string

17:35.320 --> 17:39.320
interpolation man kann ja auch richtige eigene properties deklarieren mit

17:39.320 --> 17:43.320
ad property was ich noch nie gemacht habe aber ich habe ja zum glück hier ein

17:43.320 --> 17:48.320
kompetenten mitarbeiter im call chef erzählt was macht ad property und warum

17:48.320 --> 17:52.320
ist das gut dass wir das jetzt in safari auch demnächst haben werden oder zu

17:52.320 --> 17:57.320
wissen also ich finde das finde ich ziemlich ziemlich gut ich stehe

17:57.320 --> 18:01.320
total auf dieses ad property ich finde ja auch dass das so das beste

18:01.320 --> 18:07.320
abfallprodukt von CSS hudini ist während der rest von hudini glaube ich

18:07.320 --> 18:13.320
meiner meinung nach dann irgendwie langsam in die tonne wandern kann und

18:13.320 --> 18:18.320
haben wir eine revision zu genau wir haben auch eine revision dazu die kann

18:18.320 --> 18:23.320
wir nochmal verlinken also kurz gesagt du kannst halt einfach custom

18:23.320 --> 18:30.320
properties damit typen also CSS variablen sozusagen weil und der browser

18:30.320 --> 18:36.320
wenn du die types dann kann der browser die eben auch interpolieren und damit

18:36.320 --> 18:42.320
animieren und nützlich ist sowas bei zum beispiel

18:42.320 --> 18:49.320
wenn man gradients mit custom properties irgendwie zusammensetzt dann war es

18:49.320 --> 18:53.320
eben bisher so dass wenn man wenn man die farben oder die hintergrundfarben

18:53.320 --> 18:58.320
oder so animieren wollte und das ist eben eine custom property dann konnte

18:58.320 --> 19:03.320
der browser das nicht und dann sind die im prinzip wie so wie so ein bit von

19:03.320 --> 19:09.320
null auf eins geflippt und wenn man eben dann diese variable zum beispiel

19:09.320 --> 19:17.320
als color typed dann weiß der browser alles klar von der zu der farbe da kann

19:17.320 --> 19:21.320
ich folgendermaßen interpolieren und dann hat man eben eine animation eine

19:21.320 --> 19:25.320
flüssige genau man muss halt weg ich nochmal herausstellen normale css

19:25.320 --> 19:29.320
variablen so irgendwie mein margin oder so auch wenn ich den auf null setze

19:29.320 --> 19:33.320
steht er halt im prinzip auf dem string null also das ist halt für css nicht

19:33.320 --> 19:37.320
ersichtlich dass da irgendwie ein typ drin wohnt und deswegen kann man damit

19:37.320 --> 19:40.320
eine ganze menge sachen halt nicht tun wie zum beispiel diese interpolations

19:40.320 --> 19:44.320
geschichte ich meine das eigentlich spannende ist natürlich wenn man dann

19:44.320 --> 19:47.320
schritt zurücktritt das was du gerade beschrieben hast das properties

19:47.320 --> 19:53.320
tatsächlich typen haben das ist ja sozusagen dann auch so die eine api

19:53.320 --> 19:58.320
zumindest um wirklich naja mit css properties oder beziehungsweise deren

19:58.320 --> 20:03.320
werte tatsächlich in irgendwie einer geteibten weise verwenden zu können

20:03.320 --> 20:06.320
das ist ja normalerweise bei css nicht der fall das ist ja alles irgendwie einfach

20:06.320 --> 20:09.320
nur ein riesiger hoffen strings und die werden dann irgendwann innerhalb der

20:09.320 --> 20:13.320
css engine uminterpretiert dass irgendwie null eine zahl sein könnte oder

20:13.320 --> 20:16.320
irgendwie sieben pixel halt am ende tatsächlich irgendeine zahl in pixel

20:16.320 --> 20:21.320
bedeuten oder sieben am oder was auch immer und das macht halt ja eine ganze

20:21.320 --> 20:24.320
menge also nicht nur da halt eben diese interpolation für animation das ist

20:24.320 --> 20:26.320
halt eben das eine aber zum anderen macht es natürlich auch das programmieren

20:26.320 --> 20:30.320
viel einfacher wenn ich halt irgendwie mit javascript was abfragen kann irgendwie

20:30.320 --> 20:34.320
wie breit ist das ding und ich kriege halt eine information zurück wenn da der

20:34.320 --> 20:38.320
string drin steht irgendwie im 50 am dann kann ich damit ja exakt nichts

20:38.320 --> 20:41.320
anfangen ich müsste das element hier wirklich messen um damit an der ende

20:41.320 --> 20:45.320
irgendwas anzufangen oder manuell passen gottbeware jetzt kann mir der browser halt

20:45.320 --> 20:49.320
eben sagen das sind 50 und zwar in der einheit em und ich muss das nicht mehr

20:49.320 --> 20:54.320
manuell auseinander passen was so diverse css manipulationen natürlich

20:54.320 --> 20:59.320
einfacher bis überhaupt erst möglich macht ich hatte ja mal du unterhands hatte

20:59.320 --> 21:06.320
doch mal dieses projekt namens warhul und ich glaube da habt ihr da drauf ich glaube

21:06.320 --> 21:11.320
das ist dann das type css o.m. ne heißt das dann nope es war nicht das typed o.m.

21:11.320 --> 21:14.320
weil das ja keiner unterstützt hat okay aber der chrome hat es unterstützt

21:14.320 --> 21:19.320
damals schon aber das habt ihr trotzdem dann nicht genutzt weil es wäre halt

21:19.320 --> 21:23.320
keine universelle lösung gewesen der chrome hat das unterstützt ist jetzt

21:23.320 --> 21:26.320
eine sehr sehr freundliche auslegung dessen was der machen konnte also der konnte

21:26.320 --> 21:32.320
halt wirklich für ich glaube also zu dem zeitpunkt für ausschließlich measures

21:32.320 --> 21:36.320
also length konnte er das aber schon bei farben hat es halt auch aufgehört

21:36.320 --> 21:39.320
hatte der einfach keinen support für also ich konnte den abfragen mit dem type

21:39.320 --> 21:43.320
o.m. sag mal gibt mir mal hier irgendwie so die maße hat das gemacht wie ich

21:43.320 --> 21:47.320
gerade beschrieben habe das sind 50 einheiten und die einheit ist em okay

21:47.320 --> 21:51.320
wunderbar damit kann man arbeiten aber schon bei farben kam halt am ende

21:51.320 --> 21:56.320
so ein o.p.k. objekt raus wo man wirklich nur sagen konnte aha das ist halt ein

21:56.320 --> 21:59.320
o.p.k. objekt das repräsentiert irgendein wert und ich kann das ding

21:59.320 --> 22:02.320
stringifizieren bekommt dann also irgendwie ein hexadecimalen farbcode

22:02.320 --> 22:06.320
raus aber das ist mehr operation als stringifizieren gab es da nicht drin

22:06.320 --> 22:09.320
irgendwie so einfach komponente extra hier dann mal wieder bei unseren manuellen

22:09.320 --> 22:15.320
rumpasen das war wirklich finster damals ja weil weiß halt das ist ja immer

22:15.320 --> 22:19.320
noch finster ich gehe fest davon aus weil es ist halt einfach auch ein riesiges

22:19.320 --> 22:23.320
breit was da gebohrt wird das ist ja ja wieder so ein klassischer web

22:23.320 --> 22:27.320
entwicklungsproblem fall wo man irgendwie was vorhandenes hat es gibt

22:27.320 --> 22:31.320
css es gibt auch das cssom und es gibt code der sich darauf verlässt dass es

22:31.320 --> 22:35.320
funktioniert wie es halt eben schon immer war und jetzt muss man nachträglich

22:35.320 --> 22:39.320
eine low level api an das high level konstrukt dran flanschen womit man das

22:39.320 --> 22:43.320
high level konstrukt das css dann bedienen kann und das führt halt eben

22:43.320 --> 22:46.320
dazu dass das was halt eben danach gelagert kommt automatisch mit irgendwelcher

22:46.320 --> 22:51.320
legacy last belastet ist und ja oftmals auch nicht irgendwie intern konsistenz

22:51.320 --> 22:55.320
sein kann einfach weil die high level welt von der es abgeleitet ist ja schon

22:55.320 --> 22:59.320
in nicht in sich konsistent ist das kennt man ja aus webkomponens da kommt es ja

22:59.320 --> 23:03.320
darauf an wann das ding initialisiert wurde ob man dann irgendwie seinen kind

23:03.320 --> 23:06.320
inhalt sehen sehen kann oder ob der noch und definiert ist das wirkt sich dann

23:06.320 --> 23:09.320
halt eben auch bei css auf und das ist halt eben nicht implementiert wird oder dass

23:09.320 --> 23:13.320
die browser so langsam damit sind habe ich halt vollstes verständnis für weil

23:13.320 --> 23:17.320
mal ganz ehrlich das interessiert ja auch kaum jemanden also das hätte mir damals

23:17.320 --> 23:20.320
echt das leben sehr viel leichter gemacht und irgendwie alles viel toller

23:20.320 --> 23:26.320
gemacht und das sowas wie ad property ist super und das brauchen wir mit so ein bisschen

23:26.320 --> 23:29.320
air quotes aber das brauchen halt wir und ich glaube die meisten leute die halt

23:29.320 --> 23:33.320
einfach nur damit zu kämpfen haben dass ihre webseite einigermaßen konsistent

23:33.320 --> 23:38.320
aussehen soll den ist das weniger wichtig als irgendwie keine ahnung neuer css

23:38.320 --> 23:41.320
filter oder sowas damit kann man einfach mehr anfangen und ich glaube mehr

23:41.320 --> 23:47.320
leuten was gutes tun wäre halt zu meiner einschätzung der lage ja ich glaube

23:47.320 --> 23:55.320
genau es ist halt andererseits eine relativ niedrig hängende fruit also frucht

23:55.320 --> 24:04.320
weil im prinzip kennt css ja die typen schon also man musste jetzt eben quasi

24:04.320 --> 24:12.320
nur noch rein bauen dass dass das eben diese typen auch auf custom properties oder

24:12.320 --> 24:19.320
mit denen genutzt werden kann dieses typen das ist ja dann wieder was das steckt

24:19.320 --> 24:24.320
da zwar theoretisch auch irgendwie drin aber das ist halt wie du schon gesagt

24:24.320 --> 24:30.320
hast einfach ein dickeres brett und man kann halt schon nette sachen machen

24:30.320 --> 24:34.320
ich meine so speziell das typ system ich meine das ist ja am ende kein unterschied

24:34.320 --> 24:37.320
weil die typen die du halt auf normalen properties vorfindest auf irgendwie

24:37.320 --> 24:40.320
color und background position oder so sind ja am ende die gleichen typen die du

24:40.320 --> 24:47.320
auch verwendest für deine ad property regeln also das muss man dann ja da

24:47.320 --> 24:52.320
wo das andere gleich genau dazu genau genau aber es ist halt natürlich auch

24:52.320 --> 24:54.320
das vergrößert natürlich für die browser so die gesamte oberfläche von

24:54.320 --> 24:58.320
zeug dass man testen muss weil du hast dann ja neben dem alten css som ja auch

24:58.320 --> 25:03.320
typen muss alles getestet und supportet und gebackfixt werden macht es halt auch

25:03.320 --> 25:08.320
nicht einfacher nicht das stimmt ich meine wo wir schon mal dabei sind könnten

25:08.320 --> 25:13.320
wir eben auch noch erwähnen das ja vom typen auch eine ganze Menge kram in

25:13.320 --> 25:17.320
diesem technologie preview 161 auch aktiviert wird und das ist nicht nur

25:17.320 --> 25:22.320
ad property als spielt halt zusammen sondern auch das typen an sich wird hier

25:22.320 --> 25:25.320
enabled und eine ganze Menge dinge apis und so werden da unterstützt die sind

25:25.320 --> 25:31.320
dann da auch mit verfügbar ja ich würde mal interessieren also warum weil das

25:31.320 --> 25:38.320
ja viel arbeit ist was die dazu bewegt hat dieses typen zu implementieren

25:38.320 --> 25:44.320
weil ich weiß nicht ob die so diesen hudini weggehen wollen das glaube ich hier

25:44.320 --> 25:50.320
nicht also ich denke die sehen das auch wahrscheinlich eher so das paint api und

25:50.320 --> 25:56.320
layout api dass das alles irgendwie das aus denen wahrscheinlich nichts wird oder

25:56.320 --> 26:05.320
aber was der use case ist dass sie sagen keel des typen das brauchen die leute so

26:05.320 --> 26:11.320
hart dass wir das implementieren also ich mein sag ja so du willst einen eignen

26:11.320 --> 26:15.320
der will sein eigen effekt irgendwie eine webseite bauen wenn es hart auf hart

26:15.320 --> 26:19.320
kommt kannst du immer hingehen und kannst das kennenwisselement rausholen

26:19.320 --> 26:24.320
also du kriegst immer irgendwie deine pixel da auf den bildschirm das normale

26:24.320 --> 26:32.320
cssom ist so hart eingeschränkt das ist halt wirklich wirklich im prinzip also du

26:32.320 --> 26:36.320
kannst es behandeln als wäre es nicht da du kannst halt irgendwie so die style

26:36.320 --> 26:39.320
property von dem element setzen und du kannst wenn es hoch kommt irgendwie so

26:39.320 --> 26:42.320
über die style rule sind zum style sheet drüber iterieren aber wenn du

26:42.320 --> 26:46.320
irgendwas machen willst was auch nur minimal advance da ist als das mitjar

26:46.320 --> 26:51.320
was kript ist es halt wirklich ziemlich schwierig und du hast da wirklich so

26:51.320 --> 26:56.320
fälle wo einfach so gesagt werden muss sorry webentwickler geht halt nicht also

26:56.320 --> 26:59.320
ich sage dir mal ein beispiel du hast eine zusammengesetzte property wie

26:59.320 --> 27:02.320
background wo du halt eben color und background image und background position

27:02.320 --> 27:06.320
und so weiter alles reinschreibst und sobald du halt hingehst und du hast

27:06.320 --> 27:10.320
da eine normale css variable drin die ganz normale mit den zwei dashes und du

27:10.320 --> 27:15.320
baust in diese property rein dann ist allein das vorhandensein von so einer

27:15.320 --> 27:21.320
css variable schon so schon grund dafür dass wenn du abfragst hey was ist in

27:21.320 --> 27:24.320
die background position von diesem element dass du als antwort zurückbekommst

27:24.320 --> 27:28.320
den leeren string nicht unterscheidbar von das ist irgendwie auf zum beispiel

27:28.320 --> 27:31.320
den leeren string oder irgendwas anderes gibt ja CSS properties oder leere

27:31.320 --> 27:34.320
string erlaubt das background position ist ein schlechtes beispiel aber wo du

27:34.320 --> 27:38.320
halt den leeren string zurückbekommst warum weil du halt eine css variable

27:38.320 --> 27:42.320
irgendwo in die ganze background deklaration reingeschrieben hast dadurch

27:42.320 --> 27:46.320
weil das ja nur ein string replacement ist ist es für css nicht mehr nachvollziehbar

27:46.320 --> 27:51.320
ob man jetzt damit einen wert wie zum beispiel die background position 50

27:51.320 --> 27:54.320
prozent 50 prozent reingeschrieben hat oder die background position und die

27:54.320 --> 27:58.320
color oder ein element aus der background position also einer von den

27:58.320 --> 28:04.320
zwei zahlen oder oder oder also die custom property kann quasi für mehrere

28:04.320 --> 28:10.320
ja longhands longhand properties stehen gleichzeitig oder auch nicht genau

28:10.320 --> 28:13.320
nicht kann sondern könnte und allein weil sie weil es könnte kann dir das css um

28:13.320 --> 28:18.320
dann keine antwort mehr darauf geben was ist die background position und die ant

28:18.320 --> 28:21.320
der antwort die du bekommst ist halt nicht unterscheidbar in einigen umständen

28:21.320 --> 28:26.320
von ist nicht gesetzt ja und dann stehst du halt rum und versuchst halt

28:26.320 --> 28:29.320
rauszufinden wie die background position ist und die einzige antworte die dir

28:29.320 --> 28:32.320
halt eben gegeben werden kann ist das halt fundamental unmöglich das mit

28:32.320 --> 28:38.320
sicherheit rauszufinden und das ist schon hart schwach genau wobei kannst du das

28:38.320 --> 28:46.320
denn nicht was ist denn mit get computed style ist das also nicht den computer

28:46.320 --> 28:50.320
nicht den computer style haben willst weil du zum beispiel sowas baust du halt die

28:50.320 --> 28:54.320
css deklaration also tatsächlich den input vergleichen möchtest hat das

28:54.320 --> 29:00.320
ding als background position wirklich gesetzt bekommen keine ahnung 4 em 50

29:00.320 --> 29:05.320
rem mal so als beispiel weil du ja mit dem css interagieren willst die

29:05.320 --> 29:10.320
computer styles sind ja am ende die tatsächlich realisierten ich weiß

29:10.320 --> 29:13.320
jetzt gerade den spezifikations nicht mehr begriff nicht mehr aber es gibt ja

29:13.320 --> 29:15.320
die computer styles sind dann nachher kommt ja die wirkliche wirkliche

29:15.320 --> 29:19.320
wahrheit also wie es wirklich am ende umgesetzt und ausgerechnet ist das

29:19.320 --> 29:23.320
kriegste immer raus mit eben get computed style aber halt nicht wie du

29:23.320 --> 29:26.320
dahin gekommen bist und wenn du das wissen willst dann ist halt Schluss und

29:26.320 --> 29:30.320
das ist ja eigentlich css der weg zu den computer styles die computer styles sind

29:30.320 --> 29:39.320
ja nur das ergebnis vom css das war echt ein war echt also ist ja nichts

29:39.320 --> 29:43.320
geworden weil aus einer reihe von gründen aber meine fresse ich habe so viel

29:43.320 --> 29:48.320
gelernt und wenn ich eins sagen kann das alte css um hat fast ich nie wieder an

29:48.320 --> 29:52.320
das habe ich gelernt das hast du auf hier für den podcast eigentlich gemacht

29:52.320 --> 29:57.320
damit du damit du uns davon erzählen kannst so sieht es nämlich aus alles für

29:57.320 --> 30:03.320
das publikum aber hier ein habe ich noch eine frage hätte ich noch zu diesen

30:03.320 --> 30:09.320
css custom property zeug das woran ich gerade arbeite macht eine ganze

30:09.320 --> 30:13.320
Menge css generieren also wirklich ganz ganz viel mit ganz ganz vielen

30:13.320 --> 30:19.320
komplizierten kalke war geschichten und sowas und ich fühle mich ja ein bisschen

30:19.320 --> 30:23.320
gebissen mittlerweile davon dass css ja keine sonntags oder runtime erbos mir

30:23.320 --> 30:29.320
durchgibt also ich lade meine webseite neu und das sieht halt nicht aus wie es

30:29.320 --> 30:34.320
so aussehen soll und im idealfall merke ich das im schlimmsten fall nicht ist

30:34.320 --> 30:37.320
das eigentlich noch angemessen also ich meine das verhalten dass es weiter

30:37.320 --> 30:41.320
funktioniert ist korrekt weil das ist wie css funktioniert progressive enhancement

30:41.320 --> 30:48.320
etc das soll so bleiben aber sollte nicht irgendwie eine ungültige css

30:48.320 --> 30:51.320
konstruktion uns mittlerweile mal gemeldet wird und ich meine jetzt halt

30:51.320 --> 30:55.320
nicht irgendwie so ein css validator den ich über meinen style sheet meine css

30:55.320 --> 30:58.320
darüber laufen lassen kann weil wenn ich mit javascript irgendwelches css

30:58.320 --> 31:02.320
generiere was ich halt eben gerade tue da nutzt mir das nicht ich will ja wissen

31:02.320 --> 31:05.320
was das was ich den browser zu essen gebe ob das tatsächlich noch irgendwelche

31:05.320 --> 31:10.320
gültigkeits anforderungen erfüllt gibt es da was oder sollte es das geben oder

31:10.320 --> 31:17.320
ist das käse spinnig also ich glaube das ist ja so zumindest in firefox da

31:17.320 --> 31:23.820
bekommst du ja so was sind das so notifications auf der konsole wenn du

31:23.820 --> 31:32.320
irgendwie also zumindest teilweise wenn du so mumpits werte setzt glaube ich aber

31:32.320 --> 31:39.320
das ist halt nix was du per javascript glaube ich abgreifen kannst also das

31:39.320 --> 31:43.020
müsste ich gar nicht haben aber zum beispiel irgendwie so ich hatte halt mal so

31:43.020 --> 31:46.840
ein brainfahrt wo ich irgendwie so kalk eine einwert mit einheit geteilt durch

31:46.840 --> 31:50.880
anderen wert mit einheit gemacht habe was halt offensichtlich nicht geht weil

31:50.880 --> 31:55.120
ergibt ja keinen sinn so aber was passiert halt die ganze expression ist

31:55.120 --> 31:58.520
halt eben einfach nur wird nicht evaluiert er liefert kein ergebnis

31:58.520 --> 32:04.120
funktioniert nicht was ist wenn du das in css punkt supports reinsteckst und

32:04.120 --> 32:09.360
guckst was also was da auskommt also ich meine dann du würdest es dann missbrauchen

32:09.360 --> 32:17.840
für was jetzt genau also wie würde ich das machen naja du kannst ja ich weiß

32:17.840 --> 32:23.840
nicht ob das ob das ob dann falls so came aber wenn du da eben einen ungültige

32:23.840 --> 32:32.840
deklaration reinsteckst also ich meine das müsste funktionieren aber wie

32:32.840 --> 32:36.800
implementiere ich das denn also ich generiere meinen javascript string mit

32:36.800 --> 32:41.780
50.000 css regeln drin und ich will mitbekommen wenn das nicht funktioniert

32:41.780 --> 32:46.520
möglicher im idealfall nicht nur mit deine 50.000 zeilen sind kaputt sondern

32:46.520 --> 32:52.560
in dieser stelle ist es halt eben suboptimal dieser kalkausdruck den du

32:52.560 --> 32:58.840
da gebaut hast der geht nicht ja schwierig wüsste jetzt auch nicht also

32:58.840 --> 33:04.800
ich glaube also teilweise kannst du es halt noch in den dev tools sehen also da

33:04.800 --> 33:09.360
gibt es jetzt auch immer mehr solche dass du so anmerkungen bekommst nach dem

33:09.360 --> 33:17.400
auto hier wenn du quasi diese property oder das so setzt dann funktioniert

33:17.400 --> 33:21.680
sagen wir mal float nicht mehr oder sowas also dann so hier dein float ist

33:21.680 --> 33:30.840
kaputt weil du hast im parent container display flex gemacht oder so ja genau

33:30.840 --> 33:35.400
das ist ja auch nicht das was du willst und das funktioniert ja auch nur für

33:35.400 --> 33:39.880
bestimmte dinge ja es ist ja auch das ist ja auch mehr so ein das ist ja mehr

33:39.880 --> 33:44.120
so situational awareness so das ist irgendwie so weißt du dieses ding im

33:44.120 --> 33:48.880
flugzeug was der sagt pull up terrain wenn du auf dem berg zu fliegst ja ich

33:48.880 --> 33:52.640
hätte jetzt mehr gern so mehr gern so ein ikam output wo halt so drin steht das

33:52.640 --> 33:57.400
und das ist gerade kaputt an deinem gerät und ich kann dir genau sagen welches

33:57.400 --> 34:04.480
teil das jetzt ist ja und was ist hier mit steilend also jetzt mal irgendwie

34:04.480 --> 34:08.520
ungeachtet dessen ob du das jetzt wie du das da bei dir im projekt jetzt genau

34:08.520 --> 34:14.960
verbaut aber das macht sowas auch ja aber ist halt die frage ob der den

34:14.960 --> 34:18.160
ganzen layers of interaction folgen kann also stell dir vor ich habe einen

34:18.160 --> 34:23.320
kalkausdruck war eins geteilt durch war zwei und in war zwei ist eine einheit

34:23.320 --> 34:29.200
drin das kann der auch gar nicht weil das ja von deiner domstruktur abhängt

34:29.200 --> 34:33.600
auch ja genau aber ich meine am ende sind wir ja bei deinen computer styles von

34:33.600 --> 34:39.240
vorhin irgendwann kommt halt die wahrheit zu tage und dann müsste finde ich

34:39.240 --> 34:44.160
müsste es einen reporting mechanismus geben der da sagt dieses css hier das

34:44.160 --> 34:47.200
funktioniert so nicht und sei es halt nur dass mir die deklaration genannt wird

34:47.200 --> 34:51.160
muss ja nicht mal irgendwie so eine super genaue diagnostik sein von wegen der

34:51.160 --> 34:54.600
spezifischen fehler kalk geteilt durch element mit einheit funktioniert nicht

34:54.600 --> 35:00.680
sondern einfach nur mehr als einfach still scheitern so was halt auch ein

35:00.680 --> 35:03.560
bisschen schwierig ist weil du willst ja progressive enhancement haben aber das

35:03.560 --> 35:07.160
ist ja wahrscheinlich ein kategorie fehler zu sagen unbekannte property oder

35:07.160 --> 35:10.960
unbekannter value versus ich weiß was du versuchst zu machen aber das

35:10.960 --> 35:15.920
funktioniert nicht und hier ist die meldung die dich dahin weist also mit

35:15.920 --> 35:19.040
dieser immer weiter steigenden komplexität von css mit property und

35:19.040 --> 35:23.120
hudini und hast du nicht gesehen wäre es glaube ich mal an der zeit dass die

35:23.120 --> 35:26.120
devtools nicht einfach nur aufrüsten mit neuen buttons die man anklicken kann so

35:26.120 --> 35:29.640
und wirklich mit solchen reporting mechanismen wie immer die auch aussehen

35:29.640 --> 35:33.440
ich bin da halt nur persönlich gerade von gebissen deswegen klar war das so in

35:33.440 --> 35:39.080
meinem kopf herum also tatsächlich ist es ist es ja so dass die ich glaube dass die

35:39.080 --> 35:44.840
devtool machen der verschiedenen browser auch total interessiert sind an solchen

35:44.840 --> 35:49.480
Dingen also weil immer wenn ich mal welche getroffen habe und mich mit den

35:49.480 --> 35:54.480
unterhalten habe und dann eben auch gesagt habe so so im css Bereich zum

35:54.480 --> 36:00.720
Beispiel es wäre halt einfach cool wenn die devtools ein darauf hinweisen würden

36:00.720 --> 36:08.200
dass man bestimmte dinge implizit quasi auslöst durch das explizite setzen

36:08.200 --> 36:12.480
bestimmter properties also da kommt ja dann je nachdem was man da benutzt

36:12.480 --> 36:15.320
kommen ja noch so ein paar sachen im gepack wie zum beispiel ist an eben

36:15.320 --> 36:22.840
floats nicht gehen und so da gibt es ja noch ganz ganz viel mehr und so was finde

36:22.840 --> 36:29.160
ich halt einfach total total gut und die sind da auch absolut interessiert dran

36:29.160 --> 36:36.800
deswegen also musst du da einfach nur den den case für machen und und dann

36:36.800 --> 36:41.120
dass die richtigen leuten einfach schicken und also ich glaube dass die

36:41.120 --> 36:45.720
schon offen wären für sowas und ich finde das jetzt auch tatsächlich sinnvoll

36:45.720 --> 36:50.680
ich glaube aber dass ich glaube es ist mehr als nur den case machen also ich

36:50.680 --> 36:53.880
glaube es lässt sich relativ leicht fordern so wie ich jetzt hier sitze

36:53.880 --> 37:02.000
damit man ja viele also warum sollst du es nicht auch machen und dann ja das

37:02.000 --> 37:05.360
ist ja ein bisschen mühe geben da ist vielleicht auch die chancen einigermaßen

37:05.360 --> 37:10.760
ernst genommen zu werden ja das müsste ich ja tun weil sonst würde ich ja

37:10.760 --> 37:17.720
aussehen wie ein vollhuhn ganz genau ja und vielleicht kann man ja sowas zumindest

37:17.720 --> 37:20.480
mal sowas mit so einer stylend implementierung ja zumindest mal prototypen

37:20.480 --> 37:23.440
dass man so eine browser extension schreibt und irgendwie so sagt das macht

37:23.440 --> 37:27.200
nicht was ich will es macht irgendwie nur so 30 prozent von dem aber event

37:27.200 --> 37:31.440
100 prozent von dem machen würde was ich gerne hätte siehe text dann könnte

37:31.440 --> 37:35.120
das so sein und dann wäre das vielleicht nützlich ja ja genau also ein

37:35.120 --> 37:39.160
browser extension baut es natürlich auch immer super dass er dann auch je nach

37:39.160 --> 37:42.800
dem was also wie beliebt die dann ist und was für einen uptake die hat oder was

37:42.800 --> 37:46.880
die leute darauf eben für ein feedback geben ist natürlich für die browser

37:46.880 --> 37:52.600
mache dann auch noch mal so ein ding wo die dann sehen können hey das finden

37:52.600 --> 37:56.920
schon viele leute gut oder es interessiert kann sau kann ja auch sein und

37:56.920 --> 38:01.640
dann sparen wir uns die arbeit und machen lieber andere dinge

38:01.640 --> 38:05.840
ja okay dann habe ich also jetzt hausaufgaben wunderbar ja aber finde ich

38:05.840 --> 38:13.760
gut bescheid wenn du das wenn du da irgendwie was hast dann würde ich da

38:13.760 --> 38:19.280
auch die werbetrommel rühren für okay das ist das ist ein deal das machen wir

38:19.280 --> 38:27.800
so genau dann haben wir hier wir haben dann sind ein paar fixes für die hess

38:27.800 --> 38:34.120
pseudo klasse da nehme ich an wird sowieso noch immer wieder was geben das

38:34.120 --> 38:37.400
hat war gab es auch im chrome browser ganz am anfang als die has freigeschaltet

38:37.400 --> 38:43.840
haben die das diesen invalidierungsproblemen öfters mal haben weil

38:43.840 --> 38:51.680
hess ja quasi die die richtung umkehrt in die dinge irgendwie ablaufen und das

38:51.680 --> 38:56.600
wird halt gecached damit sie eben auch nicht zu zu viel compute time braucht wenn

38:56.600 --> 39:02.200
irgendwie neue elemente insettiert werden so genau und da gibt es gibt es

39:02.200 --> 39:08.000
einfach cash invalidierungsprobleme immer mal wieder da werden wir glaube ich

39:08.000 --> 39:13.480
auch in in den nächsten releases aller möglichen browser immer wieder so was

39:13.480 --> 39:17.320
sehen wo die dann das dann eben einfangen diese

39:17.320 --> 39:22.040
probleme es ist fast so ein bisschen wie als würde hätte das gestimmt was die

39:22.040 --> 39:25.120
die gesagt haben so was wie hess kannst du nicht machen als hätten die so ein

39:25.120 --> 39:29.280
bisschen recht gehabt also weil es halt mit der normalen zers selektor abbilden

39:29.280 --> 39:32.240
mit dem normalen zers selektor mechanismus nicht funktioniert sondern halt

39:32.240 --> 39:36.400
eben sein eigenes spezialreich werden muss macht man sich da ja schon ne

39:36.400 --> 39:41.800
ganze haufen von schwierigkeiten auf die man sonst nicht hätte andererseits

39:41.800 --> 39:45.600
jetzt hören sie wenigstens auf zu fordern die da sagen sowas wie hess muss

39:45.600 --> 39:53.120
existieren ja ich ja genau also ich finde das ist auf jeden fall schon jetzt

39:53.120 --> 40:00.560
gut genug umgesetzt und gelöst tatsächlich ist es auch so dass das

40:00.560 --> 40:07.520
hess schon einen höheren impact hat so auf das ganze selektor matching ich hatte

40:07.520 --> 40:14.480
nämlich die dieses chrome tracing also dieses interne selektor matching

40:14.480 --> 40:18.440
tracing hatte ich mal auf mein aktuelles projekt angewendet und was kann da

40:18.440 --> 40:24.200
relativ weit oben raus in der tat glaube der ein oder die paar selektoren wo ich

40:24.200 --> 40:29.840
hess verwendet hatte ja liegt halt auf der hand also es wird zwar gecash und so

40:29.840 --> 40:34.600
aber es ist halt einfach für den browser schon deutlich komplexer und du musst

40:34.600 --> 40:38.080
es halt trotzdem irgendwann ja zum ersten mal ausrechnen nützt ja nichts ja

40:38.080 --> 40:48.880
genau also ist der ist ist der impact messbar oder ist ja auch spürbar es

40:48.880 --> 40:53.120
gibt ja diese wenn du leithaus laufen lässt dann gibt es ja immer so dieses

40:53.120 --> 40:58.440
das leithaus bemängelt hey du hast mehr als ich weiß nicht was die grenze

40:58.440 --> 41:04.520
nochmal war 2000 dom notes oder so verwendet und genau das ist ein akuten

41:04.520 --> 41:11.800
fall von reakt ganz schlimm vielleicht vielleicht genau und das liegt eben

41:11.800 --> 41:19.760
daran dass die style calculation oder recalc prozess dann einfach sehr lange

41:19.760 --> 41:25.600
dauert oder das auch der initiale weil eben diese ganzen elemente durchlaufen

41:25.600 --> 41:31.400
diese ganzen selektoren und je nachdem wie diese lektoren aufgebaut sind kann man

41:31.400 --> 41:35.280
das relativ schnell entscheiden dass irgendwie ein element nicht auf diesen

41:35.280 --> 41:40.880
selektor trifft zutrifft oder eben nicht und bei hess ist es natürlich dann

41:40.880 --> 41:48.040
aufwendiger und je je mehr man sein dom auch dann nachträglich noch ändert

41:48.040 --> 41:55.760
desto mehr recalcs löst man aus und es ist im prinzip am enden ein produkt aus

41:55.760 --> 42:05.240
anzahl dom notes und selektor also und da kann kann schon da können einige

42:05.240 --> 42:09.760
hundert mil sekunden sich zusammen leppern wenn man pech hat und das sind

42:09.760 --> 42:17.200
dann wieder so werte die die dann eine rolle spielen in core web vital

42:17.200 --> 42:25.720
zeiten genau und was auch cool ist ist das der also jetzt das dann nicht webkit

42:25.720 --> 42:36.400
sondern die menschen haben diese dieses selektor matching tracing haben die

42:36.400 --> 42:42.360
quasi rausgeholt aus diesem das ist eigentlich so ein interner bereich von

42:42.360 --> 42:45.640
den browser von den chromium browser haben die das in die dev tools geholt mit

42:45.640 --> 42:50.800
der neuesten version normalerweise in diesen profiling crempel drin oder ist

42:50.800 --> 42:55.240
das noch tiefer drin in den nicht in profilding drin also dann machst du dann

42:55.240 --> 43:00.320
da gibt es dann oben einen chromedrop und dann ich glaube tracing und dann

43:00.320 --> 43:06.200
gibt es da dann wird das user interface auch ein bisschen rudimentär genau den

43:06.200 --> 43:10.120
meinte ich eigentlich genau dann hast du hast ja so ganz viele verschiedene

43:10.120 --> 43:14.680
dinge die du da treiben und tracen kannst genau die benutzerfreundlichkeit ist

43:14.680 --> 43:22.040
halt dann einfach völlig weg und das haben die eben in benutzerfreundlich

43:22.040 --> 43:31.720
jetzt nach vorne in die dev tools reingehieft sehr cool genau das ist auf

43:31.720 --> 43:39.200
jeden fall cool was auch cool ist wenn ich überleiten darf ein bisschen neuer

43:39.200 --> 43:43.760
css support auch jetzt hier in der technologie preview in user invalid und

43:43.760 --> 43:51.560
user valid das ist das ist halt eben das was invalid und valid ursprünglich mal

43:51.560 --> 43:57.400
sein wollten aber das ist so ein bisschen ja wie hier pseudo klasse empty

43:57.400 --> 44:02.120
geworden erst auf niemals das implementieren was man sich halt was

44:02.120 --> 44:05.400
einem so die als erste idee in den kopf kommt ist immer eine schlechte idee ist

44:05.400 --> 44:08.040
halt blöd wenn man webstandards macht und man den geist nie wieder in die

44:08.040 --> 44:12.680
flasche bekommt aber ja also das sind die css pseudo klassen für ungültige

44:12.680 --> 44:16.680
formularelemente die erst dann in den ungültig oder gültig zustand

44:16.680 --> 44:20.600
wechseln wenn einmal eine nutzer interaktion stattgefunden hat man macht

44:20.600 --> 44:24.840
das formulare auf und das ist nicht gleich von Anfang an alles rot also das

44:24.840 --> 44:28.760
heißt man war einmal drin oder ich glaube wenn man das formulare abgeschickt hat

44:28.760 --> 44:32.480
dann gilt das eben also wenn man den sub mitknopf drückt dann ist das quasi wird

44:32.480 --> 44:39.920
das auch aktiviert genau ja ich weiß gar nicht wie der browser support da

44:39.920 --> 44:46.640
aussieht ich glaube der ist mittlerweile auch wird langsam gut ich wollte sagen

44:46.640 --> 44:53.360
schalte das sei gar nicht so schlecht ich hätte es auch heute schon nachgeschaut

44:53.360 --> 45:04.880
dann wollen wir uns noch nicht zu früh freuen aber es ist auf jeden fall gut

45:04.880 --> 45:09.600
schon mal ein einbrowser mehr das ist ja nicht so dass sie da bei chrome jetzt

45:09.600 --> 45:14.560
nicht ressourcen hätten um darauf mal zu reagieren und ja es ist auch schon ich

45:14.560 --> 45:17.200
habe mich gerade in den chrome back angeschaut da wird auch überall schon

45:17.200 --> 45:21.200
fleißig kommentiert firefox kann das schon ewigkeiten und euren kommentar

45:21.200 --> 45:26.440
dass das in den webkit tree hinein gemirkt wurde es wird also bereits schön

45:26.440 --> 45:29.880
druck gemacht ja ich würde sagen das ist so von den

45:29.880 --> 45:37.120
sachen die jetzt in der tech preview 161 so drin ist so die interessanteste

45:37.120 --> 45:47.600
neuerung es gibt so stroke dash array und und marker zeugs und font krempel aber

45:47.600 --> 45:54.200
die sind alle so sind okay aber fetzen jetzt nicht so betreffen mich jetzt auch

45:54.200 --> 45:57.760
nicht besonders also ich würde vielleicht noch erwähnen so aus dem

45:57.760 --> 46:02.000
davaskript umfeld ist halt look behind the surgeons in regulären ausdrücken

46:02.000 --> 46:08.160
nicht verkehrt man es braucht wenn man es haben und jetzt so mein persönliches

46:08.160 --> 46:13.680
mein persönliches today i learned wars der resizable array buffer den gibt es

46:13.680 --> 46:20.640
zwar noch nicht aber der ist tatsächlich schon stage 3 bei tc 39 das ist

46:20.640 --> 46:22.920
schon mal nicht schlecht also manchmal sich manuell irgendwie so einen

46:22.920 --> 46:26.120
resizable array buffer kann man sich ja nicht bauen man muss ja im prinzip dann

46:26.120 --> 46:29.760
einen neuen array buffer bauen mit einer neuen größe und dem alten inhalt oder

46:29.760 --> 46:34.560
irgendwie so krams extrem mühsam und sowas in resizable zu haben ist schon

46:34.560 --> 46:38.240
nicht schlecht ja wie gesagt ist noch kein fertiger standard und kann noch fast

46:38.240 --> 46:41.560
keiner aber zumindest haben wir auch jetzt endlich mal eine implementierung die

46:41.560 --> 46:46.600
das supportet finde ich gut das ist mal das das ist auch was dass ich

46:46.600 --> 46:53.360
wahrscheinlich weiß gar nicht wann ich sie brauchen werde jemals aber das ist

46:53.360 --> 46:59.560
dann was ist das von ja genau ja also ich hatte das halt eben im Einsatz als ich

46:59.560 --> 47:07.080
mal gif animation bauen wollte und muss man ja also man hat irgendwie dann so

47:07.080 --> 47:10.560
eine pixel daten irgendwie rgb-werte und man muss dann ja am ende eine palette

47:10.560 --> 47:16.880
raus machen man muss das ja irgendwie auf die 256 farben runter kochen und was

47:16.880 --> 47:19.440
machst du wenn du halt eben einfach nur das schnell und dreckig hin bauen willst

47:19.440 --> 47:22.360
dann nimmst du halt eben deine gesamten frames die du in dieses gif in

47:22.360 --> 47:27.520
nine füttern wirst also all diese ganzen rgb pixel arrays und konkartinierst

47:27.520 --> 47:30.280
sie einfach in einen riesigen area buffer und schiebst den dann in den

47:30.280 --> 47:33.160
entsprechenden prozess und plus den in ein webwalker und dann braucht das zwar

47:33.160 --> 47:37.080
eine sekunde aber das macht ja nichts das sieht ja nicht so oft aber dann halt

47:37.080 --> 47:40.240
eben so eine funktion zu bauen die halt wirklich area buffer konkarteniert ist

47:40.240 --> 47:42.920
erstaunlicherweise nicht ganz so trivial weil man kriegt ja normalerweise auch

47:42.920 --> 47:45.440
keine area buffer angereicht sondern halt irgendwie so diese ganzen komischen

47:45.440 --> 47:50.440
subtypen irgendwie uint irgendwas array und dann muss man sich da halt eben

47:50.440 --> 47:53.760
einen ein zu recht abbrechen wenn man das halt irgendwie generalisiert haben

47:53.760 --> 47:57.360
möchte und stellt sich raus wird in zukunft nicht mehr ganz so schmerzhaft

47:57.360 --> 48:04.320
sein cool genau ansonsten hätte ich noch was ich hier weiter unten noch seh

48:04.320 --> 48:09.720
ist dass es die offscreen canvas jetzt gibt das finde ich glaube ich auch ganz

48:09.720 --> 48:17.640
gut weil klau die ist das am prinzip eine canvas die man im webwalker benutzen

48:17.640 --> 48:21.960
kann oder genau das ist es offscreen canvas also canvas element macht ja

48:21.960 --> 48:26.760
normalerweise pixel auf dem bildschirm außer wenn man das nicht haben will und

48:26.760 --> 48:30.000
also warum würde man das nicht haben wollen man würde das nicht haben wollen

48:30.000 --> 48:33.760
wenn man einfach nur pixel daten im sinn meiner gerade genannten rgb r arrays

48:33.760 --> 48:38.360
erzeugen möchte oder halt einfach auch nur irgendwelche dinge bauen möchte die

48:38.360 --> 48:41.800
überhaupt gar nichts mit rendering zu tun haben also ich will das bild invertieren

48:41.800 --> 48:45.320
und abspeichern aber ich will zu keinem zeitpunkt anzeigen dann gibt es ja

48:45.320 --> 48:48.280
kein gut die canvas anzuzeigen wenn es keinen grund sie gibt sie anzuzeigen

48:48.280 --> 48:51.560
dann kann man sie auch im webwalker haben außer halt eben kann man halt

48:51.560 --> 48:54.440
tatsächlich nicht weil der webwalker dann sagt nee könnt ihr angezeigt werden

48:54.440 --> 48:57.560
wollen und dann geht das bei mir nicht und die offscreen canvas macht es halt eben

48:57.560 --> 49:02.600
dann in einem nicht sichtbaren prozess möglich super sache ja auch so zum

49:02.600 --> 49:07.040
beispiel bild upload wo man dann noch auf dem gerät zum beispiel das bild

49:07.040 --> 49:10.920
quasi klein resize damit der upload eben einfach schneller geht

49:10.920 --> 49:15.400
genau mega pixel zahlen die man heutzutage so ein smartphones hat das

49:15.400 --> 49:22.040
kann man dann auch prima an ein webwalker wegdelegieren oder qr code

49:22.040 --> 49:28.040
auslesen oder dekodieren oder so zeugs ja wenn man übrigens möchte dass das

49:28.040 --> 49:31.720
einigermaßen flott geht heutzutage schon und man keine offscreen canvas hat und

49:31.720 --> 49:36.360
keinen dat worker haben möchte habe ich letztens folgendes rausgefunden das ist

49:36.360 --> 49:40.560
jetzt eine preview auf dem blog post nicht morgen veröffentliche aber es begab

49:40.560 --> 49:43.240
sich so zu der zeit dass ich so zu irgendwie so zu dem hinking und dachte

49:43.240 --> 49:45.520
so hey hast du gerade irgendwelche dringenden browser probleme ich habe

49:45.520 --> 49:49.320
gerade nichts dringendes zu tun und er so ja irgendwie auf meinen neuen laptops in

49:49.320 --> 49:54.720
der firma da werden manche von unseren pdf nicht richtig angezeigt aber nur wenn

49:54.720 --> 49:59.360
die hartweilbeschleunigung an ist so richtig schöner fall von montas geht

49:59.360 --> 50:04.880
der drucker nicht stellt sich also raus liegt halt eben an einem rendering bug in

50:04.880 --> 50:09.000
der engine von chrome beziehungsweise in deren fall in der großen firma war das

50:09.000 --> 50:13.280
etch und der sorgt halt eben dafür dass wenn dann in den pdfs bestimmte font

50:13.280 --> 50:16.040
metriken nicht oder nicht hin richtig hinterlegt sind oder da irgendwelche

50:16.040 --> 50:19.760
rundungsfehler auftauchen bei bestimmten grafiktreibern ist dann dazu führt dass

50:19.760 --> 50:22.480
irgendwie pixel fehlen die buchstaben ineinander laufen und generell alles

50:22.480 --> 50:26.080
aussieht als wäre es schon mal gegessen und die richtige lösung wäre halt eben

50:26.080 --> 50:29.040
gewesen updater halt alle eine pdf in deiner firma ja wird halt nicht

50:29.040 --> 50:32.920
passieren oder halt eben schalte auf allen geräten die hartweilbeschleunigung

50:32.920 --> 50:36.200
aus fast natürlich jetzt so aus der perspektive von meiner kleinen

50:36.200 --> 50:38.960
unterabteilung einer unterabteilung einer webentwicklungsabteilung in einem

50:38.960 --> 50:43.720
riesigen konzern leichter gesagt ist als zu tun also da irgendwie zu den admins

50:43.720 --> 50:46.600
hinzugehen und zu sagen machen wir hier für alle devices diese entsprechende

50:46.600 --> 50:51.160
admin richtlinie da in windows an ist halt zumindest keine dauerlösung weil man

50:51.160 --> 50:55.520
denen halt auch nicht weiter trauen kann als man sie werfen kann und da stellt sich

50:55.520 --> 50:59.200
halt raus hartweilbeschleunigung kann man tatsächlich auf der pro kenvis

50:59.200 --> 51:03.160
eben abschalten und das würde man machen wollen wenn man genauso kram machen

51:03.160 --> 51:05.640
möchte wie das was du gerade beschrieben hast chap weil normalerweise

51:05.640 --> 51:10.000
hartweilbeschleunigung ja gut ist für schnellsachen rendern aber dazu musst du

51:10.000 --> 51:14.360
sie erst mal zu deiner gpu rüber schicken und wenn du viel so tinge machst wie ich

51:14.360 --> 51:18.400
will eigentlich nur irgendwie ein qr code mir auslesen oder irgendwie ein

51:18.400 --> 51:22.480
build resize oder so wenn ich also niemals was anzeigen möchte ist das ja

51:22.480 --> 51:25.640
nicht nötig dann kann ich ja auf der cpu bleiben aber dazu muss ich ja mein

51:25.640 --> 51:29.320
kenvis element sagen können du brauchst nicht hartweilbeschleunigung zu werden

51:29.320 --> 51:33.520
und das geht tatsächlich über so ein flag wenn man sich ein 2d kontext holt

51:33.520 --> 51:38.440
der einfach heißt will read frequently weil man halt eben da sehr viele

51:38.440 --> 51:41.960
readback operationen im sinne von gib mir die pixel macht und dadurch erzwingt

51:41.960 --> 51:45.640
man im prinzip softwarebeschleunigung wodurch dann so use cases wie von dir

51:45.640 --> 51:49.160
gerade beschrieben schneller werden oder jetzt in meinem fall für die leute mit

51:49.160 --> 51:52.760
dem kaputten laptop ich einfach sagen konnte bau diese drei zahlen javascript

51:52.760 --> 51:57.280
ein die patchen kenvis 2d kontext prototype blablabla die machen halt die

51:57.280 --> 52:01.440
get-context-methode so dass die immer will read frequently auf schuhe hat okay

52:01.440 --> 52:04.880
die erst werden dann korrekt wenn auch langsamer gerendert und zeigt war das

52:04.880 --> 52:10.600
problem gegessen ja cool also das ist sehr cool vor allen Dingen steht in den

52:10.600 --> 52:16.320
spezifikationen drin so dieser fleck sagt im browser dass er optimieren soll

52:16.320 --> 52:21.280
dahingehend das oft readback stattfinden da steht nicht drin dass das die

52:21.280 --> 52:25.720
hardwarebeschleunigung ausmacht das würde ja das wäre jetzt ja auch nicht speck

52:25.720 --> 52:32.440
konform die wollen ja immer sozusagen so wenig implementations details eigentlich

52:32.440 --> 52:37.840
liefern wie möglich nur so viel wie nötig genau aber es kreuzt runter kommt

52:37.840 --> 52:41.160
direkt nach dem diesen nach diesem satz wohl halt drin steht blablabla optimiert

52:41.160 --> 52:44.160
für readback operation kommt so ein nicht normativer einschub wo drin steht

52:44.160 --> 52:49.440
ganz im vertrauen in erster für das software rendering erzwingen und so

52:49.440 --> 52:52.440
weiß man dann und auch bei mdn steht so drin dass das dann funktioniert mehr

52:52.440 --> 52:55.520
mehr details haben möchte schaut in mein block da steht das in länger mal

52:55.520 --> 53:00.760
breiter mit code noch mal drin ja cool das merke ich mir auch mal das werde

53:00.760 --> 53:04.200
ich bestimmt mal brauchen das ist super und vor allen

53:04.200 --> 53:07.680
chromen meckert halt auch also wenn du eine normale canvas hast wo du das nicht

53:07.680 --> 53:11.880
aktivierst und du machst irgendwie dreimal nacheinander irgendwie get image data

53:11.880 --> 53:14.760
dann kriegst du doch tatsächlich so eine warning die da sagt sagen wir willst

53:14.760 --> 53:19.680
eventuell diese option anmachen okay ja so eine art warning wie du sie oder

53:19.680 --> 53:25.320
hinweis wie man es also so eine hatte ich eben auch im sinn als ich meinte der

53:25.320 --> 53:30.360
firefox sagt sowas bringt sowas auf der konsole wenn man da irgendwie falsches

53:30.360 --> 53:37.080
css anwendet genau oder halt oder hier so eine passive events bei scroll und

53:37.080 --> 53:45.880
zu zeug ja sowas ist doch cool ja mega total genau ich glaube damit sind wir

53:45.880 --> 53:53.760
aber mit dem tag preview 161 durch aber wenn man auch den 162er das sind

53:53.760 --> 53:57.400
auch noch ein paar gute sachen dann soll man sie noch schnell schnappen das

53:57.400 --> 53:59.800
machen wir ich habe da auch ein paar weniger notizen drin als ich jetzt für

53:59.800 --> 54:06.400
den 161er hatte genau also was ich da gelernt habe ist dass es eine margin

54:06.400 --> 54:10.920
trim css eigenschaft gibt und ich noch nicht gehört habe die ich natürlich

54:10.920 --> 54:17.160
dann mal nach gucken musste genau ich hatte eigentlich gedacht so dass es

54:17.160 --> 54:23.040
dafür da ist es so quasi so so margins die aus elementen herausragen dann

54:23.040 --> 54:28.920
quasi abschneiden kannst zumindest lang margin trim so aber das dem dem ist

54:28.920 --> 54:37.200
nicht so es ist eher zu verstehen wie bei dem wie bei javascript string trim also

54:37.200 --> 54:47.320
das wenn du zum beispiel in einem container in line elemente hast und um und

54:47.320 --> 54:51.000
du abstand zwischen denen haben möchtest also in line block elemente zum

54:51.000 --> 54:58.920
beispiel und würdest jedem einen margin write geben dann kann es ja sein dass eins

54:58.920 --> 55:05.440
von denen ganz am ende der zeit landet mit dem margin den du da vielleicht gar

55:05.440 --> 55:11.280
nicht haben willst genau und du kannst dann diese also an den

55:11.280 --> 55:16.000
kannten kannst du dieses margin dann abschneiden so dass das eigentlich nur

55:16.000 --> 55:23.200
zwischen den elementen gilt aber eben nicht zum rand des der box also ist ein

55:23.200 --> 55:33.760
margin außer an den margins ja schon genau das ist ja net okay okay dann

55:33.760 --> 55:40.600
hat er das deswegen auch nicht genau man sagt damit wo dieses wo der margin

55:40.600 --> 55:46.600
weggetrimpt werden soll so rum funktioniert das genau ah okay ich war

55:46.600 --> 55:50.520
gerade erst wieder so im im im Sinne von eine alternative margin angabe man

55:50.520 --> 55:53.560
macht eine normale margin angabe und sagt dann wo der margin weggetrimpt

55:53.560 --> 55:59.240
werden soll also irgendwie in line start in line end so zu euch

56:00.600 --> 56:06.240
genauso ja genau also du sagst in line an in line start soll das weggetrimpt

56:06.240 --> 56:11.280
werden oder in line end und in block richtung geht das geht das genauso

56:11.280 --> 56:18.320
ja genau ist halt eine kleinigkeit aber auch wieder so ein so ein ein kleiner

56:18.320 --> 56:23.800
baustein mehr der einem irgendwann mal irgendwie nützlich sein kann finde ich ja

56:23.800 --> 56:27.520
auf jeden fall weil ich meine ansonsten musst du halt eben also die alternative

56:27.520 --> 56:31.080
ist halt eine sehr viel komplizierter irgendwie dir mit last child ein

56:31.080 --> 56:36.680
abbrechen was halt ja aber selbst selbst das ist ja nicht immer möglich weil wenn

56:36.680 --> 56:43.880
wenn du dann wenn das dann umricht in eine neue zeile vielleicht ja stimmt

56:43.880 --> 56:47.400
das ist auch nicht dann funktioniert das ja schon nicht mehr genau das würde

56:47.400 --> 56:50.920
halt bei blocks funktionieren aber nicht irgendwie bei in line oder generell

56:50.920 --> 56:56.240
du hast ja auch so Sachen wie grid oder flexbox wo das ja sowieso alles schwierig

56:56.240 --> 57:07.720
wird ja was ich übrigens du finde ist an grid ist dass man nicht sagen kann ich

57:07.720 --> 57:14.240
möchte quasi viel mit das in ein grid aber wenn es aber maximal zwei rein und

57:14.240 --> 57:21.800
alles was mehr ist bitte einfach quasi verschlucken ja also da gibt es so

57:21.800 --> 57:29.160
tricks wie man das machen kann da kannst du quasi ich überlege gerade wie das war

57:29.160 --> 57:36.440
also du kannst es schon irgendwie tricksen aber du darfst dann kein gap benutzen

57:36.440 --> 57:44.160
weil dann sind zwar die elemente nicht mehr da die in zeile 3 4 5 und so weiter

57:44.160 --> 57:51.400
noch automatisch einsortiert werden aber die gaps dazwischen die bleiben okay das

57:51.400 --> 57:55.760
ist halt weil was würdest du machen du würdest dann diese grid zählen oder die

57:55.760 --> 57:59.880
tracks irgendwo wie so eine antike text replacement technik irgendwo in den

57:59.880 --> 58:07.160
orkos schieben ja sich also stell dir mal vor du hast irgendwie so eine bilder

58:07.160 --> 58:16.600
galerie und du du möchtest irgendwie vielleicht du willst nur x zeilen davon

58:16.600 --> 58:22.560
haben und wenn es dann noch mehr bilder sind dann möchtest du einfach also dann

58:22.560 --> 58:27.160
dann möchtest nicht in deinem html lösen indem du da quasi weil du weißt ja

58:27.160 --> 58:32.440
auch bei responsive gar nicht so wie viele mente sind das denn jetzt in dem

58:32.440 --> 58:37.440
viewport die drei zeilen ergeben also bei großen viewports kann es halt mehr

58:37.440 --> 58:43.840
reinstecken beim geräten vielleicht weniger und deswegen das das html kann

58:43.840 --> 58:48.280
jetzt irgendwie das nicht entscheiden das heißt da sind vielleicht dann 20

58:48.280 --> 58:54.040
30 bilder drin und du willst eben unabhängig aber du willst quasi auf

58:54.040 --> 58:59.760
jedem gerät drei zeilen anzeigen in der dann aber eben bei einem gerät beim

58:59.760 --> 59:06.000
desktop zehn spalten sind und bei mobile vielleicht nur drei oder sowas und da

59:06.000 --> 59:12.360
gibt es eben eigentlich nichts was grid vorsieht und um das auszudrücken

59:12.360 --> 59:20.240
stimmt bis wir nur so am rand eingefallen ja aber ich mache jetzt

59:20.240 --> 59:23.160
ja nicht den ganzen tag css aber mein eindruck von grid ist ja schon so dass

59:23.160 --> 59:28.880
das sehr für einen sagen wir aufgeräumtes geplantes layouten gedacht ist und so

59:28.880 --> 59:32.760
bald man funky werden möchte wird es halt relativ schnell relativ schwierig ja

59:32.760 --> 59:37.800
also vielleicht kommt ja auch jetzt was also grid version 2 ist ja in der mache

59:37.800 --> 59:42.840
wo auch subgrid drin steckt und so ich weiß nicht ob dann dann irgendwie noch

59:42.840 --> 59:49.160
neues kommt was das angeht ist es war nur so was was ich letztens als problem

59:49.160 --> 59:55.160
sozusagen auf dem tisch hatte und dass ich dann wo ich noch ein bisschen

59:55.160 --> 59:59.160
rumknobeln musste bis ich das gelöst hatte

01:00:00.440 --> 01:00:04.320
genau wer wissen will wie ich das gelöst habe bitte einfach mich anschreiben

01:00:04.320 --> 01:00:09.040
ich muss dann noch mal selber nachgucken und sagst euch wie kann keine

01:00:09.040 --> 01:00:15.560
artikelveröffentlichung ja ja ja ist recht müsst ihr machen genau müsstest

01:00:15.560 --> 01:00:20.200
ich verspreche es hier mit fein

01:00:21.480 --> 01:00:25.440
genau was ich auch ziemlich cool finde weil ich damit auch schon im aktuellen

01:00:25.440 --> 01:00:32.280
projekt rum gespielt habe ist die klarative shadow dom das ist im

01:00:32.280 --> 01:00:36.160
prinzip auch das ist so ein bisschen so wie diese ad property über die wir am

01:00:36.160 --> 01:00:42.720
anfang gesprochen hatten die erste inkarnation von der war also als

01:00:42.720 --> 01:00:48.360
javascript api und man konnte also die erste deklaration die erste inkarnation

01:00:48.360 --> 01:00:52.560
von shadow dom spezifisch nicht dass das die klarative ist die version 2 0

01:00:52.560 --> 01:00:57.280
genau und das war aber ad property auch das also am anfang konnte man das nur

01:00:57.280 --> 01:01:04.360
mit css.property machen und dann haben die leute gesagt so ja aber warum

01:01:04.360 --> 01:01:07.840
kann man das eigentlich nicht direkt in css machen das wäre doch irgendwie ein

01:01:07.840 --> 01:01:13.840
bisschen schlauer weil oder cooler weil das sehr e4 css also es ist ja css und

01:01:13.840 --> 01:01:20.080
dann ist ja quasi nachträglich diese ad property rule entstanden das also aus dem

01:01:20.080 --> 01:01:24.400
grund und bei diesem deklarative shadow dom ist das eigentlich auch wieder das

01:01:24.400 --> 01:01:29.520
gleiche also shadow dom gibt es ja schon eine ganze weile aber man konnte quasi

01:01:29.520 --> 01:01:37.560
nicht per html das auszeichnen also man musste immer javascript anwerfen dafür

01:01:37.560 --> 01:01:47.800
und irgendwie also fand ich das unnötig also so quasi diesen weg gar nicht zu

01:01:47.800 --> 01:01:56.200
haben und ich finde das ganz gut weil man damit also zum einen so ein graceful

01:01:56.200 --> 01:02:01.600
degradation in alten browser natürlich einerseits hin kriegen kann genau und

01:02:01.600 --> 01:02:06.760
zum anderen ist es eben dann auch suchmaschinen freundlicheres shadow dom

01:02:06.760 --> 01:02:12.680
als wenn du das eben alles nur in javascript rein drückst ist das der

01:02:12.680 --> 01:02:16.680
fall du meinst wegen dem template element oder was genau es ist ja im

01:02:16.680 --> 01:02:20.840
template und im template der content ist ja nicht in nörd aber der wird ja im

01:02:20.840 --> 01:02:26.960
prinzip letztlich nur als input genommen um das fragment zu erzeugen dass da am

01:02:26.960 --> 01:02:32.320
ende repräsentiert wird oder genau

01:02:32.720 --> 01:02:36.840
ja du kannst auch es wird auch einfach natürlich schneller erzeugt wenn du nicht

01:02:36.840 --> 01:02:44.120
erst javascript dafür hochfahren musst ja genau und ich spiele so ein bisschen mit

01:02:44.120 --> 01:02:51.960
mit shadow dom rum um so quasi auf der dem projekt wo ich bin so so

01:02:51.960 --> 01:02:58.280
compartments zu machen innerhalb der seite in denen zum beispiel eben das

01:02:58.280 --> 01:03:03.280
selektor matching einfach schneller abläuft weil das stylesheet dann

01:03:03.280 --> 01:03:08.240
innerhalb des shadow doms eben nur versucht die elemente die da drin sind

01:03:08.240 --> 01:03:14.720
zu matchen und eben nicht den kompletten dom also ein bisschen wie diese diese

01:03:14.720 --> 01:03:18.480
compartments in der titanik die sie eingebaut haben damit die nicht sinkt

01:03:18.480 --> 01:03:22.680
auch das vergleicht mit deinem projekt

01:03:22.680 --> 01:03:33.480
genau ja also nötig würde ich halt eben auch sagen so das braucht man dieses

01:03:33.480 --> 01:03:41.800
declarative shadow dom ich frau mich halt eben ob das reicht weil das bewegt

01:03:41.800 --> 01:03:47.920
sich jetzt ja zunehmend daran irgendwie ein templating mechanismus herzustellen

01:03:47.920 --> 01:03:51.880
also machen wir ja quasi schon es ist ja es kommt ja in buchstäblich ins

01:03:51.880 --> 01:03:54.960
template element rein und das ist eine vorlage dann hat man da so sein dom

01:03:54.960 --> 01:03:58.400
drin und dann kann man das ja mit konkretem inhalt befüllen aber klont

01:03:58.400 --> 01:04:02.040
halt die dom struktur irgendwo rein hat dann halt irgendwie seine web component

01:04:02.040 --> 01:04:05.640
oder dein compartment das macht ja alles Sinn aber ich frage mich jetzt halt

01:04:05.640 --> 01:04:10.280
wirklich wie lange kann man sich noch dem ganzen sagen mal drive dahingehend

01:04:10.280 --> 01:04:13.720
erwähren dass das irgendwann tatsächlich templates werden mit

01:04:13.720 --> 01:04:18.960
halt entsprechenden so möglichkeiten da content rein zu interpolieren oder halt

01:04:18.960 --> 01:04:23.040
eben in html irgendwelche platzhalter zu definieren dass ich da so handelbars

01:04:23.040 --> 01:04:26.240
artige sündags drin habe oder wenn man irgendwie retro drauf sein möchte

01:04:26.240 --> 01:04:32.800
irgendwie so spitzklammer fragezeichen perp echo irgendwas apple dann nicht auch

01:04:32.800 --> 01:04:37.360
schon mal was vorgeschlagen vor ewigen zeiten da gab es mehrere sachen da

01:04:37.360 --> 01:04:43.760
gab es ja dieses wie hieß das e4x also so dieses xml in javascript extension und

01:04:43.760 --> 01:04:47.920
es gibt ja tatsächlich so proposals wie man so eine j sx artige sündags die ja

01:04:47.920 --> 01:04:51.600
extrem react spezifisch ist aber so bendigen und generalisieren kann um so

01:04:51.600 --> 01:04:56.200
generell baumestrukturen auszudrücken und dann wäre das da ja drin

01:04:56.200 --> 01:04:59.240
weiß jetzt nicht ob das irgendwie so der weißheit letzter schluss ist

01:04:59.240 --> 01:05:03.240
notwendigerweise aber ich finde das ist halt irgendwie so eine geschichte

01:05:03.240 --> 01:05:07.680
früher oder später landen wir da dass da herrscht eigentlich in meinem kopf kein

01:05:07.680 --> 01:05:10.960
zweifel dass das irgendwie gehen muss weil du hast recht so der klare schiff

01:05:10.960 --> 01:05:13.800
shadow dom ist besser als das normale shadow dom weil du halt eben nicht den

01:05:13.800 --> 01:05:18.000
kompletten dom tree neu erzeugen musst und das ist ein bisschen ein bisschen

01:05:18.000 --> 01:05:21.680
convenience bonus und hatten je nach use case in deinem fall jetzt ein

01:05:21.680 --> 01:05:26.240
performance bonus auch noch aber am ende musst du dann wenn du das gemacht hast

01:05:26.240 --> 01:05:29.640
immer noch dom manipulation machen du musst dann dein shadow tree nehmen und

01:05:29.640 --> 01:05:33.480
dir da drin dann mit klare selektor oder sonst irgendwas rauspicken wo das

01:05:33.480 --> 01:05:37.720
element ist wo du den eigentlichen content reinschreiben willst

01:05:39.200 --> 01:05:43.640
ist das so also ich muss ich irgendwie text reinkriegen du hast ja deinen shadow

01:05:43.640 --> 01:05:48.240
dom in einem template also du meinst dann wenn du quasi so dynamisch renders

01:05:48.240 --> 01:05:54.120
noch ja also meine web und sicherlich ein eins und use case dafür ich meine wenn

01:05:54.120 --> 01:05:57.720
du das jetzt einfach nur zum für dieses compartment leising her nimmst ist das

01:05:57.720 --> 01:06:03.400
ja ein sehr allgemeiner ich machen genau mir ich nutze ja wirklich nur dieses

01:06:03.400 --> 01:06:09.560
diese kommt dieser grenzungsmechanik oder dieses diese silo mechanik die halt mit

01:06:09.560 --> 01:06:13.120
dem shadow dom daher kommt und was anderes will ich gar nicht nur deswegen

01:06:13.120 --> 01:06:17.320
tue ich das genau aber ich würde halt mal behaupten die meisten werden das

01:06:17.320 --> 01:06:22.720
verwenden wollen im kontext von webkomponent oder ähnlichem ja und

01:06:22.720 --> 01:06:25.960
dann stehst du halt wieder da und musst irgendwie so sagen ja hier webkomponent

01:06:25.960 --> 01:06:29.280
ist irgendwie plattform und native und alles irgendwie ganz toll aber du musst

01:06:29.280 --> 01:06:33.360
halt irgendwie die zeichen kette query selektor schreiben bevor du irgendwo text

01:06:33.360 --> 01:06:38.960
rein bauen kannst ist ja eigentlich nicht wirklich gut genug

01:06:38.960 --> 01:06:41.400
eigentlich nicht

01:06:41.400 --> 01:06:47.080
ich guck mal gerade da war was wir haben damit darüber damals auch mal gesprochen

01:06:47.080 --> 01:06:53.000
über diesen apple vorschlag ja ich gucke noch mal ob ich das vielleicht

01:06:53.000 --> 01:06:58.600
irgendwie noch finden kann und dann kann man das auch noch mal verlinken ja

01:06:58.600 --> 01:07:02.040
hast recht also irgendwas muss da irgendwann mal her ich glaube das ist ja

01:07:02.040 --> 01:07:08.180
auch einer der gründe warum warum leute auch mit einfach mit webkomponent

01:07:08.180 --> 01:07:15.640
schmerzen haben oder viele viele viele also das ist halt wirklich einfach das

01:07:15.640 --> 01:07:18.920
ist das gleiche probleme mit hudini du hast die high level api die ist

01:07:18.920 --> 01:07:21.240
etabliert und die kann sich nicht mehr ändern und muss jetzt nachgelagert die

01:07:21.240 --> 01:07:25.960
low level api bauen die das erklärt notwendigerweise unglaublich schwierig

01:07:25.960 --> 01:07:29.880
und vor allen Dingen fehlen die halt überall die werkzeuge also normales

01:07:29.880 --> 01:07:32.960
shadow dom und dann hast du die klerative shadow dom das macht sicherlich besser

01:07:32.960 --> 01:07:36.360
aber das ist sicherlich kein quanten sprung würde ich behaupten dann hast

01:07:36.360 --> 01:07:39.880
du da draußen die ganzen verrückten die typescript verwenden wollen und müssen

01:07:39.880 --> 01:07:42.520
dann halt irgendwie mit html interagieren html ist halt einfach nur eine

01:07:42.520 --> 01:07:46.520
welt aus schmerzen bzw strings da können die halt mit ihrem typescript nichts

01:07:46.520 --> 01:07:50.680
mit anfangen das ist komplett wertlos dann und dann ist das halt eben auch die

01:07:50.680 --> 01:07:53.160
frage okay du könntest stattdessen irgendwie angular oder react komponenten

01:07:53.160 --> 01:07:57.360
bauen bis damit zügiger unterwegs ja hast irgendwelche dependencies ja muss

01:07:57.360 --> 01:08:00.560
da und updaten und in 20 jahren weiß keiner mehr was da vor und hinten ist

01:08:00.560 --> 01:08:05.480
aber das interessiert dich halt jetzt gerade nicht und generell auch so die

01:08:05.480 --> 01:08:08.600
ganze api interwebkomponent ist halt so unglaublich kompliziert und so

01:08:08.600 --> 01:08:13.760
einschränkend da würde ich halt jetzt behaupten dass die das neue decorators

01:08:13.760 --> 01:08:18.280
proposal in eckmascript einiges richten wird aber das wird halt nie so gut

01:08:18.280 --> 01:08:21.800
sein wie das halt irgendwie in so einem framework context ist notwendigerweise

01:08:21.800 --> 01:08:26.280
das kann gar nicht sein aber wenn man halt zumindest mal einsehen würde dass

01:08:26.280 --> 01:08:29.300
man halt irgendwie hinter der anderdoc ist und man halt wirklich mal jetzt hier

01:08:29.300 --> 01:08:33.560
was verrücktes anstellen muss dann würde man da glaube ich irgendwie noch

01:08:33.560 --> 01:08:37.200
weiter vorankommen und irgendwie was verwenden was halt nicht nur shadow tom

01:08:37.200 --> 01:08:41.480
also die erste idee so von damals ist nur halt eben jetzt in deklarativ statt

01:08:41.480 --> 01:08:45.320
imperativ sondern wirklich auch sagt da machen wir eine voll eine volle template

01:08:45.320 --> 01:08:48.680
sprache daraus auf die ein oder andere weise adaptiert von mir aus jsx und

01:08:48.680 --> 01:08:51.720
reaktifiziert das ein bisschen macht es halt irgendwas dass man sich halt nicht

01:08:51.720 --> 01:08:55.080
wie das letzte follow-upst vorkommt wenn man versucht irgendwie zu sagen

01:08:55.080 --> 01:08:59.360
webkomponents existieren auch ja es ist alles mühsam und inconsistenz und

01:08:59.360 --> 01:09:02.560
schmerzhaft aber dafür müsste halt eben in drei jahren kein update durchführen

01:09:02.560 --> 01:09:07.560
es ist halt eine echte schlechte perspektive

01:09:08.280 --> 01:09:15.000
ja aber auch irgendwie was an das sich keiner so richtig handraut

01:09:15.000 --> 01:09:18.760
was kann ich verstehen ich will die einscheinungen auch nicht treffen weil

01:09:18.760 --> 01:09:21.960
sitzen am ende wieder dann irgendwie zwei nasen in einem podcast in zwei jahren

01:09:21.960 --> 01:09:25.560
und sagen so guckt ihr mal das an was haben wir uns damals bei damals nur

01:09:25.560 --> 01:09:29.520
gedacht ist natürlich alles sehr viel leichter gesagt als getan aber wie es

01:09:29.520 --> 01:09:32.840
jetzt gibt ja mittlerweile würde ich behaupten genug prior art die man

01:09:32.840 --> 01:09:37.200
hernehmen könnte als guidelines es muss ja nicht jsx sein es könnte ja einfach

01:09:37.200 --> 01:09:41.880
irgendwie so eine art von weiß ihr nicht bild in tag template literal ding sie

01:09:41.880 --> 01:09:45.560
irgendwas sein vielleicht kann man irgendein mechanismus daraus hijacken

01:09:45.560 --> 01:09:50.160
oder oder oder gibt so viele template sprachen da draußen

01:09:50.160 --> 01:09:54.200
vielleicht gehen das beste clown macht man doch bei eckmas kript ständig

01:09:54.200 --> 01:10:01.480
ja ja mal sehen wann wir wann wir endlich darüber reden können wenn das dann

01:10:01.480 --> 01:10:06.280
wenn sowas dann spezifiziert und vielleicht in den ersten browsern gelandet

01:10:06.280 --> 01:10:11.800
ist ja ich bin auf jeden fall gespannt weil bis dahin werden wir weiter irgendwelche

01:10:11.800 --> 01:10:14.040
frameworks haben wo man das halt irgendwie implementiert also man kann den

01:10:14.040 --> 01:10:17.240
Leuten das nicht vorenthalten wenn man sie nicht gibt dann machen sie selber und

01:10:17.240 --> 01:10:23.560
dann wird es halt wahrscheinlich halb gar und schmerzhaft ja generell ist jetzt

01:10:23.560 --> 01:10:28.200
in dieser in der technologie preview 162 nicht ganz so viel kram drin aber

01:10:28.200 --> 01:10:32.760
vielleicht kannst du mir noch mal ein bisschen erzählen es gibt hier die

01:10:32.760 --> 01:10:40.720
form associated custom elements die genau magst du da noch mal was zu erzählen

01:10:40.720 --> 01:10:46.680
ja also idee ist bausten custom element und würde es zum beispiel sowas machen

01:10:46.680 --> 01:10:51.080
wollen wie einen keine ahnung lange mal ein custom color picker mit einem alpha

01:10:51.080 --> 01:10:55.000
kanal der normale hat keinen alpha kanal aber du willst halt irgendwie die

01:10:55.000 --> 01:10:59.440
möglichkeit bieten dass man rgb angibt und halt auch noch und du willst keinen

01:10:59.440 --> 01:11:02.480
fancy design machen du willst das nur irgendwie möglich machen in irgendeiner

01:11:02.480 --> 01:11:06.240
form die einfachste variante das in einem kasten element umzusetzen wäre ja du

01:11:06.240 --> 01:11:09.800
nimmst ein color input und du nimmst ein number input und du packst sie zusammen

01:11:09.800 --> 01:11:14.720
in einen custom element und dann kannst du ein bisschen javascript schreiben das

01:11:14.720 --> 01:11:18.200
im prinzip sagt irgendwie uns hat mit oder so jetzt ganz vereinfacht ausgedrückt

01:11:18.200 --> 01:11:22.440
geht halt eben hin und pickt sich halt den rgb wert aus dem color input den

01:11:22.440 --> 01:11:25.360
alpha wert aus number input und flanscht die zusammen macht da zum beispiel

01:11:25.360 --> 01:11:30.800
eine keine ahnung rgba hex notations geschichte daraus könnte man sich

01:11:30.800 --> 01:11:34.560
konzeptionell vorstellen das problem ist nur dass das resultierende element

01:11:34.560 --> 01:11:39.600
dass du dann baust nicht abwerk ein formular element ist auch wenn du es

01:11:39.600 --> 01:11:42.840
irgendwie in formular reinsteckst und du implementierst darauf so dinge wie ein

01:11:42.840 --> 01:11:47.540
value getter und ein name attribute und all so Sachen macht das das ganze nicht

01:11:47.540 --> 01:11:51.800
automatisch zu einem form associated custom element das heißt man die das

01:11:51.800 --> 01:11:57.800
formula absenden würde dann würde das würde der browser das input element

01:11:57.800 --> 01:12:02.640
das im custom element drin steckt nicht quasi zusammen mit dem anderen kram

01:12:02.640 --> 01:12:05.920
verschicken korrekt genau würde nicht verschickt werden ist nicht

01:12:05.920 --> 01:12:09.600
Gegenstand von der constraint validation ist halt im prinzip als würdest du ein

01:12:09.600 --> 01:12:14.480
diff in dein formula reinstecken weil das im prinzip das ist was du tun würdest und

01:12:14.480 --> 01:12:18.960
warum ist es so also das intuitiv kommt einem das ja irgendwie merkwürdig vor

01:12:18.960 --> 01:12:23.840
weil man hat ein input also wenn man jetzt dedizierten input da reinstecken würde

01:12:23.840 --> 01:12:29.320
aber hast du nicht denn du hast ja das ganze im shadow dom wenn nun custom

01:12:29.320 --> 01:12:33.760
element baust und im shadow dom wohnen ja die implementierungs details ja

01:12:33.760 --> 01:12:38.920
nicht gegenstand der öffentlichen api sind also um das zu generalisieren ja du

01:12:38.920 --> 01:12:42.800
könntest quasi auch keinen auf dem document wenn du da query selektor all

01:12:42.800 --> 01:12:48.400
auf alle inputs machst dann würde es da ja auch nicht auftauchen genau also das

01:12:48.400 --> 01:12:51.280
ist jetzt sozusagen die beschreibung des phänomens du schiebst das in shadow

01:12:51.280 --> 01:12:55.120
dom dadurch ist ein implementierungs detaile dadurch kann halt eben der sozusagen

01:12:55.120 --> 01:12:58.800
das mit der main realm da nicht rankommen aber wenn du es ein bisschen

01:12:58.800 --> 01:13:02.680
generalisierst ist das eigentlich so du hast halt deine html apis mit den

01:13:02.680 --> 01:13:07.320
ganzen attributen und gettern und settern und das ist sozusagen die public

01:13:07.320 --> 01:13:11.360
api die eine html element so hat für dich als webentwickler und webentwickler

01:13:11.360 --> 01:13:15.600
drin ist also hin und benutzt das aber wenn du die spezifikationen anschaust

01:13:15.600 --> 01:13:21.480
gibt es ja noch eine gleichsam private api die solche elemente haben das sind

01:13:21.480 --> 01:13:24.360
dann halt eben so sachen die zum beispiel der formular validierungsmechanismus

01:13:24.360 --> 01:13:29.160
sind aber auch so dinge wie die voreingestellten area settings für

01:13:29.160 --> 01:13:34.000
barrierefreiheit und zeug das ist ja auch so zeug das ist definiert und da

01:13:34.000 --> 01:13:37.320
gibt es algorithmen für wenn dieser und jene umstand vorliegt dann wird das

01:13:37.320 --> 01:13:40.840
dieser roll kriegen ansonsten kriegt jene roll und so weiter das sind ja alles

01:13:40.840 --> 01:13:46.160
wohl definierte algorithmen nur die sind halt eben private oder die sind intern

01:13:46.160 --> 01:13:51.280
und was man jetzt kriegt sozusagen im rahmen von form associated custom

01:13:51.280 --> 01:13:55.600
elements oder sagen wir so form associated form associated custom elements sind

01:13:55.600 --> 01:13:59.160
eine ausprägung von dem ist auf webkomponents eine methode die nennt

01:13:59.160 --> 01:14:05.320
sich attach internals und die liefert dir eine public api für die private api von

01:14:05.320 --> 01:14:10.440
vielen dieser internen prozesse und diese internen prozesse sind so Dinge wie

01:14:10.440 --> 01:14:15.600
set form value das heißt was du dann machen kannst ist zu sagen okay ich

01:14:15.600 --> 01:14:18.600
habe jetzt ja mein custom element und das enthält halt eben in seinem

01:14:18.600 --> 01:14:23.840
shadowdom das color input und das number input für den alpha kanal ich mache

01:14:23.840 --> 01:14:26.800
da eventlistener drauf und wenn sich auf einen von den beiden elementen was

01:14:26.800 --> 01:14:31.920
ändert dann rufe ich die internals method set form value auf und rechne dann

01:14:31.920 --> 01:14:35.800
da aus was mein rgba wert ist schiebt ihn da rein und dadurch habe ich jetzt auf

01:14:35.800 --> 01:14:40.640
meinem element etwas dass diesen internen mechanismus vollzieht umgesetzt aus

01:14:40.640 --> 01:14:45.760
dieser attach internals mechanik heraus aus dem inneren auf vor der custom element

01:14:45.760 --> 01:14:49.360
klasse und dann gehe ich noch hin und definiere halt auf dem element so was

01:14:49.360 --> 01:14:54.160
wie ein muss ich in einem ein feld definieren ein static ich erinnere mich

01:14:54.160 --> 01:14:56.720
jetzt gerade nicht ich glaube ein static string der einfach form associated

01:14:56.720 --> 01:14:59.080
heißt oder irgendwie sowas oder ich muss das auf true setzen ich erinnere mich

01:14:59.080 --> 01:15:01.760
gerade nicht genau aber ich muss halt eben den browser sagen das ding ist form

01:15:01.760 --> 01:15:06.320
associated und dann weiß der browser ich muss das abschicken und abschicken

01:15:06.320 --> 01:15:10.880
heißt halt diese internen felder die gesetzt werden über diese internals

01:15:10.880 --> 01:15:15.200
auslesen und dann funktioniert die kiste also das ist immer noch riesiger

01:15:15.200 --> 01:15:19.200
auffand sowas zu bauen wie den gerade illustrierten color picker aber das geht

01:15:19.200 --> 01:15:22.640
und man kann halt wirklich auch so Sachen machen wie zu sagen okay wenn einer von

01:15:22.640 --> 01:15:26.600
den beiden dingern invalid ist entweder color oder alpha dann mache ich halt den

01:15:26.600 --> 01:15:30.560
validity wert von dem umgebenden halt eben auch auf ungültig und kann halt

01:15:30.560 --> 01:15:34.520
wirklich da das komplette behavior nach modelieren und habe ich jetzt so ein

01:15:34.520 --> 01:15:37.400
bisschen langwierig erzählt weil halt eben dieses attach internals viel mehr

01:15:37.400 --> 01:15:40.920
macht als nur das ist halt eine universelle api um diese implementierungs

01:15:40.920 --> 01:15:45.240
details für uns zugreifbar zu machen damit wir wirklich das machen können

01:15:45.240 --> 01:15:48.960
was ich den ganzen zeit schon sage nämlich die high level api aus der low level api

01:15:48.960 --> 01:15:54.400
obwohl die nachträglich dran geflanscht wurde komplett erklären ja cool das ist

01:15:54.400 --> 01:16:02.720
extrem cool ja ich baue tatsächlich wenig webkomponent deswegen bin ich

01:16:02.720 --> 01:16:09.040
da wahrscheinlich einfach noch nicht auf dieses problem gestoßen ja aber macht

01:16:09.040 --> 01:16:18.240
sinn und es ja dass es auch jetzt erst dazu kommt es ist dann schon fast

01:16:18.240 --> 01:16:22.520
erstaunlich ja weiß nicht ist halt unglaublich kompliziert so ein formular

01:16:22.520 --> 01:16:27.320
element also du hast die validierung set form value und du hast ja auch fragen um

01:16:27.320 --> 01:16:29.920
so Sachen wie fokussierbarkeit und so das muss ja alles irgendwie erst mal

01:16:29.920 --> 01:16:34.640
durchdachten und dass man irgendwie so für so ein mvp version 1.0 erst mal sagt

01:16:34.640 --> 01:16:42.280
okay diffs und so ja man merkt das ja auch wenn man so seine so abseits von

01:16:42.280 --> 01:16:48.480
webkomponent irgendwie seine eigenen formular eingabefelder baut oder wenn

01:16:48.480 --> 01:16:54.360
man irgendwie generell formular bauchesten baut die irgendwie funktionieren

01:16:54.360 --> 01:17:01.720
da da merkt man dann alles also was da alles noch drin steckt ja cool so ist es

01:17:01.720 --> 01:17:09.560
aber es ist keine lösung für das problem wenn ein wenn man ein label hat

01:17:09.560 --> 01:17:16.080
dass quasi wenn man eine webkomponent hat die label ist eine webkomponent die

01:17:16.080 --> 01:17:23.000
input ist dass die dann irgendwie die richtigen elemente nicht miteinander

01:17:23.000 --> 01:17:27.600
zeigen können oder nicht auch noch was das ist da auch noch so ein quasi deal

01:17:27.600 --> 01:17:33.240
breaker so ein bisschen bei webkomponent ich weiß nicht was du genau meinst aber

01:17:33.240 --> 01:17:36.600
das hört sich auf jeden fall so an aus der beschreibung heraus würde ich jetzt

01:17:36.600 --> 01:17:40.240
auch sagen ich nähere mich jetzt dem dem ausgang an damit ich mit dem problem

01:17:40.240 --> 01:17:43.480
mich nicht auseinandersetzen muss weil ich mir relativ sicher bin dass du

01:17:43.480 --> 01:17:47.440
recht hast ja ich glaube es im prinzip so wenn die beide in ihrem eigenen

01:17:47.440 --> 01:17:50.600
shadow DOM quasi gekapselt sind dann haben die eben nicht die

01:17:50.600 --> 01:17:55.200
möglichkeit über so eine id also mit vor und id irgendwie aufeinander zu zeigen

01:17:55.200 --> 01:18:00.360
und dann so aber gut aber das wäre ja auch falsch denn das shadow DOM ist ja

01:18:00.360 --> 01:18:04.040
ein implementierungsdetail da darf ja nichts rein da darf ja nichts raus

01:18:04.040 --> 01:18:08.800
korrekt also den scenario wäre du baust ein form associated custom element und

01:18:08.800 --> 01:18:12.840
du baust ein do it yourself shape label und du willst das shape label auf das

01:18:12.840 --> 01:18:16.480
form associated custom element zeigen lassen

01:18:16.480 --> 01:18:23.520
genau so glaube ich so ist das problem ja ja also dann weiß ich jetzt nicht ob

01:18:23.520 --> 01:18:27.280
das mit den attach internals also entweder jetzt geht ich würde wetten das

01:18:27.280 --> 01:18:31.200
nicht oder machbar ist weil ich habe jetzt die internen algorithmen für so ein

01:18:31.200 --> 01:18:37.920
label nicht im kopf genau das gleiche noch mal quasi nicht für input sondern

01:18:37.920 --> 01:18:43.600
für labels geben damit man diesen label custom element sozusagen die die

01:18:43.600 --> 01:18:47.560
notwendigen tricks beibringt dass sich das auch dann wie nach außen wie ein

01:18:47.560 --> 01:18:52.120
label verhält ja aber wie gesagt deswegen ist ja attach internals mehr als

01:18:52.120 --> 01:18:56.280
nur formulare also im prinzip wäre das denkbar jetzt mache ich hier gerade

01:18:56.280 --> 01:19:02.340
parallel die mdn seite zu attach internals auf bla bla bla accessibility

01:19:02.340 --> 01:19:05.800
object model und im hintergrund lädt die html spezifikation damit ich mal kurz

01:19:05.800 --> 01:19:11.360
gucken kann ob so ein label tatsächlich so ein also wenn das so eine element

01:19:11.360 --> 01:19:15.560
klasse ist so wie form associated dann wüsste ich halt nicht warum man das

01:19:15.560 --> 01:19:19.840
nicht machen müsste machen könnte also würde ich jetzt sagen ich hätte jetzt

01:19:19.840 --> 01:19:25.240
fast gesagt irgendwie ja mach eine type extension also class shape label extents

01:19:25.240 --> 01:19:28.480
html label element aber das wird ja auch nicht funktionieren weil dem kannst du

01:19:28.480 --> 01:19:31.280
dann ja wahrscheinlich wenn ich mich nicht täuschen nicht dein eigenes shadow

01:19:31.280 --> 01:19:34.800
dom überhelfen du müsstest also wirklich ein neues element erzeugen und das

01:19:34.800 --> 01:19:39.040
müsste halt eben wie ein label agieren

01:19:39.040 --> 01:19:48.720
ja alles sehr berechtigt die muss aber auch nicht jetzt aufklären können ich

01:19:48.720 --> 01:19:51.960
will es late halt nur nicht die spezifikation schon wieder was länger

01:19:51.960 --> 01:19:58.240
geworden ist last updated 28 der januar also vor zwei tagen

01:19:58.240 --> 01:20:00.960
also war da mal kurz das klären wir jetzt eben noch nicht und in der

01:20:00.960 --> 01:20:04.640
zwischenzeit kannst du ja mal deine interpretation das einen punkt ist noch

01:20:04.640 --> 01:20:07.000
der mich interessiert in der technologie preview noch eben kurz zum

01:20:07.000 --> 01:20:09.200
besten geben

01:20:09.200 --> 01:20:17.800
gespannt was das ist moved on copy on cut und und on paste to global event handlers

01:20:17.800 --> 01:20:25.120
was tut das ja also ich würde

01:20:25.480 --> 01:20:33.680
vermuten dass dass du dass das bisher event handlers waren die an bestimmte

01:20:33.680 --> 01:20:38.600
elemente gekoppelt waren also ist die nur auf bestimmten elementen ausgelöst

01:20:38.600 --> 01:20:45.440
werden konnten was vermutlich dann einfach irgendwie inputs waren und das

01:20:45.440 --> 01:20:50.960
dass das im prinzip jetzt auf jedem element ausgelöst werden kann was

01:20:50.960 --> 01:20:57.680
vielleicht dann content editable elemente neu umfasst aber wahrscheinlich waren die

01:20:57.680 --> 01:21:02.920
vorher schon dabei aber möglicherweise möchte man trotzdem genau wenn man

01:21:02.920 --> 01:21:08.160
zum beispiel auf dem dokument fokussiert ist und nicht auf einem input

01:21:08.160 --> 01:21:15.640
einen reinpasten können und dann fängt man das eben ab und leitet das dann

01:21:15.640 --> 01:21:22.800
dahin wo man wo man es eben braucht dass was da eingepasted wurde exakt exakt

01:21:22.800 --> 01:21:28.080
optimale beschreibung genau das richtige nur halt noch eins andere use case

01:21:28.080 --> 01:21:33.680
noch event delegation ja du würdest ja gegebenenfalls wirklich sagen wollen

01:21:33.680 --> 01:21:38.200
keine ahnung document body dot on paste gleich function und obwohl du programmierst

01:21:38.200 --> 01:21:41.280
als wärst du gerade der jungsteinzeit entstiegen willst du aber diese fancy

01:21:41.280 --> 01:21:45.240
event delegation technik verwenden auch dann funktioniert das ich habe mir das

01:21:45.240 --> 01:21:47.520
aus irgendwelchen gründen mal drauf geschafft wie das alles so funktioniert

01:21:47.520 --> 01:21:50.600
mit diesem global event handlers und so und das wohnt jetzt in meinem kopf und

01:21:50.600 --> 01:21:53.320
deswegen wenn ich sowas sehe was eigentlich wirklich niemand braucht weil

01:21:53.320 --> 01:21:58.360
niemand schreibt document dot body dot on paste gleich function man macht

01:21:58.360 --> 01:22:02.160
event listener und dann ist das sowieso alles egal aber nur für den fall dass

01:22:02.160 --> 01:22:07.400
man es mal nicht machen würde würdest trotzdem sind die auch nicht als copy

01:22:07.400 --> 01:22:12.200
cut und paste events da aufgelistet sondern tatsächlich dediziert als on copy

01:22:12.200 --> 01:22:20.160
on cut und on paste weil es da quasi um die steinzeit notation geht genau aber

01:22:20.160 --> 01:22:24.800
irgendwie fernspielter event delegation mit rein das ist ja quasi du du horchst

01:22:24.800 --> 01:22:29.920
am am ruht und kriegst dann solche events mit auch wenn die irgendwie tiefer im

01:22:29.920 --> 01:22:36.360
dom stattfinden genau und das ging vorher nicht das heißt du konntest

01:22:36.360 --> 01:22:44.040
vorher keinen irgendwie on copy auf dem body setzen dann hat dieser event

01:22:44.040 --> 01:22:48.240
handler das nicht mitbekommen wenn innerhalb des bodies in einem text area

01:22:48.240 --> 01:22:52.400
was kopiert wurde richtig richtig was aber niemanden stört weil niemand

01:22:52.400 --> 01:22:57.600
on copy schreibt und alle machen event listener copy okay und das geht auch

01:22:57.600 --> 01:23:03.720
dann tatsächlich nicht bei allen events weil bestimmte events so eingerichtet

01:23:03.720 --> 01:23:09.280
sind dass die nicht babbeln und andere babbeln ist es hat das damit zu tun ich

01:23:09.280 --> 01:23:12.160
weiß jetzt nicht ob das sozusagen die herleitung ist aber es ist auf jeden fall

01:23:12.160 --> 01:23:16.320
so dass das phänomen so zutrifft also Dinge wie das clay event gibt es halt

01:23:16.320 --> 01:23:21.720
nur auf dem video glaube ich jetzt es gibt solche aber es ist halt wirklich so

01:23:21.720 --> 01:23:26.720
diese ganze mechanik von html attribute on copy und dom property on copy und

01:23:26.720 --> 01:23:29.920
diese ganze string wird zu einer funktion funktion wird zu einem string

01:23:29.920 --> 01:23:33.880
je nachdem wie du die getter und zetter aufrufst das ist halt eben alles jetzt

01:23:33.880 --> 01:23:36.400
für die drei events auch auf dem interface global event handlers

01:23:36.400 --> 01:23:47.200
implementiert also wirklich so okay brauchst du vielleicht nicht nie aber

01:23:47.200 --> 01:23:52.480
vielleicht also irgendwie so der anlass wird wahrscheinlich sein irgendeine

01:23:52.480 --> 01:23:56.880
webseite oder irgendein web app wird es halt aus irgendwelchen also es kommt ja

01:23:56.880 --> 01:24:01.080
dann doch öfter vor als man denkt tatsächlich mit diesen on irgendwas

01:24:01.080 --> 01:24:06.640
ding an anstatt event listener und da wird es wahrscheinlich irgendeine anwendung

01:24:06.640 --> 01:24:11.800
geben die das benutzt hat und die dann irgendwelche bug reports gefeilt haben

01:24:11.800 --> 01:24:16.680
gegen webkit und dann hatten die irgendwann die nase voll und haben

01:24:16.680 --> 01:24:20.640
sich halt wahrscheinlich anderen den anderen browser herstellern angeglichen

01:24:20.640 --> 01:24:26.280
nämlich mal an ich denke es ist halt wahrscheinlich keine so große aufrisöle

01:24:26.280 --> 01:24:30.080
jetzt mal erwarten weil das grundsätzliche behavior ja für die

01:24:30.080 --> 01:24:35.640
ganzen anderen elements irgendwie on key ab und so ja auch schon da war aber ich

01:24:35.640 --> 01:24:39.440
meine es sind halt so sachen so dinge müssen sind halt auch da und die werden

01:24:39.440 --> 01:24:43.040
halt eben auch repariert und so gleicht sich halt eben diese ganze diese ganze

01:24:43.040 --> 01:24:45.320
standards geschichte am ende immer mehr an und die browser werden halt immer

01:24:45.320 --> 01:24:48.640
gleicher nicht nur weil die jetzt eben die alle zu chromotieren sondern auch

01:24:48.640 --> 01:24:54.880
weil tatsächlich selbst in so ultra ranständige probleme energie reingesteckt

01:24:54.880 --> 01:24:57.040
wird und da werden da wird code geschrieben und da werden dann tests

01:24:57.040 --> 01:25:00.840
geschrieben und release notes geschrieben und das ist halt eben

01:25:00.840 --> 01:25:05.080
eigentlich so das ding kann es kann ganze frameworks verwenden bis der

01:25:05.080 --> 01:25:09.520
arzt kommt aber immer wenn man da was neues lernt tickt dann halt sofort die

01:25:09.520 --> 01:25:13.040
uhr und irgendwann ist es veraltet muss ersetzt werden oder das framework stirbt

01:25:13.040 --> 01:25:16.240
oder sonst irgendwas und die webplattform ist das gegenteil wird halt immer

01:25:16.240 --> 01:25:19.480
besser auch wenn das was besser wird vielleicht wie webkomponent im moment eher

01:25:19.480 --> 01:25:25.320
schlechter ist aber zumindest stimmt die richtung ja ja genau also das wissen

01:25:25.320 --> 01:25:31.680
kann man auch kann man mutmaßlich lange gebrauchen genau kurz noch eben meine

01:25:31.680 --> 01:25:36.440
erforschungen zum label element haben jetzt keine definitive antwort ergeben

01:25:36.440 --> 01:25:42.400
aber es gibt zumindest etwas was davon spricht dass das label event ein

01:25:42.400 --> 01:25:46.600
activation behavior auslöst was dann halt eben das fokussieren von dem

01:25:46.600 --> 01:25:51.640
betroffenen formular element ist und ich würde mal annehmen auch wenn das im

01:25:51.640 --> 01:25:56.080
moment nicht in den internals von attach internals drin zu sein scheint dass das

01:25:56.080 --> 01:25:58.480
zumindest nicht ausgeschlossen ist dass es das mal geben wird und ich würde auch

01:25:58.480 --> 01:26:03.400
eher sagen da kann man tatsächlich einen ganz guten case machen in den bug

01:26:03.400 --> 01:26:07.560
trackern dieser welt dass das passieren müsste weil wie du richtig sagst relativ

01:26:07.560 --> 01:26:13.320
offensichtlich dass da was fehlt ja ich glaube das ist relativ bekannt also

01:26:13.320 --> 01:26:21.840
dass das so ein problem ist ja cool aber ich würde sagen dann also vielen dank

01:26:21.840 --> 01:26:28.960
auf jeden fall für deine recherche und auch vielen dank hier für das quatschen

01:26:28.960 --> 01:26:33.800
es war mir wie immer ein vergnügen genau wir sind da jetzt durch durch beide

01:26:33.800 --> 01:26:40.720
releases durch und waren schon ein paar coole sachen dabei und gelernt habe ich

01:26:40.720 --> 01:26:45.720
auch wieder was müssen wir jetzt nur gucken ob uns dieser browser halt noch

01:26:45.720 --> 01:26:53.960
erhalten bleibt du meinst hier nach diesen wenn jetzt der european was das

01:26:53.960 --> 01:27:00.040
digital markets act oder wieder heißt kommt genau die apple andro browser zu

01:27:00.040 --> 01:27:05.040
lassen müssen genau also es ist ja so die die auswahl ist ja schon relativ

01:27:05.040 --> 01:27:08.800
schmal geworden an der browser das war ja früher mal deutlich mehr an engines

01:27:08.800 --> 01:27:12.920
das ist jetzt so einer von denen die halt noch übrig ist und das ist ja schon so

01:27:12.920 --> 01:27:17.880
ein bisschen so der der kandidat gallisches dorf so ein ganz klein wenig

01:27:17.880 --> 01:27:22.000
weil die ja buchstäblich hinter ihren hinter ihren palisaden da stehen und

01:27:22.000 --> 01:27:25.320
sich mühsam verteidigen nur würde ich jetzt nicht notwendigerweise sagen dass

01:27:25.320 --> 01:27:31.040
die so wie asterix und obelix definitiv die guten sind aber es sind zumindest mal

01:27:31.040 --> 01:27:35.720
welche und ich werde auch nicht sagen dass die damit dem digital markets act

01:27:35.720 --> 01:27:38.880
wenn die dahin gehen und sagen so du musst jetzt hier im prinzip ja genauso

01:27:38.880 --> 01:27:42.800
wie microsoft damals tür und tor öffnen für die konkurrenz ist das ist

01:27:42.800 --> 01:27:46.520
sicherlich richtig so und ich will nicht sagen dass das nicht passieren sollte

01:27:46.520 --> 01:27:51.200
nur wenn uns dann hinterher dieser browser flürten geht oder so auf ein

01:27:51.200 --> 01:27:56.120
relevantes niveau vom firefox heutzutage zurückgedampft wird mich nicht

01:27:56.120 --> 01:28:00.640
wundern so ein bisschen pessimismus würde ich da schon mal vorrat mal haben

01:28:00.640 --> 01:28:04.320
damit man hinterher nicht überrascht ist genau andererseits muss man ja sagen

01:28:04.320 --> 01:28:08.480
also man hat ja schon gemerkt ich weiß nicht wie lange das jetzt geht also

01:28:08.480 --> 01:28:12.600
sagen wir mal drei vier jahre dass die ja auch irgendwie ordentlich kritik

01:28:12.600 --> 01:28:19.480
eingesteckt haben genau aber seitdem passiert auch echt ganz schön viel also

01:28:19.480 --> 01:28:25.320
und ich denke mal auch dass das sozusagen einen antizipieren der

01:28:25.320 --> 01:28:32.160
möglichkeit ist dass eben andere browser auf ios landen und ja also wenn man dann

01:28:32.160 --> 01:28:35.200
ein gutes angebot hat dann bleiben die leute auch ich meine es ist ja schon

01:28:35.200 --> 01:28:39.920
ein riesen vorteil wenn du der quasi mitgelieferte browser bist und das sieht

01:28:39.920 --> 01:28:46.040
man ja auch bei android und chrome und ich glaube ich mein e wurde ja auch viel

01:28:46.040 --> 01:28:51.120
genutzt bis bis weiter einfach nur noch scheiße war ja und ich meine etsch wird

01:28:51.120 --> 01:28:53.920
ja heute immer noch viel genutzt der ist jetzt das jetzt ja chrome ist ja okay

01:28:53.920 --> 01:28:57.400
der ist nicht schlechter als chrome aber trotzdem ist der default halt eben das

01:28:57.400 --> 01:29:00.960
ist das ist normalerweise da in windows und das ist gut genug und das passt schon

01:29:00.960 --> 01:29:06.120
und stimmt ja auch ist ja gut genug aber etsch ist halt auch keine eigene

01:29:06.120 --> 01:29:10.920
entität mehr so in dem sinne und chrome ist sowieso der de facto standard und

01:29:10.920 --> 01:29:13.840
der wäre es halt eben auch wenn er nicht bei einen android der mitgeliefert

01:29:13.840 --> 01:29:16.840
genau man sieht es ja an firefox also die haben ja keine eigene plattform die

01:29:16.840 --> 01:29:21.840
ist es ja eigentlich auch ein guter browser aber also firefox os das hat

01:29:21.840 --> 01:29:25.720
der das hat nicht geklappt hätten sie vielleicht auch lieber nicht versuchen

01:29:25.720 --> 01:29:31.520
weiß ich nicht ich fand prinzipiell schon nicht schlecht ich glaube ich glaube

01:29:31.520 --> 01:29:35.360
dieses was ich halt irgendwie wahrscheinlich also was ich do fand war

01:29:35.360 --> 01:29:41.560
dieser ansatz dass die so ganz low-levelige geräte quasi nur

01:29:41.560 --> 01:29:46.280
ausgebracht haben damit die halt günstig sind und so ist ja auch alles toll

01:29:46.280 --> 01:29:52.440
aber das sind keine geräte gewesen die man eigentlich haben wollte und man

01:29:52.440 --> 01:29:56.840
auch keine die spaß gemacht haben ich hatte auch so ein teil aber es war

01:29:56.840 --> 01:30:05.080
halt was cool das ist halt irgendwie so weißt du ich stelle mir ein mechanischen

01:30:05.080 --> 01:30:09.520
taschenrechner ins regal weil es cool aber ich beabsichtige nicht den zu

01:30:09.520 --> 01:30:12.320
benutzen für meine tägliche arbeit genau das war ja eigentlich nur so ein

01:30:12.320 --> 01:30:19.240
kuriosum also genau darum hat man es wirklich genau genau

01:30:19.240 --> 01:30:25.520
nee und ich glaube die von firefox das ist halt so einer der gründe für den

01:30:25.520 --> 01:30:30.040
niedrigen marktenteil und wenn die webkit leute irgendwie weiter gas geben

01:30:30.040 --> 01:30:37.400
und aufschließen dann habe ich da jetzt erst mal nicht so viele bedenken also

01:30:37.400 --> 01:30:43.680
dass die den den widerstand aufrecht erhalten können ja glaube ich schon man

01:30:43.680 --> 01:30:47.600
muss ja schon einige schritte gehen bis man dann irgendwie seinen anderen

01:30:47.600 --> 01:30:52.520
pause installiert warum lässt man dann nicht einfach den anderen dem oder

01:30:52.520 --> 01:30:55.920
nimmt man nicht den der e schon drauf ist der halt eben natürlich auch viel

01:30:55.920 --> 01:30:59.240
besser ins betriebssystem integriert werden kann einfach nur weil man sich

01:30:59.240 --> 01:31:02.040
dann natürlich als mobile safari zum beispiel es leisten kann sich darauf

01:31:02.040 --> 01:31:05.360
zu konzentrieren und man als chrome ja irgendwie für alle irgendwie eine

01:31:05.360 --> 01:31:09.560
extra wurspraten muss was rein von den ressourcen die sicherlich leisten

01:31:09.560 --> 01:31:14.040
können aber es macht ihnen halt auch nicht leichter ja wir werden sehen wie es

01:31:14.040 --> 01:31:18.360
weitergeht ja also ich bin jetzt ja nun wirklich nicht die apfeltasche vom

01:31:18.360 --> 01:31:25.720
dienst oder halte jetzt da apple und safari für die guten aber ich würde

01:31:25.720 --> 01:31:30.760
ihnen trotzdem wünschen dass sie da am leben bleiben und er bringt ja was ich

01:31:30.760 --> 01:31:34.000
meine wir haben ja hier mehrfach gesagt so geht jetzt in safari aber firefox

01:31:34.000 --> 01:31:38.440
kann es nicht hier noch nicht implementiert dann auch nicht fertig ja es

01:31:38.440 --> 01:31:41.920
gibt halt einfach bestimmte bereiche da sind die einfach stark unter anderen

01:31:41.920 --> 01:31:45.920
sind die halt nicht so stark ich würde sagen so so web api sind die

01:31:45.920 --> 01:31:50.280
talsinell eigentlich eher nicht so besonders stark und aber so rendering

01:31:50.280 --> 01:31:55.040
gezeugs und sowas da sind die ja echt immer vorne weg ja css und so es ist

01:31:55.040 --> 01:31:57.080
ja wirklich

01:31:57.080 --> 01:32:01.120
schon gut also ja machen sie gut so sollen sie weiter machen ich wünsche mir

01:32:01.120 --> 01:32:05.360
auch dass sie weiter machen damit die zukunft nicht eine komplette monokultur

01:32:05.360 --> 01:32:13.720
wird ja mal sehen wie es in der revision 750 dann ausschaut ich mache mir

01:32:13.720 --> 01:32:20.720
ein kalender wieder treffen super dann danke schön ich habe so dann vielen

01:32:20.720 --> 01:32:26.960
dank an die höheren und höherer fürs zuhören wie von erwähnt wenn ihr

01:32:26.960 --> 01:32:31.440
input habt oder fragen zum beispiel zu der grid implementation die ich

01:32:31.440 --> 01:32:37.280
gemacht habe dann haben wir jetzt eben dieses draft community was quasi von

01:32:37.280 --> 01:32:41.280
der landing page ist wo ihr dann in unseren slack kommt und da sind auch

01:32:41.280 --> 01:32:45.360
andere höheren und höherer drin also wenn ihr möchtet schaut da vorbei oder

01:32:45.360 --> 01:32:49.080
schickt uns eine mail an comments at working graph die oder ihr findet uns

01:32:49.080 --> 01:32:51.760
natürlich auf twitter und

01:32:51.760 --> 01:32:58.240
was so dann genau und bevor wir hier Schluss machen haben wir noch

01:32:58.240 --> 01:33:01.440
eine sache vergessen wir wollen nämlich noch dem hanes danken der ist nämlich

01:33:01.440 --> 01:33:09.760
unser neuster pattern patron vielen dank für deine unterstützung und bleibt

01:33:09.760 --> 01:33:15.000
noch zu sagen wir hören uns nächste woche da geht es wahrscheinlich um nochmal

01:33:15.000 --> 01:33:21.920
um ausbildungswege zum webenwickler und webenwicklerin genau hatten wir ja schon

01:33:21.920 --> 01:33:27.640
mal glaube ich ist um studium und so und das nächste mal wollen wir mal den

01:33:27.640 --> 01:33:32.680
anderen weg dahin beleuchten wenn alles klappt und nicht wieder irgendwelche

01:33:32.680 --> 01:33:41.840
krankheiten dazwischen kommen die bei der revision 557 also bis nächste

01:33:41.840 --> 01:34:11.280
woche macht es gut ist dahin tschüss tschüssi
Liked it? Take a second to support Peter on Patreon!
Become a patron at Patreon!