Working Draft

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