Re: Custom Elements: is=
On 14 June 2015 at 01:41, Patrick H. Lauke re...@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/ b
Re: Custom Elements: is=
On 12 June 2015 at 21:26, Tobie Langel to...@codespeaks.com 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? b
Re: Custom Elements: is=
On 13 June 2015 at 15:30, Léonie Watson lwat...@paciellogroup.com 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) b
Re: Making ARIA and native HTML play better together
On 7 May 2015 at 06:43, Steve Faulkner faulkner.st...@gmail.com 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?) bruce
Re: Minimum viable custom elements
On 29 January 2015 at 19:48, Ryosuke Niwa rn...@apple.com 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 ... They 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? bruce
Re: Minimum viable custom elements
On 29 January 2015 at 14:54, Steve Faulkner faulkner.st...@gmail.com 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 https://rawgit.com/alice/web-components-demos/master/index.html 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 elements. 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. bruce
Re: Minimum viable custom elements
On 29 January 2015 at 19:09, Brian Kardell bkard...@gmail.com 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 platform. b
Re: Custom Elements: 'data-' attributes
On 7 May 2014 20:03, Ian Hickson i...@hixie.ch 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. Bruce
