Re: Custom Elements: is=

2015-06-15 Thread Bruce Lawson
On 14 June 2015 at 01:41, Patrick H. Lauke 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


Re: Custom Elements: is=

2015-06-13 Thread Bruce Lawson
On 12 June 2015 at 21:26, Tobie Langel wrote:
 I'm also concerned developers will mistakenly write:

 my-button is=button

 As it is much closer in form to what they want to achieve (see the
 extend=parent syntax I wrote earlier).

That's true (and I've done exactly this myself). But wouldn't

button extendedby=my-button

solve that?


Re: Custom Elements: is=

2015-06-13 Thread Bruce Lawson
On 13 June 2015 at 15:30, LĂ©onie Watson wrote:
 why not use the extends= syntax you mentioned?

 my-button extends=button attributesPush/my-button

because browsers that don't know about web components wouldn't pay any
attention to my-button, and render Push as plain text.

 Browsers that don't know about web components will fall back to
button with button
this-is-made-much-more-marvellous-by=my-button (or whatever)


Re: Making ARIA and native HTML play better together

2015-05-07 Thread Bruce Lawson
On 7 May 2015 at 06:43, Steve Faulkner wrote:
 On another thread recent thread, leonie and chaals [3] talked about adding
 behaviours to ARIA.

this makes sense, but (unless I'm inventing nonsense because I'm mad,
which is definitely possible), doesn't this describe the current
behaviour in many UAs anyway? (Or is the aim to record current
practice and mandate it in a spec?)


Re: Minimum viable custom elements

2015-01-30 Thread Bruce Lawson
On 29 January 2015 at 19:48, Ryosuke Niwa wrote:
  And we have a proposal to do both of these things: decorators [1]

yes, indeed. What is the status of decorators? Last I looked, it had
been removed from the web components umbrella, so I thought it had
been sent to a farm upstate, but I haven't been following its progress
particularly closely.

 One more thing.  I would really like if we could stop making claims such as
 web components as currently spec'ed magically improves accessibility because
 it's doing a huge disservice to the future of the Web accessibility.

I'm not certain anyone has made the claim that anything's magically
improved ...

 don't.  Far from it.  I've pointed out numerous issues with them over the
 last couple of years but none of them have been adequately addressed.

could you provide a pointer to them, please?


Re: Minimum viable custom elements

2015-01-29 Thread Bruce Lawson
On 29 January 2015 at 14:54, Steve Faulkner wrote:
 I think being able to extend existing elements has potential value to
 developers far beyond accessibility (it just so happens that  accessibility
 is helped a lot by re-use of existing HTML features.)

I agree with everything Steve has said about accessibility. Extending
existing elements also gives us progressive enhancement potential.

Try in
Safari or IE. The second column isn't functional because it's using
brand new custom elements. The first column loses the web componenty
sparkles but remains functional because it extends existing HTML

There's a similar story with Opera Mini, which is used by at least
250m people (and another potential 100m transitioning on Microsoft
feature phones) because of its proxy architecture.

Like Steve, I've no particularly affection (or enmity) towards the
input type=radio is=luscious-radio syntax. But I'd like to know,
if it's dropped, how progressive enhancement can be achieved so we
don't lock out users of browsers that don't have web components
capabilities, JavaScript disabled or proxy browsers. If there is a
concrete plan, please point me to it. If there isn't, it's
irresponsible to drop a method that we can see working in the example
above with nothing else to replace it.

I also have a niggling worry that this may affect the uptake of web
components. When I led a dev team for a large UK legal site, there's
absolutely no way we could have used a technology that was
non-functional in older/proxy browsers.


Re: Minimum viable custom elements

2015-01-29 Thread Bruce Lawson
On 29 January 2015 at 19:09, Brian Kardell wrote:
 composition actually seems to let you express something equally good without
 ambiguity more easily except insofar as giving you a really first-class
 fallback option if you don't support JS, but... I'm having a really hard
 time imagining more than 3-4 cases  where that's really a useful thing.

I'm thinking of all the HTML elements that people feel compelled to
recreate with div soup and JS  (some of this is because the CSS hooks
don't exist, but I doubt we could ever define all conceivable CSS
hooks, but that's another story).

 The canonical example is button but input type=date
is=fab-calendar ; input type=range is=rotary-knob; input
type=checkbox is=woot-checkbox !-- OMG the checkmark spills
outside the box and it's in corporate magenta and indigo! --

All of these degrade very nicely and work even when JS isn't present,
whereas woot-checkbox and fab-calendar don't.

I'd also very much like to do nav is=glorious-accordian etc.

a really first-class fallback option if you don't support JS is
vital for the quarter of a billion people who use Opera Mini and the
100 million people who use the Nokia proxy browser. Fallback rather
than non-functional pages is vital for the people who don't use latest
greatest Chromium or Gecko browsers.

Sure, not everyone will do this. But not everyone puts alt text on
images; that's not an argument for removing img alt from the

Re: Custom Elements: 'data-' attributes

2014-05-08 Thread Bruce Lawson
On 7 May 2014 20:03, Ian Hickson wrote:

 Requiring a dash is pretty ugly. I would allow any attribute, and we'll
 just have to be careful when introducing new global ones.

I think the ship HMS Ugly has already sailed, given a dash is
compulsory for the names of custom elements. Also, requiring a dash in
the names of custom attributes would establish an easily-memorable
convention for authors, and safeguard new global attributes.