Re: Custom Elements: is=

2015-06-13 Thread Alice Boxhall
Doc in progress at
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Type-Extensions.md

On Sat, Jun 13, 2015 at 8:50 AM, Dimitri Glazkov dglaz...@google.com
wrote:

 Folks,

 I agree with Anne that we've been having a somewhat circular re-discovery
 of the pros/cons here. I believe that the best way to address this is to
 capture all of these points in one doc -- this would be a just a little
 extra work for the current participants, but super awesome for the future
 folk.

 For example, Domenic started such a doc for another custom elements
 contentious bit:
 https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Why-Upgrades.md.
 Please help break the cycle of re-discovery :)

 :DG




Re: Custom Elements: is=

2015-06-09 Thread Alice Boxhall
On Tue, Jun 9, 2015 at 8:13 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Sun, May 10, 2015 at 12:34 AM, Alice Boxhall aboxh...@google.com
 wrote:
  - In the time between v1 and v2 (however long that ends up being) we are
  left without any way to solve this problem, assuming we don't come up
 with
  something else for v1. If developers start using custom elements where
 they
  would previously have used a native element, this could well result in a
  regression in accessibility for the web as a whole for this period, and
 we
  will be stuck with the legacy of code written during this period for much
  longer as well.

 I don't see how it is a regression compared to the current situation.


Exactly: this describes the current situation, which I think is
unsatisfactory.

 - I realise that to some extent developers already aren't using native
  elements, in part because of the styling issues we've discussed which
 also
  affect is=. My concern here is that custom elements will further
 legitimise
  this habit, which we've been making some recent progress in changing - we
  stand to backslide on that effort. Having is= would allow us to roll it
 into
  the use native elements where possible message rather than diluting it
  with unless you're using a custom element in which case here's a
 checklist
  which you're not going to look at of everything it should do until we
 come
  up with an alternative.

 Most examples of custom elements to date are not actually with is=,
 simply because custom tag names are much more appealing. The
 ergonomics don't back up the message.


Polymer have a whole suite of elements which use is=:
https://elements.polymer-project.org/browse?package=gold-elements

When you refer to ergonomics, are you talking purely about the syntax? Or
about the set of issues involved in using native elements compared to
(lower case c) custom elements: essentially, whether or not you're ceding
some control over styling and behaviour to the browser?

 - v1 sets the stage for people to develop habits and expectations about
 how
  custom elements work. New features tend to be slowly adopted, by both
  browser vendors and (partly as a consequence) developers, so even if we
 do
  come up with something for v2, it will be even longer before it becomes
  mainstream (and as I mentioned earlier we will still be stuck with code
  written to v1 for much longer again).

 I don't see how it will be longer. is= is not getting acceptance
 as-is. So all this would result in is not getting custom elements
 across browsers until v2 is done.


I think Dimitri responded to this better than I could.


  Here's where we differ, because:
  - I don't think it's a wart. I've given this a great deal of thought and
 I
  keep ending up back at the current syntax when I try to think of
 reasonable
  alternatives, even assuming we could magically fix all the implementation
  issues with any alternative proposal.

 I think if we figured out how the behavior of current elements is
 composed and how to address the styling problem we'd be much closer to
 an agreement. And I think everyone agrees those need to be solved, so
 I'm a bit lost as to why we don't focus on those.


I agree that those problems need to be solved (in particular, the styling
issue also comes into play when using is=), but I think that these are
multiple pieces of the same puzzle.

The primitives are critical for creating novel types of elements, which
won't be able to benefit from type extensions in any case. Styling is
critical for getting people to use native elements with or without type
extensions.

Allowing developers to extend native types means that *users* benefit from
not relying on custom element developers who just want to create a button
with some fancy rendering (beyond what can be achieved using CSS alone), or
custom behaviour, remembering to re-implement all of the accessibility
affordances which are built in to an HTML button. It also means that
*developers* benefit from not having to do the extra legwork for
accessibility.

