This approach seems to duplicate and redefine HTML

[cwilso]

I know this is relatively early; however, I'm very concerned by the approach taken here. It seems there is overlap and redefinition of the Web platform pieces themselves - as in, subsetting HTML+CSS+JS would be concerning, but this is defining elements like <image> all over again, in a way that is close to but not quite "the Web". (For example, the CSS and JS files are, presumably, automatically applied to the HTML file, since there's no mention of <LINK>, <STYLE> or <SCRIPT> support?). It also seems (from the inclusion of a <text> element) that the flow text model is very different from the normal HTML one as well. (what happens to text outside a <text>?)

I really think this should be defined in terms of custom elements, and default HTML/CSS/JS.

[cwilso]

I will also note this is explicitly counter to the charter of the Miniapps Working Group, which would make this problematic to move there.

(From their charter: "The Working Group will not:
Define new CSS functionality, syntax, processing or rendering models.
Define any specification that overlaps the existing normative specifications for browser-based APIs without a concrete plan to work with existing working groups.
Define changes to the existing HTML markup language and to the Document Object Model (DOM) specifications.")

[MichaelWangzitao]

I agree that this work should not redefine HTML. And it should harmonize with the MiniAPP charter. This draft is very early work to present the potential scope of some common UI components for existing MiniApp implementations. It references existing non-standard deployments which will be optimized in subsequent releases. And it requires a lot of discussions to optimize the UI scopes, parameters, events, etc. For the scope of this work please review the explainer( https://github.com/w3c/miniapp-components/blob/main/docs/explainer.md ), and I would like to maximize the reuse of existing HTML standards.

I know this is relatively early; however, I'm very concerned by the approach taken here. It seems there is overlap and redefinition of the Web platform pieces themselves - as in, subsetting HTML+CSS+JS would be concerning, but this is defining elements like all over again, in a way that is close to but not quite "the Web". (For example, the CSS and JS files are, presumably, automatically applied to the HTML file, since there's no mention of , <STYLE> or <SCRIPT> support?). It also seems (from the inclusion of a element) that the flow text model is very different from the normal HTML one as well. (what happens to text outside a ?)

I really think this should be defined in terms of custom elements, and default HTML/CSS/JS.

[tomayac]

+1 to @cwilso's points above.

I strongly urge the group (again) to check out work by Open UI, who have done a lot of research on components (e.g., checkboxes) and who have ongoing research (e.g., on tabs), where the MiniApps group's perspectives, feedback, and contributions would be very valuable.

[xfq]

See also w3c/miniapp-packaging#2

(I also made some markup changes to the original comment without changing the content.)

[xfq]

Discussions in yesterday's CG meeting: https://www.w3.org/2021/08/19-miniapp-minutes.html#t01

[espinr]

I agree with you @cwilso, @tomayac and @MichaelWangzitao. We have been discussing this for a long time (w3c/miniapp-packaging#2 also during TPAC), and we need to resolve it sooner than later. So, I'll share some thoughts here, so all the MiniApp vendors may indicate their preferences. I'd preferably go for the standard way.

Analyzing the current list of MiniApp essential elements, we can see a clear overlap between these and the (standard) HTML elements:

• Similar elements (or the same like <div>) with related semantics;
• Same attributes (id, style, class) for the same purpose;
• Supporting a subset of CSS;
• And with similar events (like [PointerEvents](https://www.w3.org/TR/pointerevents3/)).

Furthermore, as mentioned before, some elements with no equivalent standard (e.g., tabs or switch) are in incubation under the OpenUI CG.

So, why not use Web Components?

• Custom HTML Elements in the case of new elements
• HTML modules
• HTML templates
• Shadow DOM
• CSS

I'm collecting some of the challenges and potential immediate solutions using standards:

Challenge	Potential Solution
New elements, not included in the HTML specification (but somehow present in some web frameworks, like <swiper>, <tabs>, <switch>, <picker>…)	These elements could be defined using stand-alone Web Components, and Custom Elements. (+ collaboration with the OpenUI CG .)
Redefinition of elements (elements that are similar to HTML standards elements like <image>, <progress>, <text>, <input>, <video>, <canvas>, <slider>, <button>…)	If they are really different, the elements could extend the HTML elements (using inheritance)
Basic MiniApp components with a minimum set of non-standard attributes (e.g., disable, focusable..)	Creation of a basic, essential MiniappElement that extends the HTMLElement with the specific requirements (the base of all elements).
MiniApp events that are similar to existing standard ones (e.g., touchstart, touchend, etc.)	Adoption of the standard version as it is (in this case, PointerEvents) - only small changes in the implementations.
New events on the MiniApp components (e.g., longpress, swipe…)	Definition of new CustomEvents based on the standard DOM interfaces.
No specific features for accessibility in MiniApp	Applying these standards we will have this aspect covered.

MiniApps could have specific profiles of standard HTML, CSS, and DOM to fully align with the current (and upcoming) standards.

Are (any of) these ideas feasible?

[EisenbergEffect]

A few comments on the above:

• New Elements - This should definitely be handled by the already established OpenUI CG.
• Redefinition of Elements - This should also go through the OpenUI CG, which is chartered also with improving existing elements. I think we should avoid extending or creating alternate versions of existing elements. To the degree possible, we should improve the existing platform capabilities. OpenUI has a process around this.
• I think something like MiniappElement should be avoided at all costs. We don't want to bifurcate the Web Component ecosystem around MiniApps. If there are Web Component needs, then let's discuss those as general platform improvements with the Web Components CG.
• MiniApp Events - Please adopt existing standards around touch, etc. If there are deficiencies, I would like to see the MiniApps group work with the appropriate W3C group to fix/enhance these existing standards. Things like longpress and swipe can be built on top of low-level standard primitives. If there's a desire for these to be natively built-in, then let's do that as a general web standard please.