W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2015

Re: Custom Elements: is=""

From: Erik Isaksen <nevraeka@gmail.com>
Date: Mon, 15 Jun 2015 06:47:08 -0400
Message-ID: <CA+owco=ftNxActusoBJN5MBPsDLhtkX_Htb5GhQKvVLKAUm3sg@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:27:31 UTC