Re: CFC: Request to move HTML5.1 to Candidate Recommendation (CR)

aye - (as TPG WG person) -- Regards SteveF Current Standards Work @W3C On 2 June 2016 at 13:48, Léonie Watson wrote: > Hello WP, > > This is a call for consensus to request that W3C publish the current

Re: Notes from the future of HTML session at TPAC

As I couldn't be there and have some interest in the outcome I wrote down my thoughts: Thoughts on “Notes from the future of HTML session at TPAC” https://medium.com/@stevefaulkner/thoughts-on-notes-from-the-future-of-html-session-at-tpac-1c2f6f204cea#.vx45e5aeo -- Regards SteveF Current

Re: Reminder regarding normative references

On 7 October 2015 at 08:15, Mike West wrote: > As a concrete example, I'm going to send a transition request for Secure > Contexts shortly. It uses the "creation URL" concept which was recently > added to WHATWG's HTML ( >

Re: Making ARIA and native HTML play better together

On 9 May 2015 at 22:22, Alice Boxhall aboxh...@google.com wrote: 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

Re: Making ARIA and native HTML play better together

On 7 May 2015 at 07:53, Bruce Lawson bru...@opera.com wrote: 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? Currently ARIA does not do this stuff AFAIK. There is some limited

Re: Custom Elements: is=

On 6 May 2015 at 14:25, Anne van Kesteren ann...@annevk.nl wrote: I think we reached rough consensus at the Extensible Web Summit that is= does not do much, even for accessibility. I agree on one level, it does not do a lot for accessibility because the issue of styling native elements still

Fwd: Making ARIA and native HTML play better together

Forwarding on as this relates to custom elements which use ARIA to provide semantics -- Regards SteveF -- Forwarded message -- From: Steve Faulkner faulkner.st...@gmail.com Date: 7 May 2015 at 06:42 Subject: Making ARIA and native HTML play better together To: HTMLWG WG public

Re: Minimum viable custom elements

this turned up today: A possible solution for web component subclasses https://github.com/JanMiksovsky/base-template#a-possible-solution-for-web-component-subclasses needs people who actually understand this stuff to critique ;-) -- Regards SteveF HTML 5.1

Re: Minimum viable custom elements

On 12 February 2015 at 10:58, Anne van Kesteren ann...@annevk.nl wrote: which is a very different problem from what you want to solve, no? The problem I think needs solving for minimum viable custom elements is reducing reliance on bolt-on accessibility. From the example provided

Re: Minimum viable custom elements

On 4 February 2015 at 16:51, Ryosuke Niwa rn...@apple.com wrote: my-custom-formatterinput/my-custom-formatter I think if this worked. i.e. hid the styling and allowed styling over top, while allowing access to the input functionality would be a good solution for the many many instances of

Re: Minimum viable custom elements

On 4 February 2015 at 19:05, Alice Boxhall aboxh...@google.com wrote: 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? I suggest as in the working canvas example i provided, it not only be exposed AT but also to keyboard

Re: Minimum viable custom elements

, Steve Faulkner faulkner.st...@gmail.com wrote: I have not suggested is= as the method that must be implemented (I have not demanded anything), what I have tried to suggest is that minimum viable custom elements with all accessibility as bolt-on is a poor solution by design. From an acc

Re: Minimum viable custom elements

...@annevk.nl wrote: On Thu, Jan 29, 2015 at 3:54 PM, Steve Faulkner faulkner.st...@gmail.com wrote: I don't have enough technical understanding to know what is viable or not, you and others are saying that the current accessibility feature support baked in to custom elements spec via

Re: Minimum viable custom elements

hi ted, I think others have responded to your question, but wanted to chip in. I agree that for non interactive elements the usefulness of type extensions is limited, but not useless. For example: An experiment subclassing footer [5] and one implementing the HTML5 outline algorithm [6] There has

Re: Minimum viable custom elements

On 16 January 2015 at 10:25, Steve Faulkner faulkner.st...@gmail.com wrote: https://rawgit.com/alice/web-components-demos/master/index.html apologies, this demo needs chrome to illustrate it working well. -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/

Re: Minimum viable custom elements

than divs with fancy names. -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 16 January 2015 at 13:16, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Jan 16, 2015 at 11:25 AM, Steve Faulkner faulkner.st...@gmail.com wrote: With custom tags everything must

Re: Minimum viable custom elements

On 14 January 2015 at 14:45, Anne van Kesteren ann...@annevk.nl wrote: t also does not address subclassing normal elements. Again, while that seems desirable Given that subclassing normal elements is the easiest and most robust method (for developers) of implementing semantics[1] and

pull request on custom elements spec

Hi Dimitri, made quite a few tweaks to the custom element semantics section after feedback. Appreciate a review of the PR https://github.com/w3c/webcomponents/pull/31 when you get a chance. -- Regards SteveF

Re: custom elements without the dash

articulated (in the spec?). -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 5 January 2015 at 13:51, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jan 5, 2015 at 2:42 PM, Steve Faulkner faulkner.st...@gmail.com wrote: Why force hyphen in custom elements? It's

Re: custom elements without the dash

On 5 January 2015 at 13:59, Jirka Kosek ji...@kosek.cz wrote: Since there are no namespaces (in XML sense) in HTML language prefixes are used instead as a mechanism to prevent clash with future standardized element names. I understand why, its the zillions of developers out there who don't

Re: custom elements without the dash

Kesteren ann...@annevk.nl wrote: On Mon, Jan 5, 2015 at 3:03 PM, Steve Faulkner faulkner.st...@gmail.com wrote: I understand why, its the zillions of developers out there who don't or don't care, either they are given good reasons not to do it in language they understand and is meaningful

custom elements without the dash

brought up on a twitter thread https://twitter.com/johnslegers/status/552064145399767040 Why force hyphen in custom elements? See alternative approach at http:// mdo.github.io/mdoml/ http://t.co/V73nupEc8E and https:// github.com/mdo/mdoml/issues/7 … https://t.co/kJGNmaBOp7. NOTE I am not

Re: Custom Element Semantics

it and give this sentence as an example. It'd be good to mention other ARIA button related attributes. Thanks. Alexander. On Tue, Dec 9, 2014 at 4:23 AM, Steve Faulkner faulkner.st...@gmail.com wrote: Hi PF! FYI I have been getting some accessibility related content into the custom elements

Re: PSA: publishing new WD of Custom Elements on December 16

Hi Art, I don't have any objection to publishing as is. Would like to note that I have pretty much completed the first draft of the custom element semantics stuff now http://stevefaulkner.github.io/webcomponents/spec/custom/#semantics and have filed a pull request

Re: [custom-elements] Re: web developer conformance requirements and advice in custom elements spec

On 8 December 2014 at 16:37, Dimitri Glazkov dglaz...@google.com wrote: Totally. Happy to review/accept patches. Great! PR https://github.com/w3c/webcomponents/pull/26 forked http://stevefaulkner.github.io/webcomponents/spec/custom/#semantics -- Regards SteveF HTML 5.1

web developer conformance requirements and advice in custom elements spec

Hi all, looking at the custom elements spec http://w3c.github.io/webcomponents/spec/custom/ i realized it includes no defined requirements or advice for web developers on creation of custom elements that are meaningful and expose useful semantics and behavior. I would like to take a stab at

Re: [Custom] Custom elements and ARIA

being very wrong on a public mailing list :) don't worry same thing happens to me all the time. From: Steve Faulkner faulkner.st...@gmail.com It appears (please correct me) you have made the assumption that 'strong native semantics' for roles is a UA requirement? This is not the case