On Oct 6, 2014, at 10:21 AM, Jarek Foksa ja...@foksa.name wrote:
On 2014-10-06, at 18:24, James M. Greene james.m.gre...@gmail.com wrote:
This only thing about this approach that is slightly inconsistent with the
rest of the Web Platform is assuming that the `this` context within the
Hi Jarek,
What I learned from people around me is that these names have Callback
suffixes because
- to indicate that it is for a callback function and not a callable API
- it is low-level API and had to use non-trivial name
So even it doesn't seem to add any information, the suffix has some
I feel like they are more like Lifecycle Hooks or Lifecycle Phases... So
naming would make more sense as createdPhase or createdHook
- Matthew Robb
On Mon, Oct 6, 2014 at 11:08 AM, Jarek Foksa ja...@foksa.name wrote:
On 2014-10-06, at 12:32, Takayoshi Kochi (河内 隆仁) ko...@google.com
wrote:
I admittedly haven't been following the Custom Elements spec, so forgive if
my point of view has already been discussed and rejected but... I
definitely agree that this naming seems very inconsistent with the rest of
the Web Platform.
I would have expected to have these handlers configured via
On 2014-10-06, at 18:24, James M. Greene james.m.gre...@gmail.com wrote:
This only thing about this approach that is slightly inconsistent with the
rest of the Web Platform is assuming that the `this` context within the
handler will be set to the element, rather than being forced to grab it
Custom elements spec defines following lifycycle callbacks:
- createdCallback()
- attachedCallback()
- detachedCallback()
- attributeChangedCallback()
I'm wondering what was the reasoning behind the naming convention used here, it
feels verbose and inconsistent with the rest of the Web
