BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Sabre//Sabre VObject 4.5.8//EN
CALSCALE:GREGORIAN
LAST-MODIFIED:20241002T114751Z
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
X-MICROSOFT-CDO-TZID:13
BEGIN:STANDARD
DTSTART:20231105T090000
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
END:STANDARD
BEGIN:STANDARD
DTSTART:20241103T090000
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
TZNAME:PST
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20240310T100000
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
TZNAME:PDT
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:a9540089-cb3a-413b-966a-8c1034b31b11
DTSTAMP:20241002T114751Z
SUMMARY:Integrating UI components is too damn hard!
DTSTART;TZID=America/Los_Angeles:20240925T144500
DTEND;TZID=America/Los_Angeles:20240925T154500
DESCRIPTION:https://www.w3.org/events/meetings/a9540089-cb3a-413b-966a-8c10
34b31b11/\n\nThe vision of authors being able to drop components and UI li
braries into their pages and have things Just Work™ and look right (at l
east to a first order approximation) is still largely unrealized. Integrat
ing any UI component is incredibly laborious\, as it requires manually com
municating fine grained design tokens to every single component.\n\nThis [
Web Awesome](https://www.kickstarter.com/projects/fontawesome/web-awesome)
tutorial illustrates the problem perfectly: \n\nhttps://youtu.be/JhfYeXLf
WdI?si=vF3xRai2QrjabVFv&t=277\n\n
\n\nAnd this is just for assigning a certain hue as the primary co
lor of a whole page — the effort is duplicated for every third-party UI
component that uses colors\, fonts\, measurements\, font sizes\, etc. Same
-party components can use the same naming convention to reduce effort\, bu
t that doesn't work for components from different entities.\n\nTo reduce i
ntegration effort\, we need to reduce the amount of information the host p
age needs to communicate about its design to each individual component. So
me avenues are:\n1. standardized ways to set design tokens (e.g. the page
’s primary color or serif font) in a way that can be read by other compo
nents\n2. ways to _derive_ tokens from core tokens (e.g. a light tint from
a primary color\, or the next smaller font size in a scale) to minimize h
ow many tokens need to be communicated.\n3. Ways for components to adopt a
nd repurpose page styles of existing (standard) elements\n4. ???\n\nAgenda
\n\n**Chairs:**\nLea Verou\, Keith Cirkel\n\n**Description:**\nThe vision
of authors being able to drop components and UI libraries into their pages
and have things Just Work™ and look right (at least to a first order ap
proximation) is still largely unrealized. Integrating any UI component is
incredibly laborious\, as it requires manually communicating fine grained
design tokens to every single component.\n\nThis [Web Awesome](https://www
.kickstarter.com/projects/fontawesome/web-awesome) tutorial illustrates th
e problem perfectly: \n\nhttps://youtu.be/JhfYeXLfWdI?si=vF3xRai2QrjabVFv&
t=277\n\n
\n\nAnd this is
just for assigning a certain hue as the primary color of a whole page —
the effort is duplicated for every third-party UI component that uses colo
rs\, fonts\, measurements\, font sizes\, etc. Same-party components can us
e the same naming convention to reduce effort\, but that doesn't work for
components from different entities.\n\nTo reduce integration effort\, we n
eed to reduce the amount of information the host page needs to communicate
about its design to each individual component. Some avenues are:\n1. stan
dardized ways to set design tokens (e.g. the page’s primary color or ser
if font) in a way that can be read by other components\n2. ways to _derive
_ tokens from core tokens (e.g. a light tint from a primary color\, or the
next smaller font size in a scale) to minimize how many tokens need to be
communicated.\n3. Ways for components to adopt and repurpose page styles
of existing (standard) elements\n4. ???\n\n**Goal(s):**\nFlesh out ideas f
or potential directions\, see which are most viable in terms of I/E\n\n\n*
*Agenda:**\n1. Discuss requirements and potential directions\n2. Discuss r
elevant proposals:\n - https://github.com/w3c/csswg-drafts/issues/9992\n -
https://github.com/w3c/csswg-drafts/issues/9999\n - https://github.com/w3
c/csswg-drafts/issues/10452\n - https://github.com/w3c/csswg-drafts/issues
/9660\n - https://github.com/w3c/csswg-drafts/issues/10222\n - https://git
hub.com/w3c/csswg-drafts/issues/5900\n\n**Materials:**\n- [minutes](https:
//github.com/w3c/csswg-drafts/issues/10948#issuecomment-2375445066)\n- [Se
ssion proposal on GitHub](https://github.com/w3c/tpac2024-breakouts/issues
/92)\n\n**Track(s):**\n- Web Components
STATUS:CONFIRMED
CREATED:20240916T220237Z
LAST-MODIFIED:20241002T114751Z
SEQUENCE:2
ORGANIZER;CN=W3C Calendar;PARTSTAT=ACCEPTED;ROLE=NON-PARTICIPANT:mailto:nor
eply@w3.org
LOCATION:-1 Lower Level - Catalina 7
CATEGORIES:TPAC 2024,Breakout Sessions
END:VEVENT
END:VCALENDAR