Sasha Firsov@epa-wg/custom-element have closed the last significant bug and looks to me as good candidate for its first release.
It allows to make web app exclusively with HTML tags.
Next is Material UI components lib with Consumer Semantic Theming.
Cool chrome Dev Tools advance I filed a ticket for, now landed to Crome.
The form elements validation states now can be enforced.
It is a great addition to #DeclarativeCustomElement DX. and <custom-element> in particular. As it supports the native HTML error handling and styling.
https://developer.chrome.com/blog/new-in-devtools-129#specific-element-states
What's new in DevTools, Chrome 129 | Blog | Chrome for Developers
Search requests in Performance > Network, use test data in address forms with Autofill, export to Puppeteer for Firefox in the Recorder panel, spot performance issues at a glance with observations in the Performance panel, and more.
Material Design in XSLT 1st draft components: https://unpkg.com/@epa-wg/custom-eleme[email protected]/src/material/components/icon-link.html
@niutech , 💓 htmlz, the base for #PHOOOS . Interesting concept. Still needs some polishing towards pure DCE.
Till this moment I thought only
<custom-element> covers no-js patterns of #DeclarativeCustomElement
@niutech ,
Declarative Shadow DOM from https://web.dev/articles/declarative-shadow-dom
has nothing to do with Declarative syntax. It is still relying on JS to function. DCE would be the no-js answer.
As UI framework author I am looking for the enterprise quality OSS UI lib with sufficient components set for apps development ( has multiple themes, form inputs, complex components like DatePicker, translations).
It would be handy to get DOM structure and CSS for components instead of reinventing the wheel.
Do you have such kind of lib in mind?
Old Dojo Toolkit would fit the bill if not abandoned. PrimeNG perhaps?
HTML5 authors committed a crime against humanity.
Its parser so impossible to implement and change, that it became a bottleneck for expanding and evolving as the standard. It is a cause of zillions implementations, none of which conforming to the standard.
The epic antipattern in software development is the most popular concept in the digital world.
Is it worth to support #DeclarativeCustomElement (DCE) in HTML5? Or XHTML is the future?
@tag is the entity which is disfunctional. Think of it. There are 3 tiers in web stack: styles/css, logic/js, and composition/html dom. FIrst 2 have
* notion of external reusable modules
* scope
* variables and scope overriding
* referencess so resources are reused
The DOM is bare bone of web app and still is missing those essentials.
#DeclarativeCustomElement meant to cover those gaps. No interest from TAG so far.
Love the debates around #DeclarativeCustomElement in WCCG.
DCE gives some level of abstraction for composition. In same time it can provide extra layers of scope sharing and insulation, rendering across tiers(SSR, in-browser, etc.) with state sharing and hydration. The capabilities of those layers have to be discussed on its own but when it goes to syntax, have to be cross-fit.
The @w3ctag for some reason does not go to architecture question like those, so we have to pull it ourselves. #w3c
#DeclarativeCustomElement POC recovered the FireFox compatibility. One sper closer to release.
🤔 What reference implementation app would be sufficient for its 1st release?
Looking into Hugo themes and shopping cart...
As of now DCE is positioned as low-code, no-JS framework. But there is no barrier to extend it with JS-powered web components.
#WebDev #w3c
https://unpkg.com/@epa-wg/custom-eleme[email protected]/index.html
