Re: [w3c/webcomponents] Need callback for form submit data (#187)

My findings from implementatoin experience:

* UA should support ```:invalid``` and ```:valid``` pseudo classes for form-associated custom elements
  Because ```ElementInternals``` has ```setValidity()``` operation, UA knows validity state of a form-associated custom element precisely.  UA can support ```:invalid``` and ```:valid``` without additional API for pseudo class matching

* UA should support ```:enabled``` and ```:disabled``` pseudo classes for form-associated custom elements
  The proposal has ```"disabledStateChangedCallback"``` because of complexity of ```<fieldset disabled>``` in ancestors.  UA needs to track disabled state of form-associated custom elements precisely.  So, UA can support ```:enabled``` and ```:disabled``` without additional API for pseudo class matching.

* Form-associated custom elements should not support form-association by HTML parser. (step 12 of [create an element for a token](https://html.spec.whatwg.org/multipage/parsing.html#create-an-element-for-the-token))
  If a parsed element looks to be a custom element but it is not defined yet or it will be upgraded later, HTML parser can't know whether it's a form-associated custom element or not.  Storing 'form element pointer' in each of undefined elements isn't reasonable.  IMO form-associated custom elements should not support form-associated by HTML parser for consistency.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/187#issuecomment-446939319