We see time after time after time that accessibility is fighting an uphill
battle because it isn't on developers' radars as a priority for v1. This
causes constant regressions in functionality for people who rely on
assistive technology. The promise of the HTML platform is that it should be
accessible if we use the native elements as they were designed to be used.
Part of my day job is helping make sure that the browser I work on upholds
its part of that bargain.

You could argue that what we need is a way to wrap *all* of the
accessibility affordances of a button into a mix-in object; I really don't
see a much more efficient way to do that than extending a button element,
either in terms of creating the spec or in terms of using the object.

 - I don't think shipping in one browser is nothing. People (both
 framework
  authors and web page authors) are already writing code using is=.

 Well, I disagree. E.g. Microsoft

Re: Custom Elements: is=

2015-06-08 Thread Alice Boxhall
Did anyone have any further thoughts on this? My concerns haven't changed.

On Sat, May 9, 2015 at 3:34 PM, Alice Boxhall aboxh...@google.com wrote:

 On Thu, May 7, 2015 at 1:00 AM, Anne van Kesteren ann...@annevk.nl
 wrote:

 On Wed, May 6, 2015 at 6:59 PM, Alice Boxhall aboxh...@google.com
 wrote:
  I definitely acknowledge is= may not be the ideal solution to the latter
  problem - it definitely has some holes in it, especially when you start
  adding author shadow roots to things - but I think it does have
 potential.
  I'd really like to be convinced that we either have a reasonable
 alternative
  solution, or that it's not worth worrying about.

 I think it is worth worrying about, but I don't think it's worth
 holding up a minimal v1 of Custom Elements for. The way to get
 agreement among all parties is to do less. And then take baby steps
 from.


 I can definitely see that logic.

 My concerns with this in practice are:

 - In the time between v1 and v2 (however long that ends up being) we are
 left without any way to solve this problem, assuming we don't come up with
 something else for v1. If developers start using custom elements where they
 would previously have used a native element, this could well result in a
 regression in accessibility for the web as a whole for this period, and we
 will be stuck with the legacy of code written during this period for much
 longer as well.

 - I realise that to some extent developers already aren't using native
 elements, in part because of the styling issues we've discussed which also
 affect is=. My concern here is that custom elements will further legitimise
 this habit, which we've been making some recent progress in changing - we
 stand to backslide on that effort. Having is= would allow us to roll it
 into the use native elements where possible message rather than diluting
 it with unless you're using a custom element in which case here's a
 checklist which you're not going to look at of everything it should do
 until we come up with an alternative.

 - v1 sets the stage for people to develop habits and expectations about
 how custom elements work. New features tend to be slowly adopted, by both
 browser vendors and (partly as a consequence) developers, so even if we do
 come up with something for v2, it will be even longer before it becomes
 mainstream (and as I mentioned earlier we will still be stuck with code
 written to v1 for much longer again).


 The way I look at this is that currently you have nothing, since only
 Chrome ships this. There's a chance to get three more browsers if you
 make some concessions on the warts. And then hopefully we can iterate
 from there in a more cooperative fashion.


 Here's where we differ, because:
 - I don't think it's a wart. I've given this a great deal of thought and I
 keep ending up back at the current syntax when I try to think of reasonable
 alternatives, even assuming we could magically fix all the implementation
 issues with any alternative proposal.
 - I don't think shipping in one browser is nothing. People (both
 framework authors and web page authors) are already writing code using is=.


 (The thread Steve shared about ARIA seemed like an equivalent effort
 by the way, to expose some of the semantics of native elements through
 simple attributes.)


 Thanks for the pointer - I followed up on that thread with some thoughts
 on that proposal.



Re: Custom Elements: is=

