Schepp und Peter nahmen die Veröffentlichung der Safari Technology Previews 161 und 162 zum Anlass, die dort frisch implementierten Features zu diskutieren und zu kommentieren.
Schaunotizen
- [00:01:25] Best of Safari Technology Preview
- Los geht es mit neuen Media-Query-Features, speziell
prefers-reduced-motion
undprefers-contrast
(die in den Previews nicht neu sind, aber jetzt besser debugged werden können). Wir diskutieren die Hürden im praktischen Einsatz dieser Features (sowie vonprefers-color-scheme
) und erinnern an Hotdog Stand. Die Unterstützung von@property
fehlt nach den neuesten Safari-Updates nun nur noch in Firefox, aber insgesamt sieht es für das CSS Typed OM und das Houdini-Projekt eher nicht so glänzend aus (Working Draft berichtete bereits). Über Fragen des Umgangs mit immer komplexerem CSS kommen wir zum Thema Selektor-Performance von:has()
, die sich mit dem Profi-Profiling-Tool von Chrome messen lässt. Die Unterstützung von:user-invalid
und:user-valid
feiern wir marginal enthusiastischer als die von Lookbehind Assertions in Regulären Ausdrücken und wir nehmen die (beinahe) bestehende Existenz des ResizableArrayBuffer zur Kenntnis. Safari wird nun als letzter fehlender Browser Unterstützung für OffscreenCanvas bekommen, was Peter dazu bringt, seine jüngsten Abenteuer rund umwillReadFrequently
nochmal wiederzugeben. Zum Ende hin quatschen wir noch übermargin-trim
, CSS Subgrids, Declarative Shadow DOM, E4X,HTMLElement.attachInternals()
bzw. Form-associated custom elements, globale Event Handler und die Zukunft von Safari und der ganzen weiten Browserwelt.
Transkript
WEBVTT 00:00.000 --> 00:06.360 Bist du einer der reduced motion referiert oder eher nicht und ich brauche es nicht 00:07.040 --> 00:11.040 Preverse reduced motion ist ja ein feature dass wir als webentwicklerinnen 00:12.120 --> 00:13.520 verwenden können 00:13.520 --> 00:18.320 Und die frage ist wenn ich jetzt jemand bin der darauf angewiesen ist dass die motion reduced ist so wie du es gerade beschrieben hast 00:19.200 --> 00:25.360 Dann kann ich doch webentwickler die ja tendenziell dazu neigen über lange animationen zu machen und zu verspielt zu werden doch nicht über einen 00:25.360 --> 00:31.360 Weg trauen oder? 00:31.360 --> 00:33.360 und 00:51.040 --> 00:54.000 working draught revision 557 00:54.000 --> 01:02.520 diese revision von working draught wird euch präsentiert von höhrerinnen und höhrern wie euch auf patreon.com 01:03.160 --> 01:09.360 Working draught könnt ihr uns ein paar euro in den hut werfen aus euren beiträgen und unseren gelinglichen werbeeinnahmen bezahlen wir allerleit 01:09.360 --> 01:12.280 höhere software bus und das honorar unserer audio produceren 01:12.560 --> 01:15.200 Wenn ihr euch auch beteiligen wollt könnt ihr das unter patreon.com 01:15.200 --> 01:23.760 Slashworking draught sehr gerne machen wir danken euch tausendfach für die unterstützung und fürs weitere zuhören 01:25.760 --> 01:30.960 Wir sind heute zu zweit und zwar während er zum ein der peter 01:31.520 --> 01:35.000 moin moin und ich bin der cheb und wir 01:35.680 --> 01:37.680 haben uns überlegt dass wir 01:37.680 --> 01:40.280 anlässlich der letzten safari 01:40.800 --> 01:42.320 technology previews 01:42.320 --> 01:45.320 technik previews technologie previews 01:45.320 --> 01:48.320 einfach mal wieder ein bisschen über webkit reden 01:48.320 --> 01:50.320 und 01:50.320 --> 01:53.320 was da so alles neues passiert 01:53.320 --> 01:58.320 weil das doch schon so einiges ist und auch ein paar coole sachen 01:58.320 --> 02:04.320 genau wo hingegen wir festgestellt haben dass im safari 16.3 der jetzt ja gerade 02:04.320 --> 02:08.320 irgendwie diese woche also in dieser aufnahmewoche ausgerollt wurde 02:08.320 --> 02:15.320 dass da im grunde nur bug fixes drin sind genau was auch cool ist die semantik versioning oder irgendwie so was ist das normal 02:15.320 --> 02:24.320 die versionsnummer von safari ist ja glaube ich immer gekoppelt an die versionsnummer das betrachten ja das kann auch nicht sein 02:24.320 --> 02:28.320 weil ich glaube also zumindest an die ios version 02:28.320 --> 02:32.320 genau das war auch mein eindruck aber beim desktop weiß ich nichts 02:32.320 --> 02:35.320 ja ich glaube desktop ist anders 02:35.320 --> 02:36.320 genau 02:36.320 --> 02:39.320 ja muss ja die aktuelle ist irgendwie 02:39.320 --> 02:41.320 ja 02:41.320 --> 02:44.320 wir sind doch echt die falschen leute für fragen zu macOS 02:44.320 --> 02:46.320 definitiv ja 02:46.320 --> 02:48.320 google das jetzt nochmal schnell 02:48.320 --> 02:51.320 aktuelle version wir bräuchten jetzt chatgbt 02:51.320 --> 02:53.320 also 02:53.320 --> 02:55.320 10.14.6 02:55.320 --> 02:57.320 ist wohl die aktuelle 02:57.320 --> 03:01.320 was überhaupt gar nichts mit der versionnummer von safari zu tun hat 03:01.320 --> 03:03.320 das stimmt 03:03.320 --> 03:09.320 gut aber auf jeden fall ist die 16.3 nur ein bug fix release deswegen 03:09.320 --> 03:15.320 übersehen wir das einfach weil da gibt es halt nichts spannendes außer dass Dinge die sowieso funktionieren sollten funktionieren 03:15.320 --> 03:19.320 genau und im webkit Bereich ist es natürlich trotzdem 03:19.320 --> 03:23.320 schön also man freut sich über darüber das zu lesen weil 03:23.320 --> 03:28.320 die haben ja viele coole features aber leider ja auch öfters mal ganz ganz merkwürdige bugs 03:28.320 --> 03:34.320 genau das heißt also da ist einiges hoffentlich stabiler und besser als vorher 03:37.320 --> 03:44.320 gut aber ich würde sagen wir gehen mal durch die beiden technologie previews durch die wir da haben 161 und 162 03:44.320 --> 03:49.320 und machen im prinzip so eine art non random glücksrad 03:49.320 --> 03:53.320 gucken wir mal was uns so zu den einzelnen features und 03:53.320 --> 03:58.320 Sachen so einfällt die da jetzt aktiviert wurden implementiert wurden oder etwas 03:58.320 --> 04:01.320 und bug fix wurden oder wo es halt eben einfach auch nur 04:01.320 --> 04:07.320 Änderungen gibt in irgendwelchen developer tools das kann uns ja eventuell auch dazu verleiten irgendwie 04:07.320 --> 04:09.320 ja 04:09.320 --> 04:13.320 irgendwas auf die themenplatte zu setzen ich würde direkt mal aufschlagen 04:13.320 --> 04:18.320 ja gerne mit dem ersten feature dass sie in der technologie preview 161 04:18.320 --> 04:24.320 geführt haben nämlich emulation toggles für css media features und zwar 04:24.320 --> 04:28.320 pre first reduced motion und pre first contrast 04:28.320 --> 04:32.320 erstmal ist natürlich sinnvoll dass man das irgendwie in seinen dev tools 04:32.320 --> 04:36.320 bekommt sonst kann man ja nicht testen was man da macht aber jetzt würde ich natürlich 04:36.320 --> 04:39.320 erstmal so die frage an dich schäbstellen 04:39.320 --> 04:44.320 hast du die im einsatz und wie entscheidet man sich dazu die einzusetzen in welchem 04:44.320 --> 04:48.320 rahmen oder so weil das fällt ja so in die gleiche kategorie von so user 04:48.320 --> 04:53.320 preferences umsetzen wie ein dark mode rein also pre first color scheme oder wie das heißt 04:53.320 --> 04:58.320 ja und das kriege ich ja noch so einig einigermaßen so in meinem cortex so 04:58.320 --> 05:01.320 vorgehalten es gibt irgendwie so die helle seite die dunkle seite das wissen 05:01.320 --> 05:05.320 wir schon seit lux skywalker und das kriege ich irgendwie so alles rein aber 05:05.320 --> 05:11.320 wie handhabt man so als man an der front diese preferred reduced motion und diese 05:11.320 --> 05:16.320 ganzen anderen preferences die man da so umsetzen kann ja bevor ich darauf 05:16.320 --> 05:20.320 antworte wollte ich noch vorab schicken du hast treffenerweise gesagt dass das 05:20.320 --> 05:26.320 ja media features sind kannst du noch kurz sagen was der unterschied warum du 05:26.320 --> 05:31.320 nicht media query gesagt hast ich glaube technisch gesehen ist es so media query 05:31.320 --> 05:34.320 ist ja so die gesamtheit von ad media und dann kommt da ihr kommt da irgendwelche 05:34.320 --> 05:38.320 regeln und dann gibt es darin die types und die features und die features sind 05:38.320 --> 05:42.320 im prinzip die wenn ich das so mal hinsetzen darf das sind im prinzip die 05:42.320 --> 05:47.320 parametrisierbaren varianten wo man irgendwie sagen kann breite bis oder 05:47.320 --> 05:52.320 color scheme dieses oder jenes und die alten waren die media features mit den 05:52.320 --> 05:57.320 vorgegebenen im prinzip geräteklassen von wegen es gibt ein mir type tv es gibt 05:57.320 --> 06:01.320 ein mir type handheld zuzeiten als es eine klare trennung gab zwischen zum 06:01.320 --> 06:04.320 beispiel einem handheld device und nicht wo das ja heutzutage irgendwie 06:04.320 --> 06:09.320 hybridgeräte sein können und wo ihr auch ein fernseher definitiv ein bestimmtes 06:09.320 --> 06:13.320 benutzungsmodell und niedrig auflösenden röhrenschirm und so was ähnliches 06:13.320 --> 06:19.320 vorausgesetzt hat so in der richtung ja genau ja die weil tatsächlich diese 06:19.320 --> 06:24.320 media features sind ja eben nur quasi ein baustein einer media query und diese 06:24.320 --> 06:29.320 media features kannst du ja auch in html bei ganz vielen elementen benutzen also 06:29.320 --> 06:38.320 bei dem source zum beispiel oder also für das picture element und bei video 06:38.320 --> 06:46.320 und bei link rel jetzt zum beispiel preload das ist dann eben das media feature 06:46.320 --> 06:51.320 und in css mit der ad media rule und dem ganzen schnick und schnack dadurch 06:51.320 --> 06:56.320 dadurch wird es erst so media query genau habe ich auch irgendwie lange gar nicht 06:56.320 --> 07:00.320 so drauf geachtet ist jetzt auch nicht unbedingt was also es ist jetzt nicht 07:00.320 --> 07:05.320 super wichtig dass man es weiß aber war dann irgendwann ist es mir das mal 07:05.320 --> 07:10.320 aufgefallen dass es eben doch zwei paar schuhe sind ja aber ich meine im prinzip 07:10.320 --> 07:14.320 ist ja das einzige also die einzigen zwei media types die ja noch relevant sind 07:14.320 --> 07:20.320 sind ja tatsächlich screen also der default und print maximal noch ja und das 07:20.320 --> 07:23.320 sind ja im prinzip wenn man jetzt mal so die analogie wieder her nimmt von wegen die 07:23.320 --> 07:27.320 feature sind parametrisierbare varianten könntest du ja im prinzip genauso gut 07:27.320 --> 07:31.320 sagen dass die types einfach nullstellige funktionen sind und dann kannst du das 07:31.320 --> 07:34.320 durchaus alles in einen top werfen und rumrühren weil ich glaube am ende 07:34.320 --> 07:37.320 interessiert das nicht so wirklich also da gibt es keinen druck die und zu 07:37.320 --> 07:43.320 unterscheiden glaube ich wenn man spezifikationen ja genau und um dann 07:43.320 --> 07:48.320 deine frage zu beantworten also tatsächlich also prefers contrast ist was 07:48.320 --> 07:54.320 dass ich momentan oder auch in der vergangenheit gar nicht bisher irgendwie 07:54.320 --> 08:00.320 bakere genau ich glaube da würde ich wahrscheinlich auch noch mal irgendwie 08:00.320 --> 08:05.320 mich einlesen wollen bevor ich da einfach ad hoc irgendwas mit baue im 08:05.320 --> 08:11.320 grunde genommen wünscht sich da eben der die besuchende oder der besucher 08:11.320 --> 08:18.320 einfach einen höheren kontrast es gibt ja noch diesen high contrast mode zum 08:18.320 --> 08:23.320 Beispiel in windows der sieht auch richtig also der ist schon echt übel so 08:23.320 --> 08:28.320 für ihr meintest du meinst hotdog stand richtig ist das hotdog stand ich glaube 08:28.320 --> 08:32.320 das glaube ich das war so ein theme das konnte man einsteigen hotdog stand war 08:32.320 --> 08:36.320 das halt eben das knallrote mit knallgelben ja ich glaube so der 08:36.320 --> 08:40.320 kontrast modus den du meinst nee aber so von der wirkung her auf jeden fall 08:40.320 --> 08:45.320 ähnlich da weiß ich jetzt gerade nicht ob das ob das das gleiche ist wie 08:45.320 --> 08:50.320 prefers contrast und deswegen sage ich also wenn ich dieses fällt irgendwie 08:50.320 --> 08:55.320 anfangen zu barkern würde ich mich da wahrscheinlich erstmal einlesen wollen 08:55.320 --> 09:02.320 genau prefers reduced motion das setze ich ein aber eigentlich eigentlich 09:02.320 --> 09:08.320 falsch weil was ich damit mache ist dass ich immer sozusagen alle animationen 09:08.320 --> 09:15.320 wieder wegnehme wenn jemand dieses diese preference gesetzt hat und ich glaube 09:15.320 --> 09:22.320 korrekt darf händis wenn ich die animationen in so ein prefers reduced motion 09:22.320 --> 09:30.320 hineinwickeln wo jemand sagt er möchte oder sie weil das dann quasi so ein 09:30.320 --> 09:36.320 art progressive enhancement ist und wer eben einen alten browser hat indem man das 09:36.320 --> 09:42.320 eben so nicht melden kann an die webseite dann dann hat man auch trotzdem fällt 09:42.320 --> 09:46.320 man eben zurück auf man hat keine animationen und wenn man eben dann eine 09:46.320 --> 09:51.320 betroffenen person ist und einen älteren browser hat dann braucht man eben kein 09:51.320 --> 09:57.320 kotz einwand neben seinem rechner wenn man die webseite betrachtet aber dann 09:57.320 --> 10:03.320 könnte man doch theoretisch einfach ganz ans ende von allem doch für alle 10:03.320 --> 10:09.320 elemente alle animationen und transitions auf aufschalten wird das nicht funktionieren 10:09.320 --> 10:16.320 genau so so mache ich das aber ich glaube ich finde also im infekt ist das jetzt 10:16.320 --> 10:20.320 das feinheiten ich glaube ich finde den umgekehrten ansatz besser wo man eben 10:20.320 --> 10:27.320 animationen hinzufügt wenn jemand prefers reduced motion ausgeschaltet hat 10:27.320 --> 10:33.320 genau und so wie du es gerade gesagt hast so mache ich das und so machen das 10:33.320 --> 10:38.320 glaube ich auch viele dass dass man dann einfach animation nun transition dann 10:38.320 --> 10:43.320 und dann noch important genau und die dinge dann nachträglich wieder 10:43.320 --> 10:50.320 abschaltet bist du einer der reduced motion preferiert oder er nicht 10:50.320 --> 10:58.320 und ich brauche es nicht also das ist ja dann es gibt weiß gar nicht vestibular 10:58.320 --> 11:04.320 oder motion sickness irgendwie dann ist dein gleichgewichtsorgan gestört glaube 11:04.320 --> 11:09.320 ich und es gibt so bestimmte arten von animationen die die du dann einfach nicht 11:09.320 --> 11:15.320 gut verträgst also wir wird zwar in der barn schlecht wenn ich arbeite und im 11:15.320 --> 11:20.320 auto wenn ich lese aber da da habe ich jetzt keine probleme ich finde aber 11:20.320 --> 11:26.320 manchmal tatsächlich wenn Sachen so zu verspielt und zu langartig animiert sind 11:26.320 --> 11:35.320 dann also dann finde ich das doof irgendwie schnell vorwärts kommen will ja gut 11:35.320 --> 11:39.320 aber das geht uns ja allen so die frage auf die ich halt hinaus möchte ist die 11:39.320 --> 11:45.320 first reduced motion ist ja ein feature dass wir als webentwicklerin verwenden 11:45.320 --> 11:49.320 können und die frage ist wenn ich jetzt jemand bin der darauf angewiesen ist 11:49.320 --> 11:52.320 dass die motion reduced ist so wie du es gerade beschrieben hast dann kann ich 11:52.320 --> 11:56.320 doch webentwickler die ja tendenziell dazu neigen über lange animationen zu 11:56.320 --> 12:00.320 machen und zu verspielt zu werden doch nicht über den weg trauen oder also für 12:00.320 --> 12:05.320 wen ist dieses feature ich kann mich ja wenn ich jetzt sozusagen den kurz einmal 12:05.320 --> 12:09.320 brauche wenn das wenn ich zu viel animationen habe kann ich mich ja nicht 12:09.320 --> 12:12.320 darauf verlassen dass das vernünftige webentwickler in weiser voraussicht 12:12.320 --> 12:15.320 abschalten sondern ich muss doch eigentlich andere wege finden das zu 12:15.320 --> 12:19.320 machen mit meinen user style sheets alle transitions abschalten oder mein 12:19.320 --> 12:24.320 betriebssystem irgendwie einrichten oder ähnliches ist das nicht so ja also 12:24.320 --> 12:29.320 wahrscheinlich wäre das der sichere weg genau also was genau und dann kann 12:29.320 --> 12:33.320 es vielleicht noch sein dass irgendwelche javascript gesteuerten animationen 12:33.320 --> 12:41.320 da da könnte man ja dann so ein match media abfrage machen genau die frage 12:41.320 --> 12:45.320 ist ob das überhaupt jemand macht aber das ist wieder sehr schön dass du wieder 12:45.320 --> 12:48.320 auf die webentwickler perspektive gehst und in meinem kopf sofort der 12:48.320 --> 12:52.320 entsprechende prototype override gebaut wurde mit dem ich halt irgendwie element 12:52.320 --> 12:56.320 und animate überschreiben kann mit das macht einfach nichts ich traue den 12:56.320 --> 13:03.320 webentwickler nicht ich glaube da hast du recht genau weil ich meine wenn ich 13:03.320 --> 13:05.320 jetzt so in meinen alltag reingucke ich muss letztens irgendwie dark mode 13:05.320 --> 13:08.320 implementieren habe halt allein schon festgestellt das klappt schon allein 13:08.320 --> 13:12.320 deshalb nicht weil auf linux der chrome die user preference ist einfach nicht 13:12.320 --> 13:16.320 umsetzt so ich stelle mein betriebssystem ein ich hätte gern dark mode das geht 13:16.320 --> 13:19.320 mit firefox auch aber chrome sagt halt eben nicht kriege ich sie halt trotzdem hier 13:19.320 --> 13:23.320 light mode und selbst dann habe ich festgestellt dass wenn ich webseiten 13:23.320 --> 13:26.320 nutze ich das gerne hin und wieder einfach auch manuell umschalte mit halt dem 13:26.320 --> 13:29.320 ding was die leute da in der ecke meistens haben also ein switch damit man 13:29.320 --> 13:33.320 das halt eben umschalten kann zwischen dark und light und wenn man schon so was 13:33.320 --> 13:36.320 bauen muss dann ist es ja eigentlich nur umso schwieriger geworden das ordentlich 13:36.320 --> 13:39.320 zu machen wenn man halt eben auch diese preference damit rein rechnen muss 13:39.320 --> 13:43.320 weil du hast ja entweder eine explizite einstellung oder ein media query switch 13:43.320 --> 13:46.320 halt eben über die preferences vom betriebssystem und wie findest du da jetzt 13:46.320 --> 13:54.320 raus was jemand wirklich haben möchte ja so ein bisschen so wie so das welche 13:54.320 --> 14:00.320 lokalisierte version meiner seite soll ich jetzt weiter leiten also macht das 14:00.320 --> 14:05.320 nur also die besuchende personen über über so ein umschalter oder gucke ich 14:05.320 --> 14:11.320 auf die quasi sprache die im http da übermittelt wird 14:11.320 --> 14:16.320 ja und selbst dann kannst du ja längst noch nicht alles umschalten irgendwie so 14:16.320 --> 14:22.320 ja ja das kommen wir da in input type number und ähnliche späße ja das ist 14:22.320 --> 14:27.320 auf jeden fall komplex und ich finde auch je mehr dieser dinge man einbaut 14:27.320 --> 14:34.320 desto mehr also multiversen hat man dann sozusagen die man testen muss neben 14:34.320 --> 14:40.320 auch noch quasi desktop und vielleicht tablet und mobile allen dazwischen dann 14:40.320 --> 14:45.320 hat man noch leitmotor dark mode und das ganze dann noch mal multipliziert mit 14:45.320 --> 14:50.320 einmal mit motion einmal ohne und also das finde ich schon sehr schwer und ich 14:50.320 --> 14:53.320 finde auch so ein dark mode ein anständigen zu bauen das ist auch richtig 14:53.320 --> 14:58.320 arbeit das gibt ja hier diesen dark mode für arme wo man quasi über css filter 14:58.320 --> 15:03.320 dann die die seite invertiert und dann alle bildelemente sich nimmt und die wieder 15:03.320 --> 15:08.320 zurück invertiert und dann noch quasi am fahrbrat dreht damit rot das nach 15:08.320 --> 15:12.320 dem invertieren grün geworden ist dann auch wieder quasi zurück ins rot gedreht 15:12.320 --> 15:18.320 wird da kommt man aber eben nur also das dann wieder pareto prinzip mit wenig 15:18.320 --> 15:23.320 aufwand schafft 80 prozent der strecke aber so richtig cool ist es nicht ist es 15:23.320 --> 15:26.320 nicht aber zum beispiel auf meinem firefox den ich auf meinem mobilgerät 15:26.320 --> 15:30.320 verwende habe ich eine extension installiert die macht halt sowas in 15:30.320 --> 15:34.320 der richtung weil ich halt den webseiten nicht zu trauen kann dass sie meine 15:34.320 --> 15:38.320 preferences irgendwie ernst nehmen und ich krieg wirklich schleuder trauma wenn 15:38.320 --> 15:41.320 ich irgendwie so mein dunkles betriebssystem habe und dann plötzlich so 15:41.320 --> 15:46.320 bamm knallweise seite es geht halt nicht sieht halt jetzt doof aus und manchmal 15:46.320 --> 15:52.320 ist auch wirklich zeug ernsthaft unlesbar aber was will man machen die web 15:52.320 --> 15:56.320 entwickeln entwickeln setzen das halt auch nicht richtig um und das wenn sie es 15:56.320 --> 15:59.320 unrichtig umsetzen wollen die zugangsdaten zu ihren jugendzünden von vor 20 15:59.320 --> 16:03.320 jahren haben sie halt auch nicht mehr und dann sind die halt so wie sie sind ja ich 16:03.320 --> 16:08.320 finde das schon also schon grundsätzlich sinnvoll dass man dass man sich 16:08.320 --> 16:15.320 dann selber hilft mit eigen user styles also die sind ja tatsächlich auch bei 16:15.320 --> 16:21.320 design vorgesehen dass die gibt und dass die genau die glaube die genau die 16:21.320 --> 16:28.320 override ja per default in der kaskade auch die website styles richtig und nur 16:28.320 --> 16:33.320 bei importen dreht sich das wenn sie importen haben haben sie die haben 16:33.320 --> 16:36.320 sie die haben sie das letzte wort aber sonst ist das irgendwie noch komplizierter 16:36.320 --> 16:40.320 aber auch das ist halt wieder das sind dann in multiversen wieder durch die halt 16:40.320 --> 16:48.320 keiner durchsteigt ja genau ja vielleicht auch einfach nochmal hier an die höhere 16:48.320 --> 16:54.320 abgegeben wie wie macht ihr das vielleicht wollte uns da mal irgendwie was 16:54.320 --> 17:01.320 schreiben in unserem community slack unter draft.community da findet ihr den 17:01.320 --> 17:06.320 weg dahin genau also ich finde das alles auch gut ich finde auch gut dass es 17:06.320 --> 17:14.320 gibt aber ich das macht halt die arbeit nicht einfacher beileibe nicht 17:14.320 --> 17:19.320 aber hey dafür kriegen wir neue neue power tools mit denen wir die arbeit noch 17:19.320 --> 17:26.320 interessanter gestalten können ja das wäre es CSS custom properties und damit 17:26.320 --> 17:31.320 meine ich jetzt nicht die ganz normalen CSS variablen mit zwei dashes davor für 17:31.320 --> 17:35.320 irgendwie so theming und so das ist ja im prinzip nur langweilige string 17:35.320 --> 17:39.320 interpolation man kann ja auch richtige eigene properties deklarieren mit 17:39.320 --> 17:43.320 ad property was ich noch nie gemacht habe aber ich habe ja zum glück hier ein 17:43.320 --> 17:48.320 kompetenten mitarbeiter im call chef erzählt was macht ad property und warum 17:48.320 --> 17:52.320 ist das gut dass wir das jetzt in safari auch demnächst haben werden oder zu 17:52.320 --> 17:57.320 wissen also ich finde das finde ich ziemlich ziemlich gut ich stehe 17:57.320 --> 18:01.320 total auf dieses ad property ich finde ja auch dass das so das beste 18:01.320 --> 18:07.320 abfallprodukt von CSS hudini ist während der rest von hudini glaube ich 18:07.320 --> 18:13.320 meiner meinung nach dann irgendwie langsam in die tonne wandern kann und 18:13.320 --> 18:18.320 haben wir eine revision zu genau wir haben auch eine revision dazu die kann 18:18.320 --> 18:23.320 wir nochmal verlinken also kurz gesagt du kannst halt einfach custom 18:23.320 --> 18:30.320 properties damit typen also CSS variablen sozusagen weil und der browser 18:30.320 --> 18:36.320 wenn du die types dann kann der browser die eben auch interpolieren und damit 18:36.320 --> 18:42.320 animieren und nützlich ist sowas bei zum beispiel 18:42.320 --> 18:49.320 wenn man gradients mit custom properties irgendwie zusammensetzt dann war es 18:49.320 --> 18:53.320 eben bisher so dass wenn man wenn man die farben oder die hintergrundfarben 18:53.320 --> 18:58.320 oder so animieren wollte und das ist eben eine custom property dann konnte 18:58.320 --> 19:03.320 der browser das nicht und dann sind die im prinzip wie so wie so ein bit von 19:03.320 --> 19:09.320 null auf eins geflippt und wenn man eben dann diese variable zum beispiel 19:09.320 --> 19:17.320 als color typed dann weiß der browser alles klar von der zu der farbe da kann 19:17.320 --> 19:21.320 ich folgendermaßen interpolieren und dann hat man eben eine animation eine 19:21.320 --> 19:25.320 flüssige genau man muss halt weg ich nochmal herausstellen normale css 19:25.320 --> 19:29.320 variablen so irgendwie mein margin oder so auch wenn ich den auf null setze 19:29.320 --> 19:33.320 steht er halt im prinzip auf dem string null also das ist halt für css nicht 19:33.320 --> 19:37.320 ersichtlich dass da irgendwie ein typ drin wohnt und deswegen kann man damit 19:37.320 --> 19:40.320 eine ganze menge sachen halt nicht tun wie zum beispiel diese interpolations 19:40.320 --> 19:44.320 geschichte ich meine das eigentlich spannende ist natürlich wenn man dann 19:44.320 --> 19:47.320 schritt zurücktritt das was du gerade beschrieben hast das properties 19:47.320 --> 19:53.320 tatsächlich typen haben das ist ja sozusagen dann auch so die eine api 19:53.320 --> 19:58.320 zumindest um wirklich naja mit css properties oder beziehungsweise deren 19:58.320 --> 20:03.320 werte tatsächlich in irgendwie einer geteibten weise verwenden zu können 20:03.320 --> 20:06.320 das ist ja normalerweise bei css nicht der fall das ist ja alles irgendwie einfach 20:06.320 --> 20:09.320 nur ein riesiger hoffen strings und die werden dann irgendwann innerhalb der 20:09.320 --> 20:13.320 css engine uminterpretiert dass irgendwie null eine zahl sein könnte oder 20:13.320 --> 20:16.320 irgendwie sieben pixel halt am ende tatsächlich irgendeine zahl in pixel 20:16.320 --> 20:21.320 bedeuten oder sieben am oder was auch immer und das macht halt ja eine ganze 20:21.320 --> 20:24.320 menge also nicht nur da halt eben diese interpolation für animation das ist 20:24.320 --> 20:26.320 halt eben das eine aber zum anderen macht es natürlich auch das programmieren 20:26.320 --> 20:30.320 viel einfacher wenn ich halt irgendwie mit javascript was abfragen kann irgendwie 20:30.320 --> 20:34.320 wie breit ist das ding und ich kriege halt eine information zurück wenn da der 20:34.320 --> 20:38.320 string drin steht irgendwie im 50 am dann kann ich damit ja exakt nichts 20:38.320 --> 20:41.320 anfangen ich müsste das element hier wirklich messen um damit an der ende 20:41.320 --> 20:45.320 irgendwas anzufangen oder manuell passen gottbeware jetzt kann mir der browser halt 20:45.320 --> 20:49.320 eben sagen das sind 50 und zwar in der einheit em und ich muss das nicht mehr 20:49.320 --> 20:54.320 manuell auseinander passen was so diverse css manipulationen natürlich 20:54.320 --> 20:59.320 einfacher bis überhaupt erst möglich macht ich hatte ja mal du unterhands hatte 20:59.320 --> 21:06.320 doch mal dieses projekt namens warhul und ich glaube da habt ihr da drauf ich glaube 21:06.320 --> 21:11.320 das ist dann das type css o.m. ne heißt das dann nope es war nicht das typed o.m. 21:11.320 --> 21:14.320 weil das ja keiner unterstützt hat okay aber der chrome hat es unterstützt 21:14.320 --> 21:19.320 damals schon aber das habt ihr trotzdem dann nicht genutzt weil es wäre halt 21:19.320 --> 21:23.320 keine universelle lösung gewesen der chrome hat das unterstützt ist jetzt 21:23.320 --> 21:26.320 eine sehr sehr freundliche auslegung dessen was der machen konnte also der konnte 21:26.320 --> 21:32.320 halt wirklich für ich glaube also zu dem zeitpunkt für ausschließlich measures 21:32.320 --> 21:36.320 also length konnte er das aber schon bei farben hat es halt auch aufgehört 21:36.320 --> 21:39.320 hatte der einfach keinen support für also ich konnte den abfragen mit dem type 21:39.320 --> 21:43.320 o.m. sag mal gibt mir mal hier irgendwie so die maße hat das gemacht wie ich 21:43.320 --> 21:47.320 gerade beschrieben habe das sind 50 einheiten und die einheit ist em okay 21:47.320 --> 21:51.320 wunderbar damit kann man arbeiten aber schon bei farben kam halt am ende 21:51.320 --> 21:56.320 so ein o.p.k. objekt raus wo man wirklich nur sagen konnte aha das ist halt ein 21:56.320 --> 21:59.320 o.p.k. objekt das repräsentiert irgendein wert und ich kann das ding 21:59.320 --> 22:02.320 stringifizieren bekommt dann also irgendwie ein hexadecimalen farbcode 22:02.320 --> 22:06.320 raus aber das ist mehr operation als stringifizieren gab es da nicht drin 22:06.320 --> 22:09.320 irgendwie so einfach komponente extra hier dann mal wieder bei unseren manuellen 22:09.320 --> 22:15.320 rumpasen das war wirklich finster damals ja weil weiß halt das ist ja immer 22:15.320 --> 22:19.320 noch finster ich gehe fest davon aus weil es ist halt einfach auch ein riesiges 22:19.320 --> 22:23.320 breit was da gebohrt wird das ist ja ja wieder so ein klassischer web 22:23.320 --> 22:27.320 entwicklungsproblem fall wo man irgendwie was vorhandenes hat es gibt 22:27.320 --> 22:31.320 css es gibt auch das cssom und es gibt code der sich darauf verlässt dass es 22:31.320 --> 22:35.320 funktioniert wie es halt eben schon immer war und jetzt muss man nachträglich 22:35.320 --> 22:39.320 eine low level api an das high level konstrukt dran flanschen womit man das 22:39.320 --> 22:43.320 high level konstrukt das css dann bedienen kann und das führt halt eben 22:43.320 --> 22:46.320 dazu dass das was halt eben danach gelagert kommt automatisch mit irgendwelcher 22:46.320 --> 22:51.320 legacy last belastet ist und ja oftmals auch nicht irgendwie intern konsistenz 22:51.320 --> 22:55.320 sein kann einfach weil die high level welt von der es abgeleitet ist ja schon 22:55.320 --> 22:59.320 in nicht in sich konsistent ist das kennt man ja aus webkomponens da kommt es ja 22:59.320 --> 23:03.320 darauf an wann das ding initialisiert wurde ob man dann irgendwie seinen kind 23:03.320 --> 23:06.320 inhalt sehen sehen kann oder ob der noch und definiert ist das wirkt sich dann 23:06.320 --> 23:09.320 halt eben auch bei css auf und das ist halt eben nicht implementiert wird oder dass 23:09.320 --> 23:13.320 die browser so langsam damit sind habe ich halt vollstes verständnis für weil 23:13.320 --> 23:17.320 mal ganz ehrlich das interessiert ja auch kaum jemanden also das hätte mir damals 23:17.320 --> 23:20.320 echt das leben sehr viel leichter gemacht und irgendwie alles viel toller 23:20.320 --> 23:26.320 gemacht und das sowas wie ad property ist super und das brauchen wir mit so ein bisschen 23:26.320 --> 23:29.320 air quotes aber das brauchen halt wir und ich glaube die meisten leute die halt 23:29.320 --> 23:33.320 einfach nur damit zu kämpfen haben dass ihre webseite einigermaßen konsistent 23:33.320 --> 23:38.320 aussehen soll den ist das weniger wichtig als irgendwie keine ahnung neuer css 23:38.320 --> 23:41.320 filter oder sowas damit kann man einfach mehr anfangen und ich glaube mehr 23:41.320 --> 23:47.320 leuten was gutes tun wäre halt zu meiner einschätzung der lage ja ich glaube 23:47.320 --> 23:55.320 genau es ist halt andererseits eine relativ niedrig hängende fruit also frucht 23:55.320 --> 24:04.320 weil im prinzip kennt css ja die typen schon also man musste jetzt eben quasi 24:04.320 --> 24:12.320 nur noch rein bauen dass dass das eben diese typen auch auf custom properties oder 24:12.320 --> 24:19.320 mit denen genutzt werden kann dieses typen das ist ja dann wieder was das steckt 24:19.320 --> 24:24.320 da zwar theoretisch auch irgendwie drin aber das ist halt wie du schon gesagt 24:24.320 --> 24:30.320 hast einfach ein dickeres brett und man kann halt schon nette sachen machen 24:30.320 --> 24:34.320 ich meine so speziell das typ system ich meine das ist ja am ende kein unterschied 24:34.320 --> 24:37.320 weil die typen die du halt auf normalen properties vorfindest auf irgendwie 24:37.320 --> 24:40.320 color und background position oder so sind ja am ende die gleichen typen die du 24:40.320 --> 24:47.320 auch verwendest für deine ad property regeln also das muss man dann ja da 24:47.320 --> 24:52.320 wo das andere gleich genau dazu genau genau aber es ist halt natürlich auch 24:52.320 --> 24:54.320 das vergrößert natürlich für die browser so die gesamte oberfläche von 24:54.320 --> 24:58.320 zeug dass man testen muss weil du hast dann ja neben dem alten css som ja auch 24:58.320 --> 25:03.320 typen muss alles getestet und supportet und gebackfixt werden macht es halt auch 25:03.320 --> 25:08.320 nicht einfacher nicht das stimmt ich meine wo wir schon mal dabei sind könnten 25:08.320 --> 25:13.320 wir eben auch noch erwähnen das ja vom typen auch eine ganze Menge kram in 25:13.320 --> 25:17.320 diesem technologie preview 161 auch aktiviert wird und das ist nicht nur 25:17.320 --> 25:22.320 ad property als spielt halt zusammen sondern auch das typen an sich wird hier 25:22.320 --> 25:25.320 enabled und eine ganze Menge dinge apis und so werden da unterstützt die sind 25:25.320 --> 25:31.320 dann da auch mit verfügbar ja ich würde mal interessieren also warum weil das 25:31.320 --> 25:38.320 ja viel arbeit ist was die dazu bewegt hat dieses typen zu implementieren 25:38.320 --> 25:44.320 weil ich weiß nicht ob die so diesen hudini weggehen wollen das glaube ich hier 25:44.320 --> 25:50.320 nicht also ich denke die sehen das auch wahrscheinlich eher so das paint api und 25:50.320 --> 25:56.320 layout api dass das alles irgendwie das aus denen wahrscheinlich nichts wird oder 25:56.320 --> 26:05.320 aber was der use case ist dass sie sagen keel des typen das brauchen die leute so 26:05.320 --> 26:11.320 hart dass wir das implementieren also ich mein sag ja so du willst einen eignen 26:11.320 --> 26:15.320 der will sein eigen effekt irgendwie eine webseite bauen wenn es hart auf hart 26:15.320 --> 26:19.320 kommt kannst du immer hingehen und kannst das kennenwisselement rausholen 26:19.320 --> 26:24.320 also du kriegst immer irgendwie deine pixel da auf den bildschirm das normale 26:24.320 --> 26:32.320 cssom ist so hart eingeschränkt das ist halt wirklich wirklich im prinzip also du 26:32.320 --> 26:36.320 kannst es behandeln als wäre es nicht da du kannst halt irgendwie so die style 26:36.320 --> 26:39.320 property von dem element setzen und du kannst wenn es hoch kommt irgendwie so 26:39.320 --> 26:42.320 über die style rule sind zum style sheet drüber iterieren aber wenn du 26:42.320 --> 26:46.320 irgendwas machen willst was auch nur minimal advance da ist als das mitjar 26:46.320 --> 26:51.320 was kript ist es halt wirklich ziemlich schwierig und du hast da wirklich so 26:51.320 --> 26:56.320 fälle wo einfach so gesagt werden muss sorry webentwickler geht halt nicht also 26:56.320 --> 26:59.320 ich sage dir mal ein beispiel du hast eine zusammengesetzte property wie 26:59.320 --> 27:02.320 background wo du halt eben color und background image und background position 27:02.320 --> 27:06.320 und so weiter alles reinschreibst und sobald du halt hingehst und du hast 27:06.320 --> 27:10.320 da eine normale css variable drin die ganz normale mit den zwei dashes und du 27:10.320 --> 27:15.320 baust in diese property rein dann ist allein das vorhandensein von so einer 27:15.320 --> 27:21.320 css variable schon so schon grund dafür dass wenn du abfragst hey was ist in 27:21.320 --> 27:24.320 die background position von diesem element dass du als antwort zurückbekommst 27:24.320 --> 27:28.320 den leeren string nicht unterscheidbar von das ist irgendwie auf zum beispiel 27:28.320 --> 27:31.320 den leeren string oder irgendwas anderes gibt ja CSS properties oder leere 27:31.320 --> 27:34.320 string erlaubt das background position ist ein schlechtes beispiel aber wo du 27:34.320 --> 27:38.320 halt den leeren string zurückbekommst warum weil du halt eine css variable 27:38.320 --> 27:42.320 irgendwo in die ganze background deklaration reingeschrieben hast dadurch 27:42.320 --> 27:46.320 weil das ja nur ein string replacement ist ist es für css nicht mehr nachvollziehbar 27:46.320 --> 27:51.320 ob man jetzt damit einen wert wie zum beispiel die background position 50 27:51.320 --> 27:54.320 prozent 50 prozent reingeschrieben hat oder die background position und die 27:54.320 --> 27:58.320 color oder ein element aus der background position also einer von den 27:58.320 --> 28:04.320 zwei zahlen oder oder oder also die custom property kann quasi für mehrere 28:04.320 --> 28:10.320 ja longhands longhand properties stehen gleichzeitig oder auch nicht genau 28:10.320 --> 28:13.320 nicht kann sondern könnte und allein weil sie weil es könnte kann dir das css um 28:13.320 --> 28:18.320 dann keine antwort mehr darauf geben was ist die background position und die ant 28:18.320 --> 28:21.320 der antwort die du bekommst ist halt nicht unterscheidbar in einigen umständen 28:21.320 --> 28:26.320 von ist nicht gesetzt ja und dann stehst du halt rum und versuchst halt 28:26.320 --> 28:29.320 rauszufinden wie die background position ist und die einzige antworte die dir 28:29.320 --> 28:32.320 halt eben gegeben werden kann ist das halt fundamental unmöglich das mit 28:32.320 --> 28:38.320 sicherheit rauszufinden und das ist schon hart schwach genau wobei kannst du das 28:38.320 --> 28:46.320 denn nicht was ist denn mit get computed style ist das also nicht den computer 28:46.320 --> 28:50.320 nicht den computer style haben willst weil du zum beispiel sowas baust du halt die 28:50.320 --> 28:54.320 css deklaration also tatsächlich den input vergleichen möchtest hat das 28:54.320 --> 29:00.320 ding als background position wirklich gesetzt bekommen keine ahnung 4 em 50 29:00.320 --> 29:05.320 rem mal so als beispiel weil du ja mit dem css interagieren willst die 29:05.320 --> 29:10.320 computer styles sind ja am ende die tatsächlich realisierten ich weiß 29:10.320 --> 29:13.320 jetzt gerade den spezifikations nicht mehr begriff nicht mehr aber es gibt ja 29:13.320 --> 29:15.320 die computer styles sind dann nachher kommt ja die wirkliche wirkliche 29:15.320 --> 29:19.320 wahrheit also wie es wirklich am ende umgesetzt und ausgerechnet ist das 29:19.320 --> 29:23.320 kriegste immer raus mit eben get computed style aber halt nicht wie du 29:23.320 --> 29:26.320 dahin gekommen bist und wenn du das wissen willst dann ist halt Schluss und 29:26.320 --> 29:30.320 das ist ja eigentlich css der weg zu den computer styles die computer styles sind 29:30.320 --> 29:39.320 ja nur das ergebnis vom css das war echt ein war echt also ist ja nichts 29:39.320 --> 29:43.320 geworden weil aus einer reihe von gründen aber meine fresse ich habe so viel 29:43.320 --> 29:48.320 gelernt und wenn ich eins sagen kann das alte css um hat fast ich nie wieder an 29:48.320 --> 29:52.320 das habe ich gelernt das hast du auf hier für den podcast eigentlich gemacht 29:52.320 --> 29:57.320 damit du damit du uns davon erzählen kannst so sieht es nämlich aus alles für 29:57.320 --> 30:03.320 das publikum aber hier ein habe ich noch eine frage hätte ich noch zu diesen 30:03.320 --> 30:09.320 css custom property zeug das woran ich gerade arbeite macht eine ganze 30:09.320 --> 30:13.320 Menge css generieren also wirklich ganz ganz viel mit ganz ganz vielen 30:13.320 --> 30:19.320 komplizierten kalke war geschichten und sowas und ich fühle mich ja ein bisschen 30:19.320 --> 30:23.320 gebissen mittlerweile davon dass css ja keine sonntags oder runtime erbos mir 30:23.320 --> 30:29.320 durchgibt also ich lade meine webseite neu und das sieht halt nicht aus wie es 30:29.320 --> 30:34.320 so aussehen soll und im idealfall merke ich das im schlimmsten fall nicht ist 30:34.320 --> 30:37.320 das eigentlich noch angemessen also ich meine das verhalten dass es weiter 30:37.320 --> 30:41.320 funktioniert ist korrekt weil das ist wie css funktioniert progressive enhancement 30:41.320 --> 30:48.320 etc das soll so bleiben aber sollte nicht irgendwie eine ungültige css 30:48.320 --> 30:51.320 konstruktion uns mittlerweile mal gemeldet wird und ich meine jetzt halt 30:51.320 --> 30:55.320 nicht irgendwie so ein css validator den ich über meinen style sheet meine css 30:55.320 --> 30:58.320 darüber laufen lassen kann weil wenn ich mit javascript irgendwelches css 30:58.320 --> 31:02.320 generiere was ich halt eben gerade tue da nutzt mir das nicht ich will ja wissen 31:02.320 --> 31:05.320 was das was ich den browser zu essen gebe ob das tatsächlich noch irgendwelche 31:05.320 --> 31:10.320 gültigkeits anforderungen erfüllt gibt es da was oder sollte es das geben oder 31:10.320 --> 31:17.320 ist das käse spinnig also ich glaube das ist ja so zumindest in firefox da 31:17.320 --> 31:23.820 bekommst du ja so was sind das so notifications auf der konsole wenn du 31:23.820 --> 31:32.320 irgendwie also zumindest teilweise wenn du so mumpits werte setzt glaube ich aber 31:32.320 --> 31:39.320 das ist halt nix was du per javascript glaube ich abgreifen kannst also das 31:39.320 --> 31:43.020 müsste ich gar nicht haben aber zum beispiel irgendwie so ich hatte halt mal so 31:43.020 --> 31:46.840 ein brainfahrt wo ich irgendwie so kalk eine einwert mit einheit geteilt durch 31:46.840 --> 31:50.880 anderen wert mit einheit gemacht habe was halt offensichtlich nicht geht weil 31:50.880 --> 31:55.120 ergibt ja keinen sinn so aber was passiert halt die ganze expression ist 31:55.120 --> 31:58.520 halt eben einfach nur wird nicht evaluiert er liefert kein ergebnis 31:58.520 --> 32:04.120 funktioniert nicht was ist wenn du das in css punkt supports reinsteckst und 32:04.120 --> 32:09.360 guckst was also was da auskommt also ich meine dann du würdest es dann missbrauchen 32:09.360 --> 32:17.840 für was jetzt genau also wie würde ich das machen naja du kannst ja ich weiß 32:17.840 --> 32:23.840 nicht ob das ob das ob dann falls so came aber wenn du da eben einen ungültige 32:23.840 --> 32:32.840 deklaration reinsteckst also ich meine das müsste funktionieren aber wie 32:32.840 --> 32:36.800 implementiere ich das denn also ich generiere meinen javascript string mit 32:36.800 --> 32:41.780 50.000 css regeln drin und ich will mitbekommen wenn das nicht funktioniert 32:41.780 --> 32:46.520 möglicher im idealfall nicht nur mit deine 50.000 zeilen sind kaputt sondern 32:46.520 --> 32:52.560 in dieser stelle ist es halt eben suboptimal dieser kalkausdruck den du 32:52.560 --> 32:58.840 da gebaut hast der geht nicht ja schwierig wüsste jetzt auch nicht also 32:58.840 --> 33:04.800 ich glaube also teilweise kannst du es halt noch in den dev tools sehen also da 33:04.800 --> 33:09.360 gibt es jetzt auch immer mehr solche dass du so anmerkungen bekommst nach dem 33:09.360 --> 33:17.400 auto hier wenn du quasi diese property oder das so setzt dann funktioniert 33:17.400 --> 33:21.680 sagen wir mal float nicht mehr oder sowas also dann so hier dein float ist 33:21.680 --> 33:30.840 kaputt weil du hast im parent container display flex gemacht oder so ja genau 33:30.840 --> 33:35.400 das ist ja auch nicht das was du willst und das funktioniert ja auch nur für 33:35.400 --> 33:39.880 bestimmte dinge ja es ist ja auch das ist ja auch mehr so ein das ist ja mehr 33:39.880 --> 33:44.120 so situational awareness so das ist irgendwie so weißt du dieses ding im 33:44.120 --> 33:48.880 flugzeug was der sagt pull up terrain wenn du auf dem berg zu fliegst ja ich 33:48.880 --> 33:52.640 hätte jetzt mehr gern so mehr gern so ein ikam output wo halt so drin steht das 33:52.640 --> 33:57.400 und das ist gerade kaputt an deinem gerät und ich kann dir genau sagen welches 33:57.400 --> 34:04.480 teil das jetzt ist ja und was ist hier mit steilend also jetzt mal irgendwie 34:04.480 --> 34:08.520 ungeachtet dessen ob du das jetzt wie du das da bei dir im projekt jetzt genau 34:08.520 --> 34:14.960 verbaut aber das macht sowas auch ja aber ist halt die frage ob der den 34:14.960 --> 34:18.160 ganzen layers of interaction folgen kann also stell dir vor ich habe einen 34:18.160 --> 34:23.320 kalkausdruck war eins geteilt durch war zwei und in war zwei ist eine einheit 34:23.320 --> 34:29.200 drin das kann der auch gar nicht weil das ja von deiner domstruktur abhängt 34:29.200 --> 34:33.600 auch ja genau aber ich meine am ende sind wir ja bei deinen computer styles von 34:33.600 --> 34:39.240 vorhin irgendwann kommt halt die wahrheit zu tage und dann müsste finde ich 34:39.240 --> 34:44.160 müsste es einen reporting mechanismus geben der da sagt dieses css hier das 34:44.160 --> 34:47.200 funktioniert so nicht und sei es halt nur dass mir die deklaration genannt wird 34:47.200 --> 34:51.160 muss ja nicht mal irgendwie so eine super genaue diagnostik sein von wegen der 34:51.160 --> 34:54.600 spezifischen fehler kalk geteilt durch element mit einheit funktioniert nicht 34:54.600 --> 35:00.680 sondern einfach nur mehr als einfach still scheitern so was halt auch ein 35:00.680 --> 35:03.560 bisschen schwierig ist weil du willst ja progressive enhancement haben aber das 35:03.560 --> 35:07.160 ist ja wahrscheinlich ein kategorie fehler zu sagen unbekannte property oder 35:07.160 --> 35:10.960 unbekannter value versus ich weiß was du versuchst zu machen aber das 35:10.960 --> 35:15.920 funktioniert nicht und hier ist die meldung die dich dahin weist also mit 35:15.920 --> 35:19.040 dieser immer weiter steigenden komplexität von css mit property und 35:19.040 --> 35:23.120 hudini und hast du nicht gesehen wäre es glaube ich mal an der zeit dass die 35:23.120 --> 35:26.120 devtools nicht einfach nur aufrüsten mit neuen buttons die man anklicken kann so 35:26.120 --> 35:29.640 und wirklich mit solchen reporting mechanismen wie immer die auch aussehen 35:29.640 --> 35:33.440 ich bin da halt nur persönlich gerade von gebissen deswegen klar war das so in 35:33.440 --> 35:39.080 meinem kopf herum also tatsächlich ist es ist es ja so dass die ich glaube dass die 35:39.080 --> 35:44.840 devtool machen der verschiedenen browser auch total interessiert sind an solchen 35:44.840 --> 35:49.480 Dingen also weil immer wenn ich mal welche getroffen habe und mich mit den 35:49.480 --> 35:54.480 unterhalten habe und dann eben auch gesagt habe so so im css Bereich zum 35:54.480 --> 36:00.720 Beispiel es wäre halt einfach cool wenn die devtools ein darauf hinweisen würden 36:00.720 --> 36:08.200 dass man bestimmte dinge implizit quasi auslöst durch das explizite setzen 36:08.200 --> 36:12.480 bestimmter properties also da kommt ja dann je nachdem was man da benutzt 36:12.480 --> 36:15.320 kommen ja noch so ein paar sachen im gepack wie zum beispiel ist an eben 36:15.320 --> 36:22.840 floats nicht gehen und so da gibt es ja noch ganz ganz viel mehr und so was finde 36:22.840 --> 36:29.160 ich halt einfach total total gut und die sind da auch absolut interessiert dran 36:29.160 --> 36:36.800 deswegen also musst du da einfach nur den den case für machen und und dann 36:36.800 --> 36:41.120 dass die richtigen leuten einfach schicken und also ich glaube dass die 36:41.120 --> 36:45.720 schon offen wären für sowas und ich finde das jetzt auch tatsächlich sinnvoll 36:45.720 --> 36:50.680 ich glaube aber dass ich glaube es ist mehr als nur den case machen also ich 36:50.680 --> 36:53.880 glaube es lässt sich relativ leicht fordern so wie ich jetzt hier sitze 36:53.880 --> 37:02.000 damit man ja viele also warum sollst du es nicht auch machen und dann ja das 37:02.000 --> 37:05.360 ist ja ein bisschen mühe geben da ist vielleicht auch die chancen einigermaßen 37:05.360 --> 37:10.760 ernst genommen zu werden ja das müsste ich ja tun weil sonst würde ich ja 37:10.760 --> 37:17.720 aussehen wie ein vollhuhn ganz genau ja und vielleicht kann man ja sowas zumindest 37:17.720 --> 37:20.480 mal sowas mit so einer stylend implementierung ja zumindest mal prototypen 37:20.480 --> 37:23.440 dass man so eine browser extension schreibt und irgendwie so sagt das macht 37:23.440 --> 37:27.200 nicht was ich will es macht irgendwie nur so 30 prozent von dem aber event 37:27.200 --> 37:31.440 100 prozent von dem machen würde was ich gerne hätte siehe text dann könnte 37:31.440 --> 37:35.120 das so sein und dann wäre das vielleicht nützlich ja ja genau also ein 37:35.120 --> 37:39.160 browser extension baut es natürlich auch immer super dass er dann auch je nach 37:39.160 --> 37:42.800 dem was also wie beliebt die dann ist und was für einen uptake die hat oder was 37:42.800 --> 37:46.880 die leute darauf eben für ein feedback geben ist natürlich für die browser 37:46.880 --> 37:52.600 mache dann auch noch mal so ein ding wo die dann sehen können hey das finden 37:52.600 --> 37:56.920 schon viele leute gut oder es interessiert kann sau kann ja auch sein und 37:56.920 --> 38:01.640 dann sparen wir uns die arbeit und machen lieber andere dinge 38:01.640 --> 38:05.840 ja okay dann habe ich also jetzt hausaufgaben wunderbar ja aber finde ich 38:05.840 --> 38:13.760 gut bescheid wenn du das wenn du da irgendwie was hast dann würde ich da 38:13.760 --> 38:19.280 auch die werbetrommel rühren für okay das ist das ist ein deal das machen wir 38:19.280 --> 38:27.800 so genau dann haben wir hier wir haben dann sind ein paar fixes für die hess 38:27.800 --> 38:34.120 pseudo klasse da nehme ich an wird sowieso noch immer wieder was geben das 38:34.120 --> 38:37.400 hat war gab es auch im chrome browser ganz am anfang als die has freigeschaltet 38:37.400 --> 38:43.840 haben die das diesen invalidierungsproblemen öfters mal haben weil 38:43.840 --> 38:51.680 hess ja quasi die die richtung umkehrt in die dinge irgendwie ablaufen und das 38:51.680 --> 38:56.600 wird halt gecached damit sie eben auch nicht zu zu viel compute time braucht wenn 38:56.600 --> 39:02.200 irgendwie neue elemente insettiert werden so genau und da gibt es gibt es 39:02.200 --> 39:08.000 einfach cash invalidierungsprobleme immer mal wieder da werden wir glaube ich 39:08.000 --> 39:13.480 auch in in den nächsten releases aller möglichen browser immer wieder so was 39:13.480 --> 39:17.320 sehen wo die dann das dann eben einfangen diese 39:17.320 --> 39:22.040 probleme es ist fast so ein bisschen wie als würde hätte das gestimmt was die 39:22.040 --> 39:25.120 die gesagt haben so was wie hess kannst du nicht machen als hätten die so ein 39:25.120 --> 39:29.280 bisschen recht gehabt also weil es halt mit der normalen zers selektor abbilden 39:29.280 --> 39:32.240 mit dem normalen zers selektor mechanismus nicht funktioniert sondern halt 39:32.240 --> 39:36.400 eben sein eigenes spezialreich werden muss macht man sich da ja schon ne 39:36.400 --> 39:41.800 ganze haufen von schwierigkeiten auf die man sonst nicht hätte andererseits 39:41.800 --> 39:45.600 jetzt hören sie wenigstens auf zu fordern die da sagen sowas wie hess muss 39:45.600 --> 39:53.120 existieren ja ich ja genau also ich finde das ist auf jeden fall schon jetzt 39:53.120 --> 40:00.560 gut genug umgesetzt und gelöst tatsächlich ist es auch so dass das 40:00.560 --> 40:07.520 hess schon einen höheren impact hat so auf das ganze selektor matching ich hatte 40:07.520 --> 40:14.480 nämlich die dieses chrome tracing also dieses interne selektor matching 40:14.480 --> 40:18.440 tracing hatte ich mal auf mein aktuelles projekt angewendet und was kann da 40:18.440 --> 40:24.200 relativ weit oben raus in der tat glaube der ein oder die paar selektoren wo ich 40:24.200 --> 40:29.840 hess verwendet hatte ja liegt halt auf der hand also es wird zwar gecash und so 40:29.840 --> 40:34.600 aber es ist halt einfach für den browser schon deutlich komplexer und du musst 40:34.600 --> 40:38.080 es halt trotzdem irgendwann ja zum ersten mal ausrechnen nützt ja nichts ja 40:38.080 --> 40:48.880 genau also ist der ist ist der impact messbar oder ist ja auch spürbar es 40:48.880 --> 40:53.120 gibt ja diese wenn du leithaus laufen lässt dann gibt es ja immer so dieses 40:53.120 --> 40:58.440 das leithaus bemängelt hey du hast mehr als ich weiß nicht was die grenze 40:58.440 --> 41:04.520 nochmal war 2000 dom notes oder so verwendet und genau das ist ein akuten 41:04.520 --> 41:11.800 fall von reakt ganz schlimm vielleicht vielleicht genau und das liegt eben 41:11.800 --> 41:19.760 daran dass die style calculation oder recalc prozess dann einfach sehr lange 41:19.760 --> 41:25.600 dauert oder das auch der initiale weil eben diese ganzen elemente durchlaufen 41:25.600 --> 41:31.400 diese ganzen selektoren und je nachdem wie diese lektoren aufgebaut sind kann man 41:31.400 --> 41:35.280 das relativ schnell entscheiden dass irgendwie ein element nicht auf diesen 41:35.280 --> 41:40.880 selektor trifft zutrifft oder eben nicht und bei hess ist es natürlich dann 41:40.880 --> 41:48.040 aufwendiger und je je mehr man sein dom auch dann nachträglich noch ändert 41:48.040 --> 41:55.760 desto mehr recalcs löst man aus und es ist im prinzip am enden ein produkt aus 41:55.760 --> 42:05.240 anzahl dom notes und selektor also und da kann kann schon da können einige 42:05.240 --> 42:09.760 hundert mil sekunden sich zusammen leppern wenn man pech hat und das sind 42:09.760 --> 42:17.200 dann wieder so werte die die dann eine rolle spielen in core web vital 42:17.200 --> 42:25.720 zeiten genau und was auch cool ist ist das der also jetzt das dann nicht webkit 42:25.720 --> 42:36.400 sondern die menschen haben diese dieses selektor matching tracing haben die 42:36.400 --> 42:42.360 quasi rausgeholt aus diesem das ist eigentlich so ein interner bereich von 42:42.360 --> 42:45.640 den browser von den chromium browser haben die das in die dev tools geholt mit 42:45.640 --> 42:50.800 der neuesten version normalerweise in diesen profiling crempel drin oder ist 42:50.800 --> 42:55.240 das noch tiefer drin in den nicht in profilding drin also dann machst du dann 42:55.240 --> 43:00.320 da gibt es dann oben einen chromedrop und dann ich glaube tracing und dann 43:00.320 --> 43:06.200 gibt es da dann wird das user interface auch ein bisschen rudimentär genau den 43:06.200 --> 43:10.120 meinte ich eigentlich genau dann hast du hast ja so ganz viele verschiedene 43:10.120 --> 43:14.680 dinge die du da treiben und tracen kannst genau die benutzerfreundlichkeit ist 43:14.680 --> 43:22.040 halt dann einfach völlig weg und das haben die eben in benutzerfreundlich 43:22.040 --> 43:31.720 jetzt nach vorne in die dev tools reingehieft sehr cool genau das ist auf 43:31.720 --> 43:39.200 jeden fall cool was auch cool ist wenn ich überleiten darf ein bisschen neuer 43:39.200 --> 43:43.760 css support auch jetzt hier in der technologie preview in user invalid und 43:43.760 --> 43:51.560 user valid das ist das ist halt eben das was invalid und valid ursprünglich mal 43:51.560 --> 43:57.400 sein wollten aber das ist so ein bisschen ja wie hier pseudo klasse empty 43:57.400 --> 44:02.120 geworden erst auf niemals das implementieren was man sich halt was 44:02.120 --> 44:05.400 einem so die als erste idee in den kopf kommt ist immer eine schlechte idee ist 44:05.400 --> 44:08.040 halt blöd wenn man webstandards macht und man den geist nie wieder in die 44:08.040 --> 44:12.680 flasche bekommt aber ja also das sind die css pseudo klassen für ungültige 44:12.680 --> 44:16.680 formularelemente die erst dann in den ungültig oder gültig zustand 44:16.680 --> 44:20.600 wechseln wenn einmal eine nutzer interaktion stattgefunden hat man macht 44:20.600 --> 44:24.840 das formulare auf und das ist nicht gleich von Anfang an alles rot also das 44:24.840 --> 44:28.760 heißt man war einmal drin oder ich glaube wenn man das formulare abgeschickt hat 44:28.760 --> 44:32.480 dann gilt das eben also wenn man den sub mitknopf drückt dann ist das quasi wird 44:32.480 --> 44:39.920 das auch aktiviert genau ja ich weiß gar nicht wie der browser support da 44:39.920 --> 44:46.640 aussieht ich glaube der ist mittlerweile auch wird langsam gut ich wollte sagen 44:46.640 --> 44:53.360 schalte das sei gar nicht so schlecht ich hätte es auch heute schon nachgeschaut 44:53.360 --> 45:04.880 dann wollen wir uns noch nicht zu früh freuen aber es ist auf jeden fall gut 45:04.880 --> 45:09.600 schon mal ein einbrowser mehr das ist ja nicht so dass sie da bei chrome jetzt 45:09.600 --> 45:14.560 nicht ressourcen hätten um darauf mal zu reagieren und ja es ist auch schon ich 45:14.560 --> 45:17.200 habe mich gerade in den chrome back angeschaut da wird auch überall schon 45:17.200 --> 45:21.200 fleißig kommentiert firefox kann das schon ewigkeiten und euren kommentar 45:21.200 --> 45:26.440 dass das in den webkit tree hinein gemirkt wurde es wird also bereits schön 45:26.440 --> 45:29.880 druck gemacht ja ich würde sagen das ist so von den 45:29.880 --> 45:37.120 sachen die jetzt in der tech preview 161 so drin ist so die interessanteste 45:37.120 --> 45:47.600 neuerung es gibt so stroke dash array und und marker zeugs und font krempel aber 45:47.600 --> 45:54.200 die sind alle so sind okay aber fetzen jetzt nicht so betreffen mich jetzt auch 45:54.200 --> 45:57.760 nicht besonders also ich würde vielleicht noch erwähnen so aus dem 45:57.760 --> 46:02.000 davaskript umfeld ist halt look behind the surgeons in regulären ausdrücken 46:02.000 --> 46:08.160 nicht verkehrt man es braucht wenn man es haben und jetzt so mein persönliches 46:08.160 --> 46:13.680 mein persönliches today i learned wars der resizable array buffer den gibt es 46:13.680 --> 46:20.640 zwar noch nicht aber der ist tatsächlich schon stage 3 bei tc 39 das ist 46:20.640 --> 46:22.920 schon mal nicht schlecht also manchmal sich manuell irgendwie so einen 46:22.920 --> 46:26.120 resizable array buffer kann man sich ja nicht bauen man muss ja im prinzip dann 46:26.120 --> 46:29.760 einen neuen array buffer bauen mit einer neuen größe und dem alten inhalt oder 46:29.760 --> 46:34.560 irgendwie so krams extrem mühsam und sowas in resizable zu haben ist schon 46:34.560 --> 46:38.240 nicht schlecht ja wie gesagt ist noch kein fertiger standard und kann noch fast 46:38.240 --> 46:41.560 keiner aber zumindest haben wir auch jetzt endlich mal eine implementierung die 46:41.560 --> 46:46.600 das supportet finde ich gut das ist mal das das ist auch was dass ich 46:46.600 --> 46:53.360 wahrscheinlich weiß gar nicht wann ich sie brauchen werde jemals aber das ist 46:53.360 --> 46:59.560 dann was ist das von ja genau ja also ich hatte das halt eben im Einsatz als ich 46:59.560 --> 47:07.080 mal gif animation bauen wollte und muss man ja also man hat irgendwie dann so 47:07.080 --> 47:10.560 eine pixel daten irgendwie rgb-werte und man muss dann ja am ende eine palette 47:10.560 --> 47:16.880 raus machen man muss das ja irgendwie auf die 256 farben runter kochen und was 47:16.880 --> 47:19.440 machst du wenn du halt eben einfach nur das schnell und dreckig hin bauen willst 47:19.440 --> 47:22.360 dann nimmst du halt eben deine gesamten frames die du in dieses gif in 47:22.360 --> 47:27.520 nine füttern wirst also all diese ganzen rgb pixel arrays und konkartinierst 47:27.520 --> 47:30.280 sie einfach in einen riesigen area buffer und schiebst den dann in den 47:30.280 --> 47:33.160 entsprechenden prozess und plus den in ein webwalker und dann braucht das zwar 47:33.160 --> 47:37.080 eine sekunde aber das macht ja nichts das sieht ja nicht so oft aber dann halt 47:37.080 --> 47:40.240 eben so eine funktion zu bauen die halt wirklich area buffer konkarteniert ist 47:40.240 --> 47:42.920 erstaunlicherweise nicht ganz so trivial weil man kriegt ja normalerweise auch 47:42.920 --> 47:45.440 keine area buffer angereicht sondern halt irgendwie so diese ganzen komischen 47:45.440 --> 47:50.440 subtypen irgendwie uint irgendwas array und dann muss man sich da halt eben 47:50.440 --> 47:53.760 einen ein zu recht abbrechen wenn man das halt irgendwie generalisiert haben 47:53.760 --> 47:57.360 möchte und stellt sich raus wird in zukunft nicht mehr ganz so schmerzhaft 47:57.360 --> 48:04.320 sein cool genau ansonsten hätte ich noch was ich hier weiter unten noch seh 48:04.320 --> 48:09.720 ist dass es die offscreen canvas jetzt gibt das finde ich glaube ich auch ganz 48:09.720 --> 48:17.640 gut weil klau die ist das am prinzip eine canvas die man im webwalker benutzen 48:17.640 --> 48:21.960 kann oder genau das ist es offscreen canvas also canvas element macht ja 48:21.960 --> 48:26.760 normalerweise pixel auf dem bildschirm außer wenn man das nicht haben will und 48:26.760 --> 48:30.000 also warum würde man das nicht haben wollen man würde das nicht haben wollen 48:30.000 --> 48:33.760 wenn man einfach nur pixel daten im sinn meiner gerade genannten rgb r arrays 48:33.760 --> 48:38.360 erzeugen möchte oder halt einfach auch nur irgendwelche dinge bauen möchte die 48:38.360 --> 48:41.800 überhaupt gar nichts mit rendering zu tun haben also ich will das bild invertieren 48:41.800 --> 48:45.320 und abspeichern aber ich will zu keinem zeitpunkt anzeigen dann gibt es ja 48:45.320 --> 48:48.280 kein gut die canvas anzuzeigen wenn es keinen grund sie gibt sie anzuzeigen 48:48.280 --> 48:51.560 dann kann man sie auch im webwalker haben außer halt eben kann man halt 48:51.560 --> 48:54.440 tatsächlich nicht weil der webwalker dann sagt nee könnt ihr angezeigt werden 48:54.440 --> 48:57.560 wollen und dann geht das bei mir nicht und die offscreen canvas macht es halt eben 48:57.560 --> 49:02.600 dann in einem nicht sichtbaren prozess möglich super sache ja auch so zum 49:02.600 --> 49:07.040 beispiel bild upload wo man dann noch auf dem gerät zum beispiel das bild 49:07.040 --> 49:10.920 quasi klein resize damit der upload eben einfach schneller geht 49:10.920 --> 49:15.400 genau mega pixel zahlen die man heutzutage so ein smartphones hat das 49:15.400 --> 49:22.040 kann man dann auch prima an ein webwalker wegdelegieren oder qr code 49:22.040 --> 49:28.040 auslesen oder dekodieren oder so zeugs ja wenn man übrigens möchte dass das 49:28.040 --> 49:31.720 einigermaßen flott geht heutzutage schon und man keine offscreen canvas hat und 49:31.720 --> 49:36.360 keinen dat worker haben möchte habe ich letztens folgendes rausgefunden das ist 49:36.360 --> 49:40.560 jetzt eine preview auf dem blog post nicht morgen veröffentliche aber es begab 49:40.560 --> 49:43.240 sich so zu der zeit dass ich so zu irgendwie so zu dem hinking und dachte 49:43.240 --> 49:45.520 so hey hast du gerade irgendwelche dringenden browser probleme ich habe 49:45.520 --> 49:49.320 gerade nichts dringendes zu tun und er so ja irgendwie auf meinen neuen laptops in 49:49.320 --> 49:54.720 der firma da werden manche von unseren pdf nicht richtig angezeigt aber nur wenn 49:54.720 --> 49:59.360 die hartweilbeschleunigung an ist so richtig schöner fall von montas geht 49:59.360 --> 50:04.880 der drucker nicht stellt sich also raus liegt halt eben an einem rendering bug in 50:04.880 --> 50:09.000 der engine von chrome beziehungsweise in deren fall in der großen firma war das 50:09.000 --> 50:13.280 etch und der sorgt halt eben dafür dass wenn dann in den pdfs bestimmte font 50:13.280 --> 50:16.040 metriken nicht oder nicht hin richtig hinterlegt sind oder da irgendwelche 50:16.040 --> 50:19.760 rundungsfehler auftauchen bei bestimmten grafiktreibern ist dann dazu führt dass 50:19.760 --> 50:22.480 irgendwie pixel fehlen die buchstaben ineinander laufen und generell alles 50:22.480 --> 50:26.080 aussieht als wäre es schon mal gegessen und die richtige lösung wäre halt eben 50:26.080 --> 50:29.040 gewesen updater halt alle eine pdf in deiner firma ja wird halt nicht 50:29.040 --> 50:32.920 passieren oder halt eben schalte auf allen geräten die hartweilbeschleunigung 50:32.920 --> 50:36.200 aus fast natürlich jetzt so aus der perspektive von meiner kleinen 50:36.200 --> 50:38.960 unterabteilung einer unterabteilung einer webentwicklungsabteilung in einem 50:38.960 --> 50:43.720 riesigen konzern leichter gesagt ist als zu tun also da irgendwie zu den admins 50:43.720 --> 50:46.600 hinzugehen und zu sagen machen wir hier für alle devices diese entsprechende 50:46.600 --> 50:51.160 admin richtlinie da in windows an ist halt zumindest keine dauerlösung weil man 50:51.160 --> 50:55.520 denen halt auch nicht weiter trauen kann als man sie werfen kann und da stellt sich 50:55.520 --> 50:59.200 halt raus hartweilbeschleunigung kann man tatsächlich auf der pro kenvis 50:59.200 --> 51:03.160 eben abschalten und das würde man machen wollen wenn man genauso kram machen 51:03.160 --> 51:05.640 möchte wie das was du gerade beschrieben hast chap weil normalerweise 51:05.640 --> 51:10.000 hartweilbeschleunigung ja gut ist für schnellsachen rendern aber dazu musst du 51:10.000 --> 51:14.360 sie erst mal zu deiner gpu rüber schicken und wenn du viel so tinge machst wie ich 51:14.360 --> 51:18.400 will eigentlich nur irgendwie ein qr code mir auslesen oder irgendwie ein 51:18.400 --> 51:22.480 build resize oder so wenn ich also niemals was anzeigen möchte ist das ja 51:22.480 --> 51:25.640 nicht nötig dann kann ich ja auf der cpu bleiben aber dazu muss ich ja mein 51:25.640 --> 51:29.320 kenvis element sagen können du brauchst nicht hartweilbeschleunigung zu werden 51:29.320 --> 51:33.520 und das geht tatsächlich über so ein flag wenn man sich ein 2d kontext holt 51:33.520 --> 51:38.440 der einfach heißt will read frequently weil man halt eben da sehr viele 51:38.440 --> 51:41.960 readback operationen im sinne von gib mir die pixel macht und dadurch erzwingt 51:41.960 --> 51:45.640 man im prinzip softwarebeschleunigung wodurch dann so use cases wie von dir 51:45.640 --> 51:49.160 gerade beschrieben schneller werden oder jetzt in meinem fall für die leute mit 51:49.160 --> 51:52.760 dem kaputten laptop ich einfach sagen konnte bau diese drei zahlen javascript 51:52.760 --> 51:57.280 ein die patchen kenvis 2d kontext prototype blablabla die machen halt die 51:57.280 --> 52:01.440 get-context-methode so dass die immer will read frequently auf schuhe hat okay 52:01.440 --> 52:04.880 die erst werden dann korrekt wenn auch langsamer gerendert und zeigt war das 52:04.880 --> 52:10.600 problem gegessen ja cool also das ist sehr cool vor allen Dingen steht in den 52:10.600 --> 52:16.320 spezifikationen drin so dieser fleck sagt im browser dass er optimieren soll 52:16.320 --> 52:21.280 dahingehend das oft readback stattfinden da steht nicht drin dass das die 52:21.280 --> 52:25.720 hardwarebeschleunigung ausmacht das würde ja das wäre jetzt ja auch nicht speck 52:25.720 --> 52:32.440 konform die wollen ja immer sozusagen so wenig implementations details eigentlich 52:32.440 --> 52:37.840 liefern wie möglich nur so viel wie nötig genau aber es kreuzt runter kommt 52:37.840 --> 52:41.160 direkt nach dem diesen nach diesem satz wohl halt drin steht blablabla optimiert 52:41.160 --> 52:44.160 für readback operation kommt so ein nicht normativer einschub wo drin steht 52:44.160 --> 52:49.440 ganz im vertrauen in erster für das software rendering erzwingen und so 52:49.440 --> 52:52.440 weiß man dann und auch bei mdn steht so drin dass das dann funktioniert mehr 52:52.440 --> 52:55.520 mehr details haben möchte schaut in mein block da steht das in länger mal 52:55.520 --> 53:00.760 breiter mit code noch mal drin ja cool das merke ich mir auch mal das werde 53:00.760 --> 53:04.200 ich bestimmt mal brauchen das ist super und vor allen 53:04.200 --> 53:07.680 chromen meckert halt auch also wenn du eine normale canvas hast wo du das nicht 53:07.680 --> 53:11.880 aktivierst und du machst irgendwie dreimal nacheinander irgendwie get image data 53:11.880 --> 53:14.760 dann kriegst du doch tatsächlich so eine warning die da sagt sagen wir willst 53:14.760 --> 53:19.680 eventuell diese option anmachen okay ja so eine art warning wie du sie oder 53:19.680 --> 53:25.320 hinweis wie man es also so eine hatte ich eben auch im sinn als ich meinte der 53:25.320 --> 53:30.360 firefox sagt sowas bringt sowas auf der konsole wenn man da irgendwie falsches 53:30.360 --> 53:37.080 css anwendet genau oder halt oder hier so eine passive events bei scroll und 53:37.080 --> 53:45.880 zu zeug ja sowas ist doch cool ja mega total genau ich glaube damit sind wir 53:45.880 --> 53:53.760 aber mit dem tag preview 161 durch aber wenn man auch den 162er das sind 53:53.760 --> 53:57.400 auch noch ein paar gute sachen dann soll man sie noch schnell schnappen das 53:57.400 --> 53:59.800 machen wir ich habe da auch ein paar weniger notizen drin als ich jetzt für 53:59.800 --> 54:06.400 den 161er hatte genau also was ich da gelernt habe ist dass es eine margin 54:06.400 --> 54:10.920 trim css eigenschaft gibt und ich noch nicht gehört habe die ich natürlich 54:10.920 --> 54:17.160 dann mal nach gucken musste genau ich hatte eigentlich gedacht so dass es 54:17.160 --> 54:23.040 dafür da ist es so quasi so so margins die aus elementen herausragen dann 54:23.040 --> 54:28.920 quasi abschneiden kannst zumindest lang margin trim so aber das dem dem ist 54:28.920 --> 54:37.200 nicht so es ist eher zu verstehen wie bei dem wie bei javascript string trim also 54:37.200 --> 54:47.320 das wenn du zum beispiel in einem container in line elemente hast und um und 54:47.320 --> 54:51.000 du abstand zwischen denen haben möchtest also in line block elemente zum 54:51.000 --> 54:58.920 beispiel und würdest jedem einen margin write geben dann kann es ja sein dass eins 54:58.920 --> 55:05.440 von denen ganz am ende der zeit landet mit dem margin den du da vielleicht gar 55:05.440 --> 55:11.280 nicht haben willst genau und du kannst dann diese also an den 55:11.280 --> 55:16.000 kannten kannst du dieses margin dann abschneiden so dass das eigentlich nur 55:16.000 --> 55:23.200 zwischen den elementen gilt aber eben nicht zum rand des der box also ist ein 55:23.200 --> 55:33.760 margin außer an den margins ja schon genau das ist ja net okay okay dann 55:33.760 --> 55:40.600 hat er das deswegen auch nicht genau man sagt damit wo dieses wo der margin 55:40.600 --> 55:46.600 weggetrimpt werden soll so rum funktioniert das genau ah okay ich war 55:46.600 --> 55:50.520 gerade erst wieder so im im im Sinne von eine alternative margin angabe man 55:50.520 --> 55:53.560 macht eine normale margin angabe und sagt dann wo der margin weggetrimpt 55:53.560 --> 55:59.240 werden soll also irgendwie in line start in line end so zu euch 56:00.600 --> 56:06.240 genauso ja genau also du sagst in line an in line start soll das weggetrimpt 56:06.240 --> 56:11.280 werden oder in line end und in block richtung geht das geht das genauso 56:11.280 --> 56:18.320 ja genau ist halt eine kleinigkeit aber auch wieder so ein so ein ein kleiner 56:18.320 --> 56:23.800 baustein mehr der einem irgendwann mal irgendwie nützlich sein kann finde ich ja 56:23.800 --> 56:27.520 auf jeden fall weil ich meine ansonsten musst du halt eben also die alternative 56:27.520 --> 56:31.080 ist halt eine sehr viel komplizierter irgendwie dir mit last child ein 56:31.080 --> 56:36.680 abbrechen was halt ja aber selbst selbst das ist ja nicht immer möglich weil wenn 56:36.680 --> 56:43.880 wenn du dann wenn das dann umricht in eine neue zeile vielleicht ja stimmt 56:43.880 --> 56:47.400 das ist auch nicht dann funktioniert das ja schon nicht mehr genau das würde 56:47.400 --> 56:50.920 halt bei blocks funktionieren aber nicht irgendwie bei in line oder generell 56:50.920 --> 56:56.240 du hast ja auch so Sachen wie grid oder flexbox wo das ja sowieso alles schwierig 56:56.240 --> 57:07.720 wird ja was ich übrigens du finde ist an grid ist dass man nicht sagen kann ich 57:07.720 --> 57:14.240 möchte quasi viel mit das in ein grid aber wenn es aber maximal zwei rein und 57:14.240 --> 57:21.800 alles was mehr ist bitte einfach quasi verschlucken ja also da gibt es so 57:21.800 --> 57:29.160 tricks wie man das machen kann da kannst du quasi ich überlege gerade wie das war 57:29.160 --> 57:36.440 also du kannst es schon irgendwie tricksen aber du darfst dann kein gap benutzen 57:36.440 --> 57:44.160 weil dann sind zwar die elemente nicht mehr da die in zeile 3 4 5 und so weiter 57:44.160 --> 57:51.400 noch automatisch einsortiert werden aber die gaps dazwischen die bleiben okay das 57:51.400 --> 57:55.760 ist halt weil was würdest du machen du würdest dann diese grid zählen oder die 57:55.760 --> 57:59.880 tracks irgendwo wie so eine antike text replacement technik irgendwo in den 57:59.880 --> 58:07.160 orkos schieben ja sich also stell dir mal vor du hast irgendwie so eine bilder 58:07.160 --> 58:16.600 galerie und du du möchtest irgendwie vielleicht du willst nur x zeilen davon 58:16.600 --> 58:22.560 haben und wenn es dann noch mehr bilder sind dann möchtest du einfach also dann 58:22.560 --> 58:27.160 dann möchtest nicht in deinem html lösen indem du da quasi weil du weißt ja 58:27.160 --> 58:32.440 auch bei responsive gar nicht so wie viele mente sind das denn jetzt in dem 58:32.440 --> 58:37.440 viewport die drei zeilen ergeben also bei großen viewports kann es halt mehr 58:37.440 --> 58:43.840 reinstecken beim geräten vielleicht weniger und deswegen das das html kann 58:43.840 --> 58:48.280 jetzt irgendwie das nicht entscheiden das heißt da sind vielleicht dann 20 58:48.280 --> 58:54.040 30 bilder drin und du willst eben unabhängig aber du willst quasi auf 58:54.040 --> 58:59.760 jedem gerät drei zeilen anzeigen in der dann aber eben bei einem gerät beim 58:59.760 --> 59:06.000 desktop zehn spalten sind und bei mobile vielleicht nur drei oder sowas und da 59:06.000 --> 59:12.360 gibt es eben eigentlich nichts was grid vorsieht und um das auszudrücken 59:12.360 --> 59:20.240 stimmt bis wir nur so am rand eingefallen ja aber ich mache jetzt 59:20.240 --> 59:23.160 ja nicht den ganzen tag css aber mein eindruck von grid ist ja schon so dass 59:23.160 --> 59:28.880 das sehr für einen sagen wir aufgeräumtes geplantes layouten gedacht ist und so 59:28.880 --> 59:32.760 bald man funky werden möchte wird es halt relativ schnell relativ schwierig ja 59:32.760 --> 59:37.800 also vielleicht kommt ja auch jetzt was also grid version 2 ist ja in der mache 59:37.800 --> 59:42.840 wo auch subgrid drin steckt und so ich weiß nicht ob dann dann irgendwie noch 59:42.840 --> 59:49.160 neues kommt was das angeht ist es war nur so was was ich letztens als problem 59:49.160 --> 59:55.160 sozusagen auf dem tisch hatte und dass ich dann wo ich noch ein bisschen 59:55.160 --> 59:59.160 rumknobeln musste bis ich das gelöst hatte 01:00:00.440 --> 01:00:04.320 genau wer wissen will wie ich das gelöst habe bitte einfach mich anschreiben 01:00:04.320 --> 01:00:09.040 ich muss dann noch mal selber nachgucken und sagst euch wie kann keine 01:00:09.040 --> 01:00:15.560 artikelveröffentlichung ja ja ja ist recht müsst ihr machen genau müsstest 01:00:15.560 --> 01:00:20.200 ich verspreche es hier mit fein 01:00:21.480 --> 01:00:25.440 genau was ich auch ziemlich cool finde weil ich damit auch schon im aktuellen 01:00:25.440 --> 01:00:32.280 projekt rum gespielt habe ist die klarative shadow dom das ist im 01:00:32.280 --> 01:00:36.160 prinzip auch das ist so ein bisschen so wie diese ad property über die wir am 01:00:36.160 --> 01:00:42.720 anfang gesprochen hatten die erste inkarnation von der war also als 01:00:42.720 --> 01:00:48.360 javascript api und man konnte also die erste deklaration die erste inkarnation 01:00:48.360 --> 01:00:52.560 von shadow dom spezifisch nicht dass das die klarative ist die version 2 0 01:00:52.560 --> 01:00:57.280 genau und das war aber ad property auch das also am anfang konnte man das nur 01:00:57.280 --> 01:01:04.360 mit css.property machen und dann haben die leute gesagt so ja aber warum 01:01:04.360 --> 01:01:07.840 kann man das eigentlich nicht direkt in css machen das wäre doch irgendwie ein 01:01:07.840 --> 01:01:13.840 bisschen schlauer weil oder cooler weil das sehr e4 css also es ist ja css und 01:01:13.840 --> 01:01:20.080 dann ist ja quasi nachträglich diese ad property rule entstanden das also aus dem 01:01:20.080 --> 01:01:24.400 grund und bei diesem deklarative shadow dom ist das eigentlich auch wieder das 01:01:24.400 --> 01:01:29.520 gleiche also shadow dom gibt es ja schon eine ganze weile aber man konnte quasi 01:01:29.520 --> 01:01:37.560 nicht per html das auszeichnen also man musste immer javascript anwerfen dafür 01:01:37.560 --> 01:01:47.800 und irgendwie also fand ich das unnötig also so quasi diesen weg gar nicht zu 01:01:47.800 --> 01:01:56.200 haben und ich finde das ganz gut weil man damit also zum einen so ein graceful 01:01:56.200 --> 01:02:01.600 degradation in alten browser natürlich einerseits hin kriegen kann genau und 01:02:01.600 --> 01:02:06.760 zum anderen ist es eben dann auch suchmaschinen freundlicheres shadow dom 01:02:06.760 --> 01:02:12.680 als wenn du das eben alles nur in javascript rein drückst ist das der 01:02:12.680 --> 01:02:16.680 fall du meinst wegen dem template element oder was genau es ist ja im 01:02:16.680 --> 01:02:20.840 template und im template der content ist ja nicht in nörd aber der wird ja im 01:02:20.840 --> 01:02:26.960 prinzip letztlich nur als input genommen um das fragment zu erzeugen dass da am 01:02:26.960 --> 01:02:32.320 ende repräsentiert wird oder genau 01:02:32.720 --> 01:02:36.840 ja du kannst auch es wird auch einfach natürlich schneller erzeugt wenn du nicht 01:02:36.840 --> 01:02:44.120 erst javascript dafür hochfahren musst ja genau und ich spiele so ein bisschen mit 01:02:44.120 --> 01:02:51.960 mit shadow dom rum um so quasi auf der dem projekt wo ich bin so so 01:02:51.960 --> 01:02:58.280 compartments zu machen innerhalb der seite in denen zum beispiel eben das 01:02:58.280 --> 01:03:03.280 selektor matching einfach schneller abläuft weil das stylesheet dann 01:03:03.280 --> 01:03:08.240 innerhalb des shadow doms eben nur versucht die elemente die da drin sind 01:03:08.240 --> 01:03:14.720 zu matchen und eben nicht den kompletten dom also ein bisschen wie diese diese 01:03:14.720 --> 01:03:18.480 compartments in der titanik die sie eingebaut haben damit die nicht sinkt 01:03:18.480 --> 01:03:22.680 auch das vergleicht mit deinem projekt 01:03:22.680 --> 01:03:33.480 genau ja also nötig würde ich halt eben auch sagen so das braucht man dieses 01:03:33.480 --> 01:03:41.800 declarative shadow dom ich frau mich halt eben ob das reicht weil das bewegt 01:03:41.800 --> 01:03:47.920 sich jetzt ja zunehmend daran irgendwie ein templating mechanismus herzustellen 01:03:47.920 --> 01:03:51.880 also machen wir ja quasi schon es ist ja es kommt ja in buchstäblich ins 01:03:51.880 --> 01:03:54.960 template element rein und das ist eine vorlage dann hat man da so sein dom 01:03:54.960 --> 01:03:58.400 drin und dann kann man das ja mit konkretem inhalt befüllen aber klont 01:03:58.400 --> 01:04:02.040 halt die dom struktur irgendwo rein hat dann halt irgendwie seine web component 01:04:02.040 --> 01:04:05.640 oder dein compartment das macht ja alles Sinn aber ich frage mich jetzt halt 01:04:05.640 --> 01:04:10.280 wirklich wie lange kann man sich noch dem ganzen sagen mal drive dahingehend 01:04:10.280 --> 01:04:13.720 erwähren dass das irgendwann tatsächlich templates werden mit 01:04:13.720 --> 01:04:18.960 halt entsprechenden so möglichkeiten da content rein zu interpolieren oder halt 01:04:18.960 --> 01:04:23.040 eben in html irgendwelche platzhalter zu definieren dass ich da so handelbars 01:04:23.040 --> 01:04:26.240 artige sündags drin habe oder wenn man irgendwie retro drauf sein möchte 01:04:26.240 --> 01:04:32.800 irgendwie so spitzklammer fragezeichen perp echo irgendwas apple dann nicht auch 01:04:32.800 --> 01:04:37.360 schon mal was vorgeschlagen vor ewigen zeiten da gab es mehrere sachen da 01:04:37.360 --> 01:04:43.760 gab es ja dieses wie hieß das e4x also so dieses xml in javascript extension und 01:04:43.760 --> 01:04:47.920 es gibt ja tatsächlich so proposals wie man so eine j sx artige sündags die ja 01:04:47.920 --> 01:04:51.600 extrem react spezifisch ist aber so bendigen und generalisieren kann um so 01:04:51.600 --> 01:04:56.200 generell baumestrukturen auszudrücken und dann wäre das da ja drin 01:04:56.200 --> 01:04:59.240 weiß jetzt nicht ob das irgendwie so der weißheit letzter schluss ist 01:04:59.240 --> 01:05:03.240 notwendigerweise aber ich finde das ist halt irgendwie so eine geschichte 01:05:03.240 --> 01:05:07.680 früher oder später landen wir da dass da herrscht eigentlich in meinem kopf kein 01:05:07.680 --> 01:05:10.960 zweifel dass das irgendwie gehen muss weil du hast recht so der klare schiff 01:05:10.960 --> 01:05:13.800 shadow dom ist besser als das normale shadow dom weil du halt eben nicht den 01:05:13.800 --> 01:05:18.000 kompletten dom tree neu erzeugen musst und das ist ein bisschen ein bisschen 01:05:18.000 --> 01:05:21.680 convenience bonus und hatten je nach use case in deinem fall jetzt ein 01:05:21.680 --> 01:05:26.240 performance bonus auch noch aber am ende musst du dann wenn du das gemacht hast 01:05:26.240 --> 01:05:29.640 immer noch dom manipulation machen du musst dann dein shadow tree nehmen und 01:05:29.640 --> 01:05:33.480 dir da drin dann mit klare selektor oder sonst irgendwas rauspicken wo das 01:05:33.480 --> 01:05:37.720 element ist wo du den eigentlichen content reinschreiben willst 01:05:39.200 --> 01:05:43.640 ist das so also ich muss ich irgendwie text reinkriegen du hast ja deinen shadow 01:05:43.640 --> 01:05:48.240 dom in einem template also du meinst dann wenn du quasi so dynamisch renders 01:05:48.240 --> 01:05:54.120 noch ja also meine web und sicherlich ein eins und use case dafür ich meine wenn 01:05:54.120 --> 01:05:57.720 du das jetzt einfach nur zum für dieses compartment leising her nimmst ist das 01:05:57.720 --> 01:06:03.400 ja ein sehr allgemeiner ich machen genau mir ich nutze ja wirklich nur dieses 01:06:03.400 --> 01:06:09.560 diese kommt dieser grenzungsmechanik oder dieses diese silo mechanik die halt mit 01:06:09.560 --> 01:06:13.120 dem shadow dom daher kommt und was anderes will ich gar nicht nur deswegen 01:06:13.120 --> 01:06:17.320 tue ich das genau aber ich würde halt mal behaupten die meisten werden das 01:06:17.320 --> 01:06:22.720 verwenden wollen im kontext von webkomponent oder ähnlichem ja und 01:06:22.720 --> 01:06:25.960 dann stehst du halt wieder da und musst irgendwie so sagen ja hier webkomponent 01:06:25.960 --> 01:06:29.280 ist irgendwie plattform und native und alles irgendwie ganz toll aber du musst 01:06:29.280 --> 01:06:33.360 halt irgendwie die zeichen kette query selektor schreiben bevor du irgendwo text 01:06:33.360 --> 01:06:38.960 rein bauen kannst ist ja eigentlich nicht wirklich gut genug 01:06:38.960 --> 01:06:41.400 eigentlich nicht 01:06:41.400 --> 01:06:47.080 ich guck mal gerade da war was wir haben damit darüber damals auch mal gesprochen 01:06:47.080 --> 01:06:53.000 über diesen apple vorschlag ja ich gucke noch mal ob ich das vielleicht 01:06:53.000 --> 01:06:58.600 irgendwie noch finden kann und dann kann man das auch noch mal verlinken ja 01:06:58.600 --> 01:07:02.040 hast recht also irgendwas muss da irgendwann mal her ich glaube das ist ja 01:07:02.040 --> 01:07:08.180 auch einer der gründe warum warum leute auch mit einfach mit webkomponent 01:07:08.180 --> 01:07:15.640 schmerzen haben oder viele viele viele also das ist halt wirklich einfach das 01:07:15.640 --> 01:07:18.920 ist das gleiche probleme mit hudini du hast die high level api die ist 01:07:18.920 --> 01:07:21.240 etabliert und die kann sich nicht mehr ändern und muss jetzt nachgelagert die 01:07:21.240 --> 01:07:25.960 low level api bauen die das erklärt notwendigerweise unglaublich schwierig 01:07:25.960 --> 01:07:29.880 und vor allen Dingen fehlen die halt überall die werkzeuge also normales 01:07:29.880 --> 01:07:32.960 shadow dom und dann hast du die klerative shadow dom das macht sicherlich besser 01:07:32.960 --> 01:07:36.360 aber das ist sicherlich kein quanten sprung würde ich behaupten dann hast 01:07:36.360 --> 01:07:39.880 du da draußen die ganzen verrückten die typescript verwenden wollen und müssen 01:07:39.880 --> 01:07:42.520 dann halt irgendwie mit html interagieren html ist halt einfach nur eine 01:07:42.520 --> 01:07:46.520 welt aus schmerzen bzw strings da können die halt mit ihrem typescript nichts 01:07:46.520 --> 01:07:50.680 mit anfangen das ist komplett wertlos dann und dann ist das halt eben auch die 01:07:50.680 --> 01:07:53.160 frage okay du könntest stattdessen irgendwie angular oder react komponenten 01:07:53.160 --> 01:07:57.360 bauen bis damit zügiger unterwegs ja hast irgendwelche dependencies ja muss 01:07:57.360 --> 01:08:00.560 da und updaten und in 20 jahren weiß keiner mehr was da vor und hinten ist 01:08:00.560 --> 01:08:05.480 aber das interessiert dich halt jetzt gerade nicht und generell auch so die 01:08:05.480 --> 01:08:08.600 ganze api interwebkomponent ist halt so unglaublich kompliziert und so 01:08:08.600 --> 01:08:13.760 einschränkend da würde ich halt jetzt behaupten dass die das neue decorators 01:08:13.760 --> 01:08:18.280 proposal in eckmascript einiges richten wird aber das wird halt nie so gut 01:08:18.280 --> 01:08:21.800 sein wie das halt irgendwie in so einem framework context ist notwendigerweise 01:08:21.800 --> 01:08:26.280 das kann gar nicht sein aber wenn man halt zumindest mal einsehen würde dass 01:08:26.280 --> 01:08:29.300 man halt irgendwie hinter der anderdoc ist und man halt wirklich mal jetzt hier 01:08:29.300 --> 01:08:33.560 was verrücktes anstellen muss dann würde man da glaube ich irgendwie noch 01:08:33.560 --> 01:08:37.200 weiter vorankommen und irgendwie was verwenden was halt nicht nur shadow tom 01:08:37.200 --> 01:08:41.480 also die erste idee so von damals ist nur halt eben jetzt in deklarativ statt 01:08:41.480 --> 01:08:45.320 imperativ sondern wirklich auch sagt da machen wir eine voll eine volle template 01:08:45.320 --> 01:08:48.680 sprache daraus auf die ein oder andere weise adaptiert von mir aus jsx und 01:08:48.680 --> 01:08:51.720 reaktifiziert das ein bisschen macht es halt irgendwas dass man sich halt nicht 01:08:51.720 --> 01:08:55.080 wie das letzte follow-upst vorkommt wenn man versucht irgendwie zu sagen 01:08:55.080 --> 01:08:59.360 webkomponents existieren auch ja es ist alles mühsam und inconsistenz und 01:08:59.360 --> 01:09:02.560 schmerzhaft aber dafür müsste halt eben in drei jahren kein update durchführen 01:09:02.560 --> 01:09:07.560 es ist halt eine echte schlechte perspektive 01:09:08.280 --> 01:09:15.000 ja aber auch irgendwie was an das sich keiner so richtig handraut 01:09:15.000 --> 01:09:18.760 was kann ich verstehen ich will die einscheinungen auch nicht treffen weil 01:09:18.760 --> 01:09:21.960 sitzen am ende wieder dann irgendwie zwei nasen in einem podcast in zwei jahren 01:09:21.960 --> 01:09:25.560 und sagen so guckt ihr mal das an was haben wir uns damals bei damals nur 01:09:25.560 --> 01:09:29.520 gedacht ist natürlich alles sehr viel leichter gesagt als getan aber wie es 01:09:29.520 --> 01:09:32.840 jetzt gibt ja mittlerweile würde ich behaupten genug prior art die man 01:09:32.840 --> 01:09:37.200 hernehmen könnte als guidelines es muss ja nicht jsx sein es könnte ja einfach 01:09:37.200 --> 01:09:41.880 irgendwie so eine art von weiß ihr nicht bild in tag template literal ding sie 01:09:41.880 --> 01:09:45.560 irgendwas sein vielleicht kann man irgendein mechanismus daraus hijacken 01:09:45.560 --> 01:09:50.160 oder oder oder gibt so viele template sprachen da draußen 01:09:50.160 --> 01:09:54.200 vielleicht gehen das beste clown macht man doch bei eckmas kript ständig 01:09:54.200 --> 01:10:01.480 ja ja mal sehen wann wir wann wir endlich darüber reden können wenn das dann 01:10:01.480 --> 01:10:06.280 wenn sowas dann spezifiziert und vielleicht in den ersten browsern gelandet 01:10:06.280 --> 01:10:11.800 ist ja ich bin auf jeden fall gespannt weil bis dahin werden wir weiter irgendwelche 01:10:11.800 --> 01:10:14.040 frameworks haben wo man das halt irgendwie implementiert also man kann den 01:10:14.040 --> 01:10:17.240 Leuten das nicht vorenthalten wenn man sie nicht gibt dann machen sie selber und 01:10:17.240 --> 01:10:23.560 dann wird es halt wahrscheinlich halb gar und schmerzhaft ja generell ist jetzt 01:10:23.560 --> 01:10:28.200 in dieser in der technologie preview 162 nicht ganz so viel kram drin aber 01:10:28.200 --> 01:10:32.760 vielleicht kannst du mir noch mal ein bisschen erzählen es gibt hier die 01:10:32.760 --> 01:10:40.720 form associated custom elements die genau magst du da noch mal was zu erzählen 01:10:40.720 --> 01:10:46.680 ja also idee ist bausten custom element und würde es zum beispiel sowas machen 01:10:46.680 --> 01:10:51.080 wollen wie einen keine ahnung lange mal ein custom color picker mit einem alpha 01:10:51.080 --> 01:10:55.000 kanal der normale hat keinen alpha kanal aber du willst halt irgendwie die 01:10:55.000 --> 01:10:59.440 möglichkeit bieten dass man rgb angibt und halt auch noch und du willst keinen 01:10:59.440 --> 01:11:02.480 fancy design machen du willst das nur irgendwie möglich machen in irgendeiner 01:11:02.480 --> 01:11:06.240 form die einfachste variante das in einem kasten element umzusetzen wäre ja du 01:11:06.240 --> 01:11:09.800 nimmst ein color input und du nimmst ein number input und du packst sie zusammen 01:11:09.800 --> 01:11:14.720 in einen custom element und dann kannst du ein bisschen javascript schreiben das 01:11:14.720 --> 01:11:18.200 im prinzip sagt irgendwie uns hat mit oder so jetzt ganz vereinfacht ausgedrückt 01:11:18.200 --> 01:11:22.440 geht halt eben hin und pickt sich halt den rgb wert aus dem color input den 01:11:22.440 --> 01:11:25.360 alpha wert aus number input und flanscht die zusammen macht da zum beispiel 01:11:25.360 --> 01:11:30.800 eine keine ahnung rgba hex notations geschichte daraus könnte man sich 01:11:30.800 --> 01:11:34.560 konzeptionell vorstellen das problem ist nur dass das resultierende element 01:11:34.560 --> 01:11:39.600 dass du dann baust nicht abwerk ein formular element ist auch wenn du es 01:11:39.600 --> 01:11:42.840 irgendwie in formular reinsteckst und du implementierst darauf so dinge wie ein 01:11:42.840 --> 01:11:47.540 value getter und ein name attribute und all so Sachen macht das das ganze nicht 01:11:47.540 --> 01:11:51.800 automatisch zu einem form associated custom element das heißt man die das 01:11:51.800 --> 01:11:57.800 formula absenden würde dann würde das würde der browser das input element 01:11:57.800 --> 01:12:02.640 das im custom element drin steckt nicht quasi zusammen mit dem anderen kram 01:12:02.640 --> 01:12:05.920 verschicken korrekt genau würde nicht verschickt werden ist nicht 01:12:05.920 --> 01:12:09.600 Gegenstand von der constraint validation ist halt im prinzip als würdest du ein 01:12:09.600 --> 01:12:14.480 diff in dein formula reinstecken weil das im prinzip das ist was du tun würdest und 01:12:14.480 --> 01:12:18.960 warum ist es so also das intuitiv kommt einem das ja irgendwie merkwürdig vor 01:12:18.960 --> 01:12:23.840 weil man hat ein input also wenn man jetzt dedizierten input da reinstecken würde 01:12:23.840 --> 01:12:29.320 aber hast du nicht denn du hast ja das ganze im shadow dom wenn nun custom 01:12:29.320 --> 01:12:33.760 element baust und im shadow dom wohnen ja die implementierungs details ja 01:12:33.760 --> 01:12:38.920 nicht gegenstand der öffentlichen api sind also um das zu generalisieren ja du 01:12:38.920 --> 01:12:42.800 könntest quasi auch keinen auf dem document wenn du da query selektor all 01:12:42.800 --> 01:12:48.400 auf alle inputs machst dann würde es da ja auch nicht auftauchen genau also das 01:12:48.400 --> 01:12:51.280 ist jetzt sozusagen die beschreibung des phänomens du schiebst das in shadow 01:12:51.280 --> 01:12:55.120 dom dadurch ist ein implementierungs detaile dadurch kann halt eben der sozusagen 01:12:55.120 --> 01:12:58.800 das mit der main realm da nicht rankommen aber wenn du es ein bisschen 01:12:58.800 --> 01:13:02.680 generalisierst ist das eigentlich so du hast halt deine html apis mit den 01:13:02.680 --> 01:13:07.320 ganzen attributen und gettern und settern und das ist sozusagen die public 01:13:07.320 --> 01:13:11.360 api die eine html element so hat für dich als webentwickler und webentwickler 01:13:11.360 --> 01:13:15.600 drin ist also hin und benutzt das aber wenn du die spezifikationen anschaust 01:13:15.600 --> 01:13:21.480 gibt es ja noch eine gleichsam private api die solche elemente haben das sind 01:13:21.480 --> 01:13:24.360 dann halt eben so sachen die zum beispiel der formular validierungsmechanismus 01:13:24.360 --> 01:13:29.160 sind aber auch so dinge wie die voreingestellten area settings für 01:13:29.160 --> 01:13:34.000 barrierefreiheit und zeug das ist ja auch so zeug das ist definiert und da 01:13:34.000 --> 01:13:37.320 gibt es algorithmen für wenn dieser und jene umstand vorliegt dann wird das 01:13:37.320 --> 01:13:40.840 dieser roll kriegen ansonsten kriegt jene roll und so weiter das sind ja alles 01:13:40.840 --> 01:13:46.160 wohl definierte algorithmen nur die sind halt eben private oder die sind intern 01:13:46.160 --> 01:13:51.280 und was man jetzt kriegt sozusagen im rahmen von form associated custom 01:13:51.280 --> 01:13:55.600 elements oder sagen wir so form associated form associated custom elements sind 01:13:55.600 --> 01:13:59.160 eine ausprägung von dem ist auf webkomponents eine methode die nennt 01:13:59.160 --> 01:14:05.320 sich attach internals und die liefert dir eine public api für die private api von 01:14:05.320 --> 01:14:10.440 vielen dieser internen prozesse und diese internen prozesse sind so Dinge wie 01:14:10.440 --> 01:14:15.600 set form value das heißt was du dann machen kannst ist zu sagen okay ich 01:14:15.600 --> 01:14:18.600 habe jetzt ja mein custom element und das enthält halt eben in seinem 01:14:18.600 --> 01:14:23.840 shadowdom das color input und das number input für den alpha kanal ich mache 01:14:23.840 --> 01:14:26.800 da eventlistener drauf und wenn sich auf einen von den beiden elementen was 01:14:26.800 --> 01:14:31.920 ändert dann rufe ich die internals method set form value auf und rechne dann 01:14:31.920 --> 01:14:35.800 da aus was mein rgba wert ist schiebt ihn da rein und dadurch habe ich jetzt auf 01:14:35.800 --> 01:14:40.640 meinem element etwas dass diesen internen mechanismus vollzieht umgesetzt aus 01:14:40.640 --> 01:14:45.760 dieser attach internals mechanik heraus aus dem inneren auf vor der custom element 01:14:45.760 --> 01:14:49.360 klasse und dann gehe ich noch hin und definiere halt auf dem element so was 01:14:49.360 --> 01:14:54.160 wie ein muss ich in einem ein feld definieren ein static ich erinnere mich 01:14:54.160 --> 01:14:56.720 jetzt gerade nicht ich glaube ein static string der einfach form associated 01:14:56.720 --> 01:14:59.080 heißt oder irgendwie sowas oder ich muss das auf true setzen ich erinnere mich 01:14:59.080 --> 01:15:01.760 gerade nicht genau aber ich muss halt eben den browser sagen das ding ist form 01:15:01.760 --> 01:15:06.320 associated und dann weiß der browser ich muss das abschicken und abschicken 01:15:06.320 --> 01:15:10.880 heißt halt diese internen felder die gesetzt werden über diese internals 01:15:10.880 --> 01:15:15.200 auslesen und dann funktioniert die kiste also das ist immer noch riesiger 01:15:15.200 --> 01:15:19.200 auffand sowas zu bauen wie den gerade illustrierten color picker aber das geht 01:15:19.200 --> 01:15:22.640 und man kann halt wirklich auch so Sachen machen wie zu sagen okay wenn einer von 01:15:22.640 --> 01:15:26.600 den beiden dingern invalid ist entweder color oder alpha dann mache ich halt den 01:15:26.600 --> 01:15:30.560 validity wert von dem umgebenden halt eben auch auf ungültig und kann halt 01:15:30.560 --> 01:15:34.520 wirklich da das komplette behavior nach modelieren und habe ich jetzt so ein 01:15:34.520 --> 01:15:37.400 bisschen langwierig erzählt weil halt eben dieses attach internals viel mehr 01:15:37.400 --> 01:15:40.920 macht als nur das ist halt eine universelle api um diese implementierungs 01:15:40.920 --> 01:15:45.240 details für uns zugreifbar zu machen damit wir wirklich das machen können 01:15:45.240 --> 01:15:48.960 was ich den ganzen zeit schon sage nämlich die high level api aus der low level api 01:15:48.960 --> 01:15:54.400 obwohl die nachträglich dran geflanscht wurde komplett erklären ja cool das ist 01:15:54.400 --> 01:16:02.720 extrem cool ja ich baue tatsächlich wenig webkomponent deswegen bin ich 01:16:02.720 --> 01:16:09.040 da wahrscheinlich einfach noch nicht auf dieses problem gestoßen ja aber macht 01:16:09.040 --> 01:16:18.240 sinn und es ja dass es auch jetzt erst dazu kommt es ist dann schon fast 01:16:18.240 --> 01:16:22.520 erstaunlich ja weiß nicht ist halt unglaublich kompliziert so ein formular 01:16:22.520 --> 01:16:27.320 element also du hast die validierung set form value und du hast ja auch fragen um 01:16:27.320 --> 01:16:29.920 so Sachen wie fokussierbarkeit und so das muss ja alles irgendwie erst mal 01:16:29.920 --> 01:16:34.640 durchdachten und dass man irgendwie so für so ein mvp version 1.0 erst mal sagt 01:16:34.640 --> 01:16:42.280 okay diffs und so ja man merkt das ja auch wenn man so seine so abseits von 01:16:42.280 --> 01:16:48.480 webkomponent irgendwie seine eigenen formular eingabefelder baut oder wenn 01:16:48.480 --> 01:16:54.360 man irgendwie generell formular bauchesten baut die irgendwie funktionieren 01:16:54.360 --> 01:17:01.720 da da merkt man dann alles also was da alles noch drin steckt ja cool so ist es 01:17:01.720 --> 01:17:09.560 aber es ist keine lösung für das problem wenn ein wenn man ein label hat 01:17:09.560 --> 01:17:16.080 dass quasi wenn man eine webkomponent hat die label ist eine webkomponent die 01:17:16.080 --> 01:17:23.000 input ist dass die dann irgendwie die richtigen elemente nicht miteinander 01:17:23.000 --> 01:17:27.600 zeigen können oder nicht auch noch was das ist da auch noch so ein quasi deal 01:17:27.600 --> 01:17:33.240 breaker so ein bisschen bei webkomponent ich weiß nicht was du genau meinst aber 01:17:33.240 --> 01:17:36.600 das hört sich auf jeden fall so an aus der beschreibung heraus würde ich jetzt 01:17:36.600 --> 01:17:40.240 auch sagen ich nähere mich jetzt dem dem ausgang an damit ich mit dem problem 01:17:40.240 --> 01:17:43.480 mich nicht auseinandersetzen muss weil ich mir relativ sicher bin dass du 01:17:43.480 --> 01:17:47.440 recht hast ja ich glaube es im prinzip so wenn die beide in ihrem eigenen 01:17:47.440 --> 01:17:50.600 shadow DOM quasi gekapselt sind dann haben die eben nicht die 01:17:50.600 --> 01:17:55.200 möglichkeit über so eine id also mit vor und id irgendwie aufeinander zu zeigen 01:17:55.200 --> 01:18:00.360 und dann so aber gut aber das wäre ja auch falsch denn das shadow DOM ist ja 01:18:00.360 --> 01:18:04.040 ein implementierungsdetail da darf ja nichts rein da darf ja nichts raus 01:18:04.040 --> 01:18:08.800 korrekt also den scenario wäre du baust ein form associated custom element und 01:18:08.800 --> 01:18:12.840 du baust ein do it yourself shape label und du willst das shape label auf das 01:18:12.840 --> 01:18:16.480 form associated custom element zeigen lassen 01:18:16.480 --> 01:18:23.520 genau so glaube ich so ist das problem ja ja also dann weiß ich jetzt nicht ob 01:18:23.520 --> 01:18:27.280 das mit den attach internals also entweder jetzt geht ich würde wetten das 01:18:27.280 --> 01:18:31.200 nicht oder machbar ist weil ich habe jetzt die internen algorithmen für so ein 01:18:31.200 --> 01:18:37.920 label nicht im kopf genau das gleiche noch mal quasi nicht für input sondern 01:18:37.920 --> 01:18:43.600 für labels geben damit man diesen label custom element sozusagen die die 01:18:43.600 --> 01:18:47.560 notwendigen tricks beibringt dass sich das auch dann wie nach außen wie ein 01:18:47.560 --> 01:18:52.120 label verhält ja aber wie gesagt deswegen ist ja attach internals mehr als 01:18:52.120 --> 01:18:56.280 nur formulare also im prinzip wäre das denkbar jetzt mache ich hier gerade 01:18:56.280 --> 01:19:02.340 parallel die mdn seite zu attach internals auf bla bla bla accessibility 01:19:02.340 --> 01:19:05.800 object model und im hintergrund lädt die html spezifikation damit ich mal kurz 01:19:05.800 --> 01:19:11.360 gucken kann ob so ein label tatsächlich so ein also wenn das so eine element 01:19:11.360 --> 01:19:15.560 klasse ist so wie form associated dann wüsste ich halt nicht warum man das 01:19:15.560 --> 01:19:19.840 nicht machen müsste machen könnte also würde ich jetzt sagen ich hätte jetzt 01:19:19.840 --> 01:19:25.240 fast gesagt irgendwie ja mach eine type extension also class shape label extents 01:19:25.240 --> 01:19:28.480 html label element aber das wird ja auch nicht funktionieren weil dem kannst du 01:19:28.480 --> 01:19:31.280 dann ja wahrscheinlich wenn ich mich nicht täuschen nicht dein eigenes shadow 01:19:31.280 --> 01:19:34.800 dom überhelfen du müsstest also wirklich ein neues element erzeugen und das 01:19:34.800 --> 01:19:39.040 müsste halt eben wie ein label agieren 01:19:39.040 --> 01:19:48.720 ja alles sehr berechtigt die muss aber auch nicht jetzt aufklären können ich 01:19:48.720 --> 01:19:51.960 will es late halt nur nicht die spezifikation schon wieder was länger 01:19:51.960 --> 01:19:58.240 geworden ist last updated 28 der januar also vor zwei tagen 01:19:58.240 --> 01:20:00.960 also war da mal kurz das klären wir jetzt eben noch nicht und in der 01:20:00.960 --> 01:20:04.640 zwischenzeit kannst du ja mal deine interpretation das einen punkt ist noch 01:20:04.640 --> 01:20:07.000 der mich interessiert in der technologie preview noch eben kurz zum 01:20:07.000 --> 01:20:09.200 besten geben 01:20:09.200 --> 01:20:17.800 gespannt was das ist moved on copy on cut und und on paste to global event handlers 01:20:17.800 --> 01:20:25.120 was tut das ja also ich würde 01:20:25.480 --> 01:20:33.680 vermuten dass dass du dass das bisher event handlers waren die an bestimmte 01:20:33.680 --> 01:20:38.600 elemente gekoppelt waren also ist die nur auf bestimmten elementen ausgelöst 01:20:38.600 --> 01:20:45.440 werden konnten was vermutlich dann einfach irgendwie inputs waren und das 01:20:45.440 --> 01:20:50.960 dass das im prinzip jetzt auf jedem element ausgelöst werden kann was 01:20:50.960 --> 01:20:57.680 vielleicht dann content editable elemente neu umfasst aber wahrscheinlich waren die 01:20:57.680 --> 01:21:02.920 vorher schon dabei aber möglicherweise möchte man trotzdem genau wenn man 01:21:02.920 --> 01:21:08.160 zum beispiel auf dem dokument fokussiert ist und nicht auf einem input 01:21:08.160 --> 01:21:15.640 einen reinpasten können und dann fängt man das eben ab und leitet das dann 01:21:15.640 --> 01:21:22.800 dahin wo man wo man es eben braucht dass was da eingepasted wurde exakt exakt 01:21:22.800 --> 01:21:28.080 optimale beschreibung genau das richtige nur halt noch eins andere use case 01:21:28.080 --> 01:21:33.680 noch event delegation ja du würdest ja gegebenenfalls wirklich sagen wollen 01:21:33.680 --> 01:21:38.200 keine ahnung document body dot on paste gleich function und obwohl du programmierst 01:21:38.200 --> 01:21:41.280 als wärst du gerade der jungsteinzeit entstiegen willst du aber diese fancy 01:21:41.280 --> 01:21:45.240 event delegation technik verwenden auch dann funktioniert das ich habe mir das 01:21:45.240 --> 01:21:47.520 aus irgendwelchen gründen mal drauf geschafft wie das alles so funktioniert 01:21:47.520 --> 01:21:50.600 mit diesem global event handlers und so und das wohnt jetzt in meinem kopf und 01:21:50.600 --> 01:21:53.320 deswegen wenn ich sowas sehe was eigentlich wirklich niemand braucht weil 01:21:53.320 --> 01:21:58.360 niemand schreibt document dot body dot on paste gleich function man macht 01:21:58.360 --> 01:22:02.160 event listener und dann ist das sowieso alles egal aber nur für den fall dass 01:22:02.160 --> 01:22:07.400 man es mal nicht machen würde würdest trotzdem sind die auch nicht als copy 01:22:07.400 --> 01:22:12.200 cut und paste events da aufgelistet sondern tatsächlich dediziert als on copy 01:22:12.200 --> 01:22:20.160 on cut und on paste weil es da quasi um die steinzeit notation geht genau aber 01:22:20.160 --> 01:22:24.800 irgendwie fernspielter event delegation mit rein das ist ja quasi du du horchst 01:22:24.800 --> 01:22:29.920 am am ruht und kriegst dann solche events mit auch wenn die irgendwie tiefer im 01:22:29.920 --> 01:22:36.360 dom stattfinden genau und das ging vorher nicht das heißt du konntest 01:22:36.360 --> 01:22:44.040 vorher keinen irgendwie on copy auf dem body setzen dann hat dieser event 01:22:44.040 --> 01:22:48.240 handler das nicht mitbekommen wenn innerhalb des bodies in einem text area 01:22:48.240 --> 01:22:52.400 was kopiert wurde richtig richtig was aber niemanden stört weil niemand 01:22:52.400 --> 01:22:57.600 on copy schreibt und alle machen event listener copy okay und das geht auch 01:22:57.600 --> 01:23:03.720 dann tatsächlich nicht bei allen events weil bestimmte events so eingerichtet 01:23:03.720 --> 01:23:09.280 sind dass die nicht babbeln und andere babbeln ist es hat das damit zu tun ich 01:23:09.280 --> 01:23:12.160 weiß jetzt nicht ob das sozusagen die herleitung ist aber es ist auf jeden fall 01:23:12.160 --> 01:23:16.320 so dass das phänomen so zutrifft also Dinge wie das clay event gibt es halt 01:23:16.320 --> 01:23:21.720 nur auf dem video glaube ich jetzt es gibt solche aber es ist halt wirklich so 01:23:21.720 --> 01:23:26.720 diese ganze mechanik von html attribute on copy und dom property on copy und 01:23:26.720 --> 01:23:29.920 diese ganze string wird zu einer funktion funktion wird zu einem string 01:23:29.920 --> 01:23:33.880 je nachdem wie du die getter und zetter aufrufst das ist halt eben alles jetzt 01:23:33.880 --> 01:23:36.400 für die drei events auch auf dem interface global event handlers 01:23:36.400 --> 01:23:47.200 implementiert also wirklich so okay brauchst du vielleicht nicht nie aber 01:23:47.200 --> 01:23:52.480 vielleicht also irgendwie so der anlass wird wahrscheinlich sein irgendeine 01:23:52.480 --> 01:23:56.880 webseite oder irgendein web app wird es halt aus irgendwelchen also es kommt ja 01:23:56.880 --> 01:24:01.080 dann doch öfter vor als man denkt tatsächlich mit diesen on irgendwas 01:24:01.080 --> 01:24:06.640 ding an anstatt event listener und da wird es wahrscheinlich irgendeine anwendung 01:24:06.640 --> 01:24:11.800 geben die das benutzt hat und die dann irgendwelche bug reports gefeilt haben 01:24:11.800 --> 01:24:16.680 gegen webkit und dann hatten die irgendwann die nase voll und haben 01:24:16.680 --> 01:24:20.640 sich halt wahrscheinlich anderen den anderen browser herstellern angeglichen 01:24:20.640 --> 01:24:26.280 nämlich mal an ich denke es ist halt wahrscheinlich keine so große aufrisöle 01:24:26.280 --> 01:24:30.080 jetzt mal erwarten weil das grundsätzliche behavior ja für die 01:24:30.080 --> 01:24:35.640 ganzen anderen elements irgendwie on key ab und so ja auch schon da war aber ich 01:24:35.640 --> 01:24:39.440 meine es sind halt so sachen so dinge müssen sind halt auch da und die werden 01:24:39.440 --> 01:24:43.040 halt eben auch repariert und so gleicht sich halt eben diese ganze diese ganze 01:24:43.040 --> 01:24:45.320 standards geschichte am ende immer mehr an und die browser werden halt immer 01:24:45.320 --> 01:24:48.640 gleicher nicht nur weil die jetzt eben die alle zu chromotieren sondern auch 01:24:48.640 --> 01:24:54.880 weil tatsächlich selbst in so ultra ranständige probleme energie reingesteckt 01:24:54.880 --> 01:24:57.040 wird und da werden da wird code geschrieben und da werden dann tests 01:24:57.040 --> 01:25:00.840 geschrieben und release notes geschrieben und das ist halt eben 01:25:00.840 --> 01:25:05.080 eigentlich so das ding kann es kann ganze frameworks verwenden bis der 01:25:05.080 --> 01:25:09.520 arzt kommt aber immer wenn man da was neues lernt tickt dann halt sofort die 01:25:09.520 --> 01:25:13.040 uhr und irgendwann ist es veraltet muss ersetzt werden oder das framework stirbt 01:25:13.040 --> 01:25:16.240 oder sonst irgendwas und die webplattform ist das gegenteil wird halt immer 01:25:16.240 --> 01:25:19.480 besser auch wenn das was besser wird vielleicht wie webkomponent im moment eher 01:25:19.480 --> 01:25:25.320 schlechter ist aber zumindest stimmt die richtung ja ja genau also das wissen 01:25:25.320 --> 01:25:31.680 kann man auch kann man mutmaßlich lange gebrauchen genau kurz noch eben meine 01:25:31.680 --> 01:25:36.440 erforschungen zum label element haben jetzt keine definitive antwort ergeben 01:25:36.440 --> 01:25:42.400 aber es gibt zumindest etwas was davon spricht dass das label event ein 01:25:42.400 --> 01:25:46.600 activation behavior auslöst was dann halt eben das fokussieren von dem 01:25:46.600 --> 01:25:51.640 betroffenen formular element ist und ich würde mal annehmen auch wenn das im 01:25:51.640 --> 01:25:56.080 moment nicht in den internals von attach internals drin zu sein scheint dass das 01:25:56.080 --> 01:25:58.480 zumindest nicht ausgeschlossen ist dass es das mal geben wird und ich würde auch 01:25:58.480 --> 01:26:03.400 eher sagen da kann man tatsächlich einen ganz guten case machen in den bug 01:26:03.400 --> 01:26:07.560 trackern dieser welt dass das passieren müsste weil wie du richtig sagst relativ 01:26:07.560 --> 01:26:13.320 offensichtlich dass da was fehlt ja ich glaube das ist relativ bekannt also 01:26:13.320 --> 01:26:21.840 dass das so ein problem ist ja cool aber ich würde sagen dann also vielen dank 01:26:21.840 --> 01:26:28.960 auf jeden fall für deine recherche und auch vielen dank hier für das quatschen 01:26:28.960 --> 01:26:33.800 es war mir wie immer ein vergnügen genau wir sind da jetzt durch durch beide 01:26:33.800 --> 01:26:40.720 releases durch und waren schon ein paar coole sachen dabei und gelernt habe ich 01:26:40.720 --> 01:26:45.720 auch wieder was müssen wir jetzt nur gucken ob uns dieser browser halt noch 01:26:45.720 --> 01:26:53.960 erhalten bleibt du meinst hier nach diesen wenn jetzt der european was das 01:26:53.960 --> 01:27:00.040 digital markets act oder wieder heißt kommt genau die apple andro browser zu 01:27:00.040 --> 01:27:05.040 lassen müssen genau also es ist ja so die die auswahl ist ja schon relativ 01:27:05.040 --> 01:27:08.800 schmal geworden an der browser das war ja früher mal deutlich mehr an engines 01:27:08.800 --> 01:27:12.920 das ist jetzt so einer von denen die halt noch übrig ist und das ist ja schon so 01:27:12.920 --> 01:27:17.880 ein bisschen so der der kandidat gallisches dorf so ein ganz klein wenig 01:27:17.880 --> 01:27:22.000 weil die ja buchstäblich hinter ihren hinter ihren palisaden da stehen und 01:27:22.000 --> 01:27:25.320 sich mühsam verteidigen nur würde ich jetzt nicht notwendigerweise sagen dass 01:27:25.320 --> 01:27:31.040 die so wie asterix und obelix definitiv die guten sind aber es sind zumindest mal 01:27:31.040 --> 01:27:35.720 welche und ich werde auch nicht sagen dass die damit dem digital markets act 01:27:35.720 --> 01:27:38.880 wenn die dahin gehen und sagen so du musst jetzt hier im prinzip ja genauso 01:27:38.880 --> 01:27:42.800 wie microsoft damals tür und tor öffnen für die konkurrenz ist das ist 01:27:42.800 --> 01:27:46.520 sicherlich richtig so und ich will nicht sagen dass das nicht passieren sollte 01:27:46.520 --> 01:27:51.200 nur wenn uns dann hinterher dieser browser flürten geht oder so auf ein 01:27:51.200 --> 01:27:56.120 relevantes niveau vom firefox heutzutage zurückgedampft wird mich nicht 01:27:56.120 --> 01:28:00.640 wundern so ein bisschen pessimismus würde ich da schon mal vorrat mal haben 01:28:00.640 --> 01:28:04.320 damit man hinterher nicht überrascht ist genau andererseits muss man ja sagen 01:28:04.320 --> 01:28:08.480 also man hat ja schon gemerkt ich weiß nicht wie lange das jetzt geht also 01:28:08.480 --> 01:28:12.600 sagen wir mal drei vier jahre dass die ja auch irgendwie ordentlich kritik 01:28:12.600 --> 01:28:19.480 eingesteckt haben genau aber seitdem passiert auch echt ganz schön viel also 01:28:19.480 --> 01:28:25.320 und ich denke mal auch dass das sozusagen einen antizipieren der 01:28:25.320 --> 01:28:32.160 möglichkeit ist dass eben andere browser auf ios landen und ja also wenn man dann 01:28:32.160 --> 01:28:35.200 ein gutes angebot hat dann bleiben die leute auch ich meine es ist ja schon 01:28:35.200 --> 01:28:39.920 ein riesen vorteil wenn du der quasi mitgelieferte browser bist und das sieht 01:28:39.920 --> 01:28:46.040 man ja auch bei android und chrome und ich glaube ich mein e wurde ja auch viel 01:28:46.040 --> 01:28:51.120 genutzt bis bis weiter einfach nur noch scheiße war ja und ich meine etsch wird 01:28:51.120 --> 01:28:53.920 ja heute immer noch viel genutzt der ist jetzt das jetzt ja chrome ist ja okay 01:28:53.920 --> 01:28:57.400 der ist nicht schlechter als chrome aber trotzdem ist der default halt eben das 01:28:57.400 --> 01:29:00.960 ist das ist normalerweise da in windows und das ist gut genug und das passt schon 01:29:00.960 --> 01:29:06.120 und stimmt ja auch ist ja gut genug aber etsch ist halt auch keine eigene 01:29:06.120 --> 01:29:10.920 entität mehr so in dem sinne und chrome ist sowieso der de facto standard und 01:29:10.920 --> 01:29:13.840 der wäre es halt eben auch wenn er nicht bei einen android der mitgeliefert 01:29:13.840 --> 01:29:16.840 genau man sieht es ja an firefox also die haben ja keine eigene plattform die 01:29:16.840 --> 01:29:21.840 ist es ja eigentlich auch ein guter browser aber also firefox os das hat 01:29:21.840 --> 01:29:25.720 der das hat nicht geklappt hätten sie vielleicht auch lieber nicht versuchen 01:29:25.720 --> 01:29:31.520 weiß ich nicht ich fand prinzipiell schon nicht schlecht ich glaube ich glaube 01:29:31.520 --> 01:29:35.360 dieses was ich halt irgendwie wahrscheinlich also was ich do fand war 01:29:35.360 --> 01:29:41.560 dieser ansatz dass die so ganz low-levelige geräte quasi nur 01:29:41.560 --> 01:29:46.280 ausgebracht haben damit die halt günstig sind und so ist ja auch alles toll 01:29:46.280 --> 01:29:52.440 aber das sind keine geräte gewesen die man eigentlich haben wollte und man 01:29:52.440 --> 01:29:56.840 auch keine die spaß gemacht haben ich hatte auch so ein teil aber es war 01:29:56.840 --> 01:30:05.080 halt was cool das ist halt irgendwie so weißt du ich stelle mir ein mechanischen 01:30:05.080 --> 01:30:09.520 taschenrechner ins regal weil es cool aber ich beabsichtige nicht den zu 01:30:09.520 --> 01:30:12.320 benutzen für meine tägliche arbeit genau das war ja eigentlich nur so ein 01:30:12.320 --> 01:30:19.240 kuriosum also genau darum hat man es wirklich genau genau 01:30:19.240 --> 01:30:25.520 nee und ich glaube die von firefox das ist halt so einer der gründe für den 01:30:25.520 --> 01:30:30.040 niedrigen marktenteil und wenn die webkit leute irgendwie weiter gas geben 01:30:30.040 --> 01:30:37.400 und aufschließen dann habe ich da jetzt erst mal nicht so viele bedenken also 01:30:37.400 --> 01:30:43.680 dass die den den widerstand aufrecht erhalten können ja glaube ich schon man 01:30:43.680 --> 01:30:47.600 muss ja schon einige schritte gehen bis man dann irgendwie seinen anderen 01:30:47.600 --> 01:30:52.520 pause installiert warum lässt man dann nicht einfach den anderen dem oder 01:30:52.520 --> 01:30:55.920 nimmt man nicht den der e schon drauf ist der halt eben natürlich auch viel 01:30:55.920 --> 01:30:59.240 besser ins betriebssystem integriert werden kann einfach nur weil man sich 01:30:59.240 --> 01:31:02.040 dann natürlich als mobile safari zum beispiel es leisten kann sich darauf 01:31:02.040 --> 01:31:05.360 zu konzentrieren und man als chrome ja irgendwie für alle irgendwie eine 01:31:05.360 --> 01:31:09.560 extra wurspraten muss was rein von den ressourcen die sicherlich leisten 01:31:09.560 --> 01:31:14.040 können aber es macht ihnen halt auch nicht leichter ja wir werden sehen wie es 01:31:14.040 --> 01:31:18.360 weitergeht ja also ich bin jetzt ja nun wirklich nicht die apfeltasche vom 01:31:18.360 --> 01:31:25.720 dienst oder halte jetzt da apple und safari für die guten aber ich würde 01:31:25.720 --> 01:31:30.760 ihnen trotzdem wünschen dass sie da am leben bleiben und er bringt ja was ich 01:31:30.760 --> 01:31:34.000 meine wir haben ja hier mehrfach gesagt so geht jetzt in safari aber firefox 01:31:34.000 --> 01:31:38.440 kann es nicht hier noch nicht implementiert dann auch nicht fertig ja es 01:31:38.440 --> 01:31:41.920 gibt halt einfach bestimmte bereiche da sind die einfach stark unter anderen 01:31:41.920 --> 01:31:45.920 sind die halt nicht so stark ich würde sagen so so web api sind die 01:31:45.920 --> 01:31:50.280 talsinell eigentlich eher nicht so besonders stark und aber so rendering 01:31:50.280 --> 01:31:55.040 gezeugs und sowas da sind die ja echt immer vorne weg ja css und so es ist 01:31:55.040 --> 01:31:57.080 ja wirklich 01:31:57.080 --> 01:32:01.120 schon gut also ja machen sie gut so sollen sie weiter machen ich wünsche mir 01:32:01.120 --> 01:32:05.360 auch dass sie weiter machen damit die zukunft nicht eine komplette monokultur 01:32:05.360 --> 01:32:13.720 wird ja mal sehen wie es in der revision 750 dann ausschaut ich mache mir 01:32:13.720 --> 01:32:20.720 ein kalender wieder treffen super dann danke schön ich habe so dann vielen 01:32:20.720 --> 01:32:26.960 dank an die höheren und höherer fürs zuhören wie von erwähnt wenn ihr 01:32:26.960 --> 01:32:31.440 input habt oder fragen zum beispiel zu der grid implementation die ich 01:32:31.440 --> 01:32:37.280 gemacht habe dann haben wir jetzt eben dieses draft community was quasi von 01:32:37.280 --> 01:32:41.280 der landing page ist wo ihr dann in unseren slack kommt und da sind auch 01:32:41.280 --> 01:32:45.360 andere höheren und höherer drin also wenn ihr möchtet schaut da vorbei oder 01:32:45.360 --> 01:32:49.080 schickt uns eine mail an comments at working graph die oder ihr findet uns 01:32:49.080 --> 01:32:51.760 natürlich auf twitter und 01:32:51.760 --> 01:32:58.240 was so dann genau und bevor wir hier Schluss machen haben wir noch 01:32:58.240 --> 01:33:01.440 eine sache vergessen wir wollen nämlich noch dem hanes danken der ist nämlich 01:33:01.440 --> 01:33:09.760 unser neuster pattern patron vielen dank für deine unterstützung und bleibt 01:33:09.760 --> 01:33:15.000 noch zu sagen wir hören uns nächste woche da geht es wahrscheinlich um nochmal 01:33:15.000 --> 01:33:21.920 um ausbildungswege zum webenwickler und webenwicklerin genau hatten wir ja schon 01:33:21.920 --> 01:33:27.640 mal glaube ich ist um studium und so und das nächste mal wollen wir mal den 01:33:27.640 --> 01:33:32.680 anderen weg dahin beleuchten wenn alles klappt und nicht wieder irgendwelche 01:33:32.680 --> 01:33:41.840 krankheiten dazwischen kommen die bei der revision 557 also bis nächste 01:33:41.840 --> 01:34:11.280 woche macht es gut ist dahin tschüss tschüssi
Kommentare
Noch keine Kommentare oder Backlinks.
RSS-Feed zu diesem Beitrag
Kommentare sind für diesen Beitrag geschlossen.