- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Thu, 1 Oct 2015 09:01:56 +0200
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: "www-style@w3.org" <www-style@w3.org>, Domenic Denicola <d@domenic.me>
On Wed, Sep 30, 2015 at 7:56 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > Personally, I think not. A well-designed custom element with similar > functionality should either throw upon setting an unrecognized value, > silently ignore the set, or ignore what you're trying to set and > instead just set it to the default value. <input> is a legacy mistake > with the worst possible behavior - accepting the set with any value, > but interpreting it as something else. I'm okay with it being > annoying to deal with. Every enumerated attribute in HTML works this way. And just as it is not done for HTML elements to modify the DOM without API action, so too should it be for custom elements. If we want custom elements to behave consistently anyway. I do agree that <input> is an especially poor element to base your custom element on. Way too overloaded. And I also agree that creating a generic CSS solution here might be hard (without enumerating all values in CSS somehow) so that's probably not worth it. -- https://annevankesteren.nl/
Received on Thursday, 1 October 2015 07:02:28 UTC