2015-06-08 Thread Alice Boxhall
On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa rn...@apple.com wrote:


  On Jun 8, 2015, at 2:16 PM, Alice Boxhall aboxh...@google.com wrote:
 
  Did anyone have any further thoughts on this? My concerns haven't
 changed.

 Nothing new.

  On Sat, May 9, 2015 at 3:34 PM, Alice Boxhall aboxh...@google.com
 wrote:
  On Thu, May 7, 2015 at 1:00 AM, Anne van Kesteren ann...@annevk.nl
 wrote:
  On Wed, May 6, 2015 at 6:59 PM, Alice Boxhall aboxh...@google.com
 wrote:
   I definitely acknowledge is= may not be the ideal solution to the
 latter
   problem - it definitely has some holes in it, especially when you
 start
   adding author shadow roots to things - but I think it does have
 potential.
   I'd really like to be convinced that we either have a reasonable
 alternative
   solution, or that it's not worth worrying about.
 
  I think it is worth worrying about, but I don't think it's worth
  holding up a minimal v1 of Custom Elements for. The way to get
  agreement among all parties is to do less. And then take baby steps
  from.
 
  I can definitely see that logic.
 
  My concerns with this in practice are:
 
  - In the time between v1 and v2 (however long that ends up being) we
 are left without any way to solve this problem, assuming we don't come up
 with something else for v1. If developers start using custom elements where
 they would previously have used a native element, this could well result in
 a regression in accessibility for the web as a whole for this period, and
 we will be stuck with the legacy of code written during this period for
 much longer as well.

 Web developers are already writing their own custom elements as a bunch
 of nested div's.  How does introducing custom elements make it worse?


I believe the rest of my comment already addressed this.


 The argument that it'll make things worse between v1 and v2 is moot
 because we haven't agreed on anything. is= syntax may never be realized due
 to various issues associated with it.


This was in response to Anne's suggestion to take baby steps. If this is
going to happen at all, I believe it needs to happen in V1 rather than
later, for the reasons I outlined.


  - I realise that to some extent developers already aren't using native
 elements, in part because of the styling issues we've discussed which also
 affect is=. My concern here is that custom elements will further legitimise
 this habit, which we've been making some recent progress in changing - we
 stand to backslide on that effort. Having is= would allow us to roll it
 into the use native elements where possible message rather than diluting
 it with unless you're using a custom element in which case here's a
 checklist which you're not going to look at of everything it should do
 until we come up with an alternative.

 In the case of stylizing elements, it doesn't really matter if authors
 attach a shadow DOM on top of a builtin input element or to a div because
 as soon as the shadow DOM replaces the rendered contents, we can't make
 assumptions about how to expose that element to AT.


That's simply not true at all. If someone replaces the rendered content of
a `button`, we know that their intent is to create an element which is
semantically a button, and may even be rendered as a button in some cases.
Similarly for `input` with a `type` attribute. This is no different to
using an ARIA role as far as assistive technology is concerned.


  The way I look at this is that currently you have nothing, since only
  Chrome ships this. There's a chance to get three more browsers if you
  make some concessions on the warts. And then hopefully we can iterate
  from there in a more cooperative fashion.
 
  Here's where we differ, because:
  - I don't think it's a wart. I've given this a great deal of thought
 and I keep ending up back at the current syntax when I try to think of
 reasonable alternatives, even assuming we could magically fix all the
 implementation issues with any alternative proposal.

 FWIW, we (Apple) definitely dislike is= syntax as currently (or formerly)
 spec'ed.


Any chance you could go into more detail on that? What exactly is it you
dislike about it?


  - I don't think shipping in one browser is nothing. People (both
 framework authors and web page authors) are already writing code using is=.

 Some developers are always going to use a feature only implemented by a
 single browser (ActiveX in Trident, NaCl in Chrome, current web components
 implementation in Chrome). In fact, why would any browser vendor ship a
 feature that's not going to be used by anyone? However, that doesn't mean
 the feature will be standardized or adopted by other browser vendors.


No, but unlike the first two examples, this is a proposed web standard.

Thanks,

Alice


Re: Custom Elements: is=

