Incorporate Custom Elements in HTML directly?

[chaals]

Custom elements does not (in my opinion) seem like a good fit for a module, since it essentially impacts a number of different places in the specification rather than standing alone.

Should we integrate it directly - assuming sufficient interoperability, anticipating it for HTML 5.3?

Note this issue may become a formal CfC...

[LJWatson]

Background for this was posted to public-html@w3.org, and is reproduced below:

"Our approach thus far has been to maintain it as a separate specification. That has proven difficult to maintain, and it is largely a set of "monkey-patches" to HTML (and a few to DOM), pointing to various places throughout the specification where changes should be made to take account of custom elements. The chairs' proposal is to merge custom elements into the core HTML spec, beginning with HTML 5.3. As always Candidate Recommendations will be limited to features that we expect to show have interoperable implementation, with any doubt meaning a feature will be labeled at-risk and may be held off for a later version. This proposal has the short-term disadvantage that anyone trying to implement custom elements on top of an existing system, especially a browser or similar user agent, will have to look through the entire specification change history to be sure they have noted all the things they need to implement. We hope to mitigate this problem by continuing to publish changelogs that provide an effective quick guide to the things that have changed. In balancing the "priority of constituencies", merging custom elements into the HTML spec has the benefit that anyone reading the specification will learn about custom elements at the same time, rather than having to read two specifications in parallel. We would like to further modularise the HTML spec, but custom elements does not seem like a good candidate to continue as a stand-alone module. Merging the specifications also has the medium-term benefit of simplifying maintenance - while the discussion and resolution of issues continues, that aspect has been falling steadily behind.">

[ZoeBijl]

If it does indeed impact various sections of the base spec than it’d make a lot of sense to incorporate it.

[dwsinger]

in this case, I think it makes sense. Custom Elements are entangled into HTML (and WhatWG have integrated).

But the HTML spec. is already unwieldy, really, and making it larger and larger is not a great direction. We should explore making the HTML spec. more modular. Integrate the things that are deeply entangled with the spec., separate into modules things that are layered on it (roughly).

[cwilso]

Is there someone planning to maintain this area in the spec, then? Currently Domenic occasionally takes a snapshot of the relevant parts of the WHATWG specs (HTML&DOM), but I don't believe he is committed to doing any maintenance if it's rolled into HTML. Until that update path can be resolved, I believe Google would prefer to keep this outside the core spec.

[snuggs]

@cwilso what would maintenance entail? I've spent the past couple years of my life combing and watching the specs matriculate from V0 to V1 like a hawk. That said, I know contribution processes to orgs like WHATWG / W3C can be daunting at times to say the least. Perhaps a link to what that "path" would look like?

Thanks in advance. /cc @brandondees

[chaals]

@snuggs if you are (or anyone else reading is) interested in taking on the task, there are two parts to the path, the "bureauracy" of getting on it, and the day to day work.

The "bureaucracy" involved is becoming a member of the Web Platform Working Group - if you are not sponsored by a W3C member organisation, that means satisfying the requirements for an invited expert (broadly, you're not working for someone who has no reason not to join W3C and sponsor you, that you agree to follow W3C's code of conduct about being a reasonable constructive member of a community, and that you are invited. I'm happy to talk about the last bit offline). If you are sponsored by a W3C member, then you just get them to nominate you to the group. Either way, there is a commitment required to the W3C patent policy, which roughly means you promise not to put stuff into the spec and then try to charge licenses for it under a patent.

Then you can be appointed as an editor of the specification - that just means convincing the chairs (me, @LJWatson and @adrianba) that you will do the work at some reasonable rate.

The actual work is editing the specification in this HTML repository to incorporate stuff that is in the current ( and somewhat neglected :( ) custom elements specification, and decisions made by the group - e.g. as noted in the issues raised on it.

And as you may imagine, like being a chair, the pay for editing is that you get to do it, and if there is a need to travel or something you cover the cost yourself :S But you do get more gratitude from the chairs than we will manage to express, and perhapos teh satisfaction of doing a somewhat thankless task well.

[marcoscaceres]

So, the forking is again impacting things like ReSpec ☝️... If you haven't found someone to maintain Custom Elements, then that should be acknowledged and that work should stop at the w3c, no?

[chaals]

We now have @brucelawson agreeing to take responsibility to merge the work, and commitments to help him. We will raise a formal CfC.