- From: Ole Ersoy <notifications@github.com>
- Date: Tue, 07 Mar 2017 23:19:40 -0800
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/509/284966400@github.com>
It looks reasonable, but I'm not sure about the: > what these extend and what primitive behaviors they use. It would be nice to see one full blown implementation of one of these things. For example for `<flexy-img>` - What part of the current image API does that use? The other part to this is that in the simplest scenarios these things sound great. But what if we have a <flexy-img-table> that uses the image api and the table api ... ? It seems to me that the naming of the element and what services it offers should be two distinct / orthoganol concerns. As an example I'm playing around with button designs using the [superfly-css](https://github.com/superfly-css/superfly-css) framework. Here's an example of a button design: ``` html <a class="Button u-text-color-white u-font-open-sans u-background-color-444 u-border-color-222 u-on-active-invert-100 u-font-weight-300 u-font-size-500">booyakasha </a> ``` This turns an `<a>` element into a button with a whole bunch of css customizations based on the utilities that are being applied. For example if I wanted the ripple effect that part of the custom elements v1 tutorial document I would drop in `u-ripple-effect` as one of the classes, and if that type of css is supported by the browser, or by a polyfill, it works if not, no biggie. The anchor element is still there. We could take the view that each css utility being applied is the API of an element. So if were were to extend that concept to the design of elements we would end up with really long element names. -- 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/509#issuecomment-284966400
Received on Wednesday, 8 March 2017 07:20:15 UTC