2015-06-08 Thread Alice Boxhall
On Mon, Jun 8, 2015 at 4:23 PM, Ryosuke Niwa rn...@apple.com wrote:


 On Jun 8, 2015, at 3:23 PM, Alice Boxhall aboxh...@google.com wrote:

 On Mon, Jun 8, 2015 at 3:12 PM, Ryosuke Niwa rn...@apple.com wrote:


  On Jun 8, 2015, at 2:16 PM, Alice Boxhall aboxh...@google.com wrote:
 Web developers are already writing their own custom elements as a bunch
 of nested div's.  How does introducing custom elements make it worse?


 I believe the rest of my comment already addressed this.


 Sorry, I don't follow.

  - I realise that to some extent developers already aren't using native
 elements, in part because of the styling issues we've discussed which also
 affect is=. My concern here is that custom elements will further legitimise
 this habit, which we've been making some recent progress in changing - we
 stand to backslide on that effort. Having is= would allow us to roll it
 into the use native elements where possible message rather than diluting
 it with unless you're using a custom element in which case here's a
 checklist which you're not going to look at of everything it should do
 until we come up with an alternative.

 In the case of stylizing elements, it doesn't really matter if authors
 attach a shadow DOM on top of a builtin input element or to a div because
 as soon as the shadow DOM replaces the rendered contents, we can't make
 assumptions about how to expose that element to AT.


 That's simply not true at all. If someone replaces the rendered content of
 a `button`, we know that their intent is to create an element which is
 semantically a button, and may even be rendered as a button in some cases.
 Similarly for `input` with a `type` attribute. This is no different to
 using an ARIA role as far as assistive technology is concerned.


 Perhaps I should have said we can't _always_ make assumptions about how
 to expose that element to AT.

 Consider creating a date picker in the time we haven't added type=date
 yet.  Inside the shadow DOM of this color picker may contain various
 buttons and controls to move between months and pick a date.  Treating the
 entire control as a text field will provide a very poor user experience.


Ah, I see what you're saying now, thanks for clarifying.

In this case, the custom element author can add semantic markup inside
Shadow DOM just as the browser does for a date picker currently - no
assumptions need to be made, since even in the case of type extensions the
Shadow DOM is available to the accessibility tree. I don't think it will
ever treat the entire control as a text field.


 All the use cases I can think of that let UA can safely make assumptions
 about the ARIA role of the element involves tweaking the appearance, which
 is better served by better styling mechanisms for form controls.


I don't think it's an either/or question between is= and styling mechanisms
for form controls. I actually think we need both.

  The way I look at this is that currently you have nothing, since only
  Chrome ships this. There's a chance to get three more browsers if you
  make some concessions on the warts. And then hopefully we can iterate
  from there in a more cooperative fashion.
 
  Here's where we differ, because:
  - I don't think it's a wart. I've given this a great deal of thought
 and I keep ending up back at the current syntax when I try to think of
 reasonable alternatives, even assuming we could magically fix all the
 implementation issues with any alternative proposal.

 FWIW, we (Apple) definitely dislike is= syntax as currently (or formerly)
 spec'ed.


 Any chance you could go into more detail on that? What exactly is it you
 dislike about it?


 See our replies on the topic on public-webapps.  I don't have a time to
 collect all our replies or restate all the problems we have with is=
 syntax.  (Perhaps I should put up a document somewhere to reference since
 someone brings up the same question every six months or so, and I'm getting
 sick and tried to even say that I don't have a time to re-iterate the same
 points over and over...)


If you did have time to put together such a document at some point, it
would be much appreciated!

I do absolutely realise that it's important to address the existing
concerns, but I've been having a really hard time trying to figure out
exactly what those are. (It's also unfortunately really difficult to search
for 'is=' when search engines strip out punctuation from search terms.)

  - I don't think shipping in one browser is nothing. People (both
 framework authors and web page authors) are already writing code using is=.

 Some developers are always going to use a feature only implemented by a
 single browser (ActiveX in Trident, NaCl in Chrome, current web components
 implementation in Chrome). In fact, why would any browser vendor ship a
 feature that's not going to be used by anyone? However, that doesn't mean
 the feature will be standardized or adopted by other browser vendors.


 No, but unlike the first two

Re: Custom Elements: is=

