- From: Erik Isaksen <nevraeka@gmail.com>
- Date: Mon, 15 Jun 2015 06:47:08 -0400
- To: lwatson@paciellogroup.com
- Cc: Bruce Lawson <brucel@opera.com>, "Patrick H. Lauke" <redux@splintered.co.uk>, Tobie Langel <tobie@codespeaks.com>, WebApps WG <public-webapps@w3.org>
- Message-ID: <CA+owco=ftNxActusoBJN5MBPsDLhtkX_Htb5GhQKvVLKAUm3sg@mail.gmail.com>
I agree with Anne. A stopgap could hinder cross browser development significantly (with regards to backwards compatibility & browser needs of clients). Does it gain enough for us to justify one? I am just joining the conversation now so please correct me if I missed something on 'is'. As far as naming goes, an 'extends' attribute with a prototype path seems to be the most intuitive for me. Using element names in the naming conventions to define inheritance is limiting. Eventually we would want to be able to support extending other custom elements (whether this happens in v1 or v2). Custom elements can have long names. For the most part I have seen elements with 2-3 hyphenated words but it is possible to have elements that are like 'crazy-long-awesome-button-thing' so extending this without an attribute reference might look like '<crazy-long-awesome-button-thing-my-fabulous-button>' where 'my-fabulous-button' is the new element namespace. Although this is a problem with 'is' or 'extends' as well, it is more intuitive to have some attribute reference to denote a change rather than a a long concatenated element name. On a side note, developers suck at naming generally speaking. On Mon, Jun 15, 2015 at 5:07 AM, Léonie Watson <lwatson@paciellogroup.com> wrote: > From: Bruce Lawson [mailto:brucel@opera.com] > Sent: 15 June 2015 09:46 > > On 14 June 2015 at 01:41, Patrick H. Lauke <redux@splintered.co.uk> wrote: > > it makes more sense to work on stylability of standard elements. > > I'd like to keep the is="" construct (or better name) in the knowledge > that it's a stopgap for v1, and put our energies we're currently expending > debating this into styling standard elements - which is currently being > considered http://dev.w3.org/csswg/css-forms/ > > Will leaving is= (or whatever we call it) in situ create backward > compatibility problems later on if/when it changes? > > That aside, concentrating efforts on styling native HTML elements makes a > lot of sense. > > > Léonie > > -- > Léonie Watson - Senior accessibility engineer > @LeonieWatson @PacielloGroup PacielloGroup.com > > > > > -- *Erik Isaksen * *Google Developer Expert HTML5 <https://developers.google.com/experts/people/erik-isaksen>* *The Web Platform Podcast <http://thewebplatform.libsyn.com/> Show Host* *ReadTheSource.io <http://ReadTheSource.io> Co-Host* *nevraeka@gmail.com <nevraeka@gmail.com>* *@eisaksen <https://twitter.com/eisaksen> * *The Web Platform Podcast Links* Twitter - https://twitter.com/thewebplatform Google Plus - https://plus.google.com/u/0/106965203807974584370 Stream/Web -http://thewebplatform.libsyn.com/ Facebook - https://www.facebook.com/thewebplatform iTunes - https://itunes.apple.com/us/podcast/the-web-platform-podcast/id899384794?mt=2 Stitcher - http://www.stitcher.com/podcast/the-web-platform-podcast YouTube (not all episodes available) - https://www.youtube.com/channel/UCjz3j22CyBpy6Qk5SL6UwcQ RSS - http://thewebplatform.libsyn.com/rss Github - https://github.com/thewebplatform *Read The Source: Open Source Companion Live Screencast* Twitter - http://hangouts.readthesource.io/ Google Plus - https://plus.google.com/105627089988168968277/ Youtube - https://www.youtube.com/channel/UCVqD-Rd1nMmvbvf-AvQvgZw Github - https://github.com/readthesource RSS - http://hangouts.readthesource.io/index.xml
Received on Monday, 15 June 2015 10:47:37 UTC