2015-05-09 Thread Alice Boxhall
On Thu, May 7, 2015 at 1:00 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Wed, May 6, 2015 at 6:59 PM, Alice Boxhall aboxh...@google.com wrote:
  I definitely acknowledge is= may not be the ideal solution to the latter
  problem - it definitely has some holes in it, especially when you start
  adding author shadow roots to things - but I think it does have
 potential.
  I'd really like to be convinced that we either have a reasonable
 alternative
  solution, or that it's not worth worrying about.

 I think it is worth worrying about, but I don't think it's worth
 holding up a minimal v1 of Custom Elements for. The way to get
 agreement among all parties is to do less. And then take baby steps
 from.


I can definitely see that logic.

My concerns with this in practice are:

- In the time between v1 and v2 (however long that ends up being) we are
left without any way to solve this problem, assuming we don't come up with
something else for v1. If developers start using custom elements where they
would previously have used a native element, this could well result in a
regression in accessibility for the web as a whole for this period, and we
will be stuck with the legacy of code written during this period for much
longer as well.

- I realise that to some extent developers already aren't using native
elements, in part because of the styling issues we've discussed which also
affect is=. My concern here is that custom elements will further legitimise
this habit, which we've been making some recent progress in changing - we
stand to backslide on that effort. Having is= would allow us to roll it
into the use native elements where possible message rather than diluting
it with unless you're using a custom element in which case here's a
checklist which you're not going to look at of everything it should do
until we come up with an alternative.

- v1 sets the stage for people to develop habits and expectations about how
custom elements work. New features tend to be slowly adopted, by both
browser vendors and (partly as a consequence) developers, so even if we do
come up with something for v2, it will be even longer before it becomes
mainstream (and as I mentioned earlier we will still be stuck with code
written to v1 for much longer again).


 The way I look at this is that currently you have nothing, since only
 Chrome ships this. There's a chance to get three more browsers if you
 make some concessions on the warts. And then hopefully we can iterate
 from there in a more cooperative fashion.


Here's where we differ, because:
- I don't think it's a wart. I've given this a great deal of thought and I
keep ending up back at the current syntax when I try to think of reasonable
alternatives, even assuming we could magically fix all the implementation
issues with any alternative proposal.
- I don't think shipping in one browser is nothing. People (both
framework authors and web page authors) are already writing code using is=.


 (The thread Steve shared about ARIA seemed like an equivalent effort
 by the way, to expose some of the semantics of native elements through
 simple attributes.)


Thanks for the pointer - I followed up on that thread with some thoughts on
that proposal.


Re: Making ARIA and native HTML play better together

2015-05-09 Thread Alice Boxhall
I agree we badly need the primitives, but it seems to me like there is
potentially an easier and maybe even bigger win in making it more
straightforward for developers to reuse existing patterns (like the one you
described for button earlier) than in explaining the existing patterns
and allowing developers to create new ones.

As Patrick pointed out, we can approximately explain these things today -
not perfectly, as you demonstrate, but we can achieve much the same
functionality with effort - but we've seen time and time again that
developers aren't going to that effort. If it were more straightforward to
do so, we would probably see some increase in compliance, but it would
still require understanding the existing patterns and knowing that the
effort needs to be made.

However, I'm on the fence about whether this proposal is the way forward
for that problem. On the one hand, many developers (including me) have an
expectation when they first encounter ARIA that it will magically affect
behaviour, so it seems like a good path of desire to go ahead and fulfill
that expectation.

On the other hand, as Dominic (with an i) pointed out, this has the
potential to break existing sites. We would need to experiment carefully to
figure out the interactions between existing code and the new behaviour.

Additionally, as it stands today ARIA is a useful tool for explaining the
the semantics side of HTML - we would need to solve a couple of problems
(semantics missing from ARIA and currently only available to native
elements, which should be straightforward to fix, and the issue of
sprouting ARIA described below), but overall it's a good starting point.
If we were to modify ARIA to be more than just purely semantic, we would
need to come up with a new mechanism to explain the semantic piece when
developing new patterns.

On Fri, May 8, 2015 at 5:53 AM, Domenic Denicola d...@domenic.me wrote:

 From: Patrick H. Lauke re...@splintered.co.uk

  Isn't that, in a way, what we currently have already?

 No, not quite.

  - default focusable: add tabindex=0

 This isn't default-focusable; this is just focusable. Default focusable
 means that, in the absence of a tabindex attribute, it is focusable---like
 a href and button, and unlike span or a.

  - activatable with certain key commands: define key command handlers
 yourself in JS

 This has a few issues. Notably, it doesn't accomodate different platform
 conventions for activation, and it doesn't correctly hook up default
 actions: if you do myAnchor.addEventListener(click, function (e) {
 e.preventDefault(); }), navigation will not occur, whereas if you hook up
 key command handlers to custom-a, myCustomAnchor.addEventListener(...)
 will not have the same effect.

  - announced by AT as a button: role=button

 The problem here is similar to that with tabindex. The attributes
 (tabindex, role, aria-description, etc.) are meant to allow web app authors
 to override the default values that a given component might have. A
 component author, on the other hand, should be able to set the default way
 in which their component is announced to screenreaders, even when there is
 no role attribute present. In other words, my-button should be announced
 as a button; we shouldn't require my-button role=button.


We should clarify that adding a role/state/value attributes in lifecycle
callbacks approximates the original intention - yes, it sprouts some ugly
attributes, but it doesn't require the web page author to type my-button
role=button.

One potential solution to the sprouting attributes problem which has been
discussed elsewhere is to use some variant of the Cascading Attribute
Sheets idea (http://www.xanthir.com/blog/b4K_0) - although that proposal
seems to just apply attributes directly on to the element; I'd prefer to
see it more like CSS where instead of sprouting style attributes
everywhere, matched rules affect only the *computed style* of the element,
which is overridden by explicit attributes.


Re: Custom Elements: is=

2015-05-06 Thread Alice Boxhall
On Wed, May 6, 2015 at 8:33 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Wed, May 6, 2015 at 4:46 PM, LĂ©onie Watson lwat...@paciellogroup.com
 wrote:
  My understanding is that sub-classing would give us the accessibility
 inheritance we were hoping is= would provide. Apologies if I've missed it
 somewhere obvious, but is there any information/detail about the proposed
 sub-classing feature available anywhere?

 It should fall out of figuring out HTML as Custom Elements. Apart from
 styling which I think we can solve independently to some extent that's
 the big elephant in the room.


As I see it there are two problems which is= could conceivably solve, which
seem to be being conflated:
- providing access to capabilities which so far only native elements have
(roles not captured by ARIA, forms behaviour, etc)
- allowing re-use of the bundled complete set of behaviours captured in
each element in the platform (what is focusable, what keyboard interactions
work, what happens on mobile vs. desktop, what semantic values are exposed
- essentially everything required in the HTML specs for that particular
element)

A solution to the first problem I agree should fall out of the HTML as
custom elements effort.

The second is the one I'm more concerned about falling off the radar: when
using a native button, you can be reasonably certain that it will adhere
to the HTML spec in behaviour; when using an x-button, you only have the
reputation of the custom element vendor to give you any sort of guarantee
about behaviour, and it could regress at any time.

I definitely acknowledge is= may not be the ideal solution to the latter
problem - it definitely has some holes in it, especially when you start
adding author shadow roots to things - but I think it does have potential.
I'd really like to be convinced that we either have a reasonable
alternative solution, or that it's not worth worrying about.


Re: Minimum viable custom elements

2015-02-04 Thread Alice Boxhall
So a web page author would write
x-slider min=-100 ... etc.

and then the custom element would sprout an input type=range ...etc
with the attribute values copied across? Then the web page author knows
nothing about the input element, so if they want to programmatically the
value of the custom element, they'd modify an attribute on it, rather than
the input, right? So you'd have to keep them in sync regardless.

On Wed, Feb 4, 2015 at 11:14 AM, Ryosuke Niwa rn...@apple.com wrote:


 On Feb 4, 2015, at 11:05 AM, Alice Boxhall aboxh...@google.com wrote:

 On Wed, Feb 4, 2015 at 11:01 AM, Brian Kardell bkard...@gmail.com wrote:


 On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall aboxh...@google.com
 wrote:

 On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa rn...@apple.com wrote:


 On Feb 4, 2015, at 10:12 AM, Brian Kardell bkard...@gmail.com wrote:

 On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman chrisb...@gmail.com
 wrote:

 Yeah, I had noted in that post that wrapping a native element with a
 custom element was an option - only drawback is that the markup isn't as
 terse (which is generally advertised as one of the selling points of 
 Custom
 Elements). But that doesn't seem like a deal breaker to me, if subclassing
 needs to be postponed.

 Chris


 As I pointed out ealier:

 input is=x-foo

 x-fooinput/x-foo

 seems like barely a ternseness savings worth discussing.


 Indeed.  Also, authors are used to the idea of including a fallback
 content inside an element after canvas and object elements and this fits
 well with their mental model.


 I'm just trying to get my head around this pattern. In this example,
 does the web page author or the custom element developer embed the input?
 And who is responsible for syncing the relevant attributes across? In
 reality, isn't this going to look more like

 x-checkbox checked=true
 input type=checkbox checked=true
 /x-checkbox

 or as a slightly contrived example,

 x-slider min=-100 max=100 value=0 step=5
 input type=range min=-100 max=100 value=0 step=5
 /x-slider

 Or does the custom element get its state from the embedded element?


 the custom element uses its contents as input and, in the simplest sense,
 just moves it or maps it during creation... In a more complicated world
 with something more like shadow dom (a separate topic) it might be
 'projected'


 It seems like it would have to be in the light DOM for things like labels,
 forms etc to work. So then how do we treat it as fallback content i.e.
 un-rendered, while allowing it to be accessible to to the AT layer?


 Since it's a fallback content, it would certainly be in the regular DOM
 even if we had shadow DOM.  FYI, this whole thread doesn't assume or
 preclude the existence of shadow DOM.  It is the responsibility for custom
 form elements users to put regular input elements inside them.

 - R. Niwa




Re: Minimum viable custom elements

2015-02-04 Thread Alice Boxhall
On Wed, Feb 4, 2015 at 11:01 AM, Brian Kardell bkard...@gmail.com wrote:



 On Wed, Feb 4, 2015 at 1:54 PM, Alice Boxhall aboxh...@google.com wrote:

 On Wed, Feb 4, 2015 at 10:36 AM, Ryosuke Niwa rn...@apple.com wrote:


 On Feb 4, 2015, at 10:12 AM, Brian Kardell bkard...@gmail.com wrote:

 On Wed, Feb 4, 2015 at 12:41 PM, Chris Bateman chrisb...@gmail.com
 wrote:

 Yeah, I had noted in that post that wrapping a native element with a
 custom element was an option - only drawback is that the markup isn't as
 terse (which is generally advertised as one of the selling points of Custom
 Elements). But that doesn't seem like a deal breaker to me, if subclassing
 needs to be postponed.

 Chris


 As I pointed out ealier:

 input is=x-foo

 x-fooinput/x-foo

 seems like barely a ternseness savings worth discussing.


 Indeed.  Also, authors are used to the idea of including a fallback
 content inside an element after canvas and object elements and this fits
 well with their mental model.


 I'm just trying to get my head around this pattern. In this example, does
 the web page author or the custom element developer embed the input? And
 who is responsible for syncing the relevant attributes across? In reality,
 isn't this going to look more like

 x-checkbox checked=true
 input type=checkbox checked=true
 /x-checkbox

 or as a slightly contrived example,

 x-slider min=-100 max=100 value=0 step=5
 input type=range min=-100 max=100 value=0 step=5
 /x-slider

 Or does the custom element get its state from the embedded element?


 the custom element uses its contents as input and, in the simplest sense,
 just moves it or maps it during creation... In a more complicated world
 with something more like shadow dom (a separate topic) it might be
 'projected'


It seems like it would have to be in the light DOM for things like labels,
forms etc to work. So then how do we treat it as fallback content i.e.
un-rendered, while allowing it to be accessible to to the AT layer?