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

[Steve Faulkner]

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 HTML
> Working Draft (WD) as a Candidate Recommendation (CR). It has been posted
> to
> public-webapps@w3.org as the official email for this WG.
>
> Please reply to this thread on public-webapps@w3.org  no later than end of
> day on 10 June. Positive responses are preferred and encouraged, silence
> will be considered as assent.
>
> The current HTML5.1 WD [1] improves upon HTML5. It includes updates that
> make it more reliable, more readable and understandable, and a better match
> for reality. Substantial changes between HTML5 and HTML5.1 can be found in
> the spec [2].
>
> When a specification moves to CR it triggers a Call For Exclusions, per
> section 4 of the W3C Patent Policy [3]. No substantive additions can be
> made
> to a specification in CR without starting a new Call for Exclusions, so we
> will put HTML5.1 into "feature freeze". It is possible to make editorial
> updates as necessary, and features marked "At Risk" may be removed if found
> not to be interoperable.
>
> The following features are considered "at risk". If we cannot identify at
> least two shipping implementations, they will be marked "at risk" in the CR
> and may be removed from the Proposed Recommendation.
>
> keygen element. [issue 43]
> label as a reassociatable element [issue 109]
> Fixing requestAnimationFrame to 60Hz, not implementation-defined [issues
> 159/375/422]
> registerContentHandler [Issue 233]
> inputmode attribute of the input element [issue 269]
> autofill of form elements [issue 372]
> menu, menuitem and context menus. [issue 373]
> dialog element [issue 427]
> Text tracks exposing in-band metadata best practices [Issue 461]
> datetime and datatime-local states of the input element [Issue 462]
>
> Please share implementation details for any of these features on Github. To
> mark other features "at risk", please identify them by 10th June (ideally
> by
> filing an issue and providing a test case).
>
> At the same time we move HTML5.1 into CR, we plan to continue updating the
> Editor's Draft, and in the next few weeks we expect to post a Call for
> Consensus to publish it as the First Public Working Draft of HTML5.2, so
> improving HTML will continue without a pause. It also means that changes
> that didn't make it into
> HTML5.1 will not have long to wait before being incorporated into the
> specification.
>
> Léonie on behalf of the WP chairs and team, and HTML editors.
> [1] https://www.w3.org/TR/html51/
> [2] https://www.w3.org/TR/html51/changes.html#changes
> [3] https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion
>
> [issue 43] https://github.com/w3c/html/issues/43
> [issue 109] https://github.com/w3c/html/issues/109
> [issues 159/375/422] https://github.com/w3c/html/issues/159 and links
> [issue
> 233] https://github.com/w3c/html/issues/233
> [issue 269] https://github.com/w3c/html/issues/269
> [issue 372] https://github.com/w3c/html/issues/372
> [issue 373] https://github.com/w3c/html/issues/373
> [issue 427] https://github.com/w3c/html/issues/427
> [Issue 461] https://github.com/w3c/html/issues/461
> [Issue 462] https://github.com/w3c/html/issues/462
>
>
> --
> @LeonieWatson tink.uk Carpe diem
>
>
>
>
>

Re: Notes from the future of HTML session at TPAC

[Steve Faulkner]

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 Standards Work @W3C


On 28 October 2015 at 08:46, Léonie Watson 
wrote:

> Thanks to everyone for a useful and informative discussion. Minutes
> available from the following palces:
>
> Web:
> http://www.w3.org/2015/10/28-html-minutes.html
>
> Text:
> http://www.w3.org/2015/10/28-html-minutes.html,text
> Léonie
>
> --
> Senior accessibility engineer @PacielloGroup @LeonieWatson
>
>
>
>

Re: Reminder regarding normative references

[Steve Faulkner]

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 (
> https://html.spec.whatwg.org/multipage/webappapis.html#creation-url).
> That concept is not present in the W3C's HTML (nor is it clear to me how to
> get it added :) ). How do you suggest that we proceed?
>

hi mike, i think you will find your example is in the W3C HTML 5.1:

http://www.w3.org/TR/html51/webappapis.html#creation-url

not saying there aren't other examples that would be concrete.

--

Regards

SteveF
Current Standards Work @W3C

Re: Making ARIA and native HTML play better together

[Steve Faulkner]

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
 behaviour, so it seems like a good path of desire to go ahead and fulfill
 that expectation.


Hi Alice, I would not go so far as to call it a proposal ;-) it is just a
few ideas , mostly not thought out at this stage and definitley not to be
taken as a package.

I think idea 1 has the potential to be implemented without being overly
burdensome, so forgetting about the ideas for the moment:

1. When a role is used that matches the default implicit semantics of
 labelable HTML elements [1] use of the label element will result in the
 same behaviour as the native element and a label.
 Example:

 span role=checkbox id=customcheck/span label for=customchecki
 like this idea/label


What this would entail (i think ) is the addition of a defined set of roles
to the labelable elements list [1]. So when an element with one of the
defined roles is associated with a lable using the for attribute or as a
child of label, the behaviour matches that currently defined in HTML

The label element's exact default presentation and behaviour, in particular
 what its activation behaviour might be, if anything, should match the
 platform's label behaviour. The activation behaviour of a label element
 for events targeted at interactive content descendants of a label
 element, and any descendants of those interactive content descendants, must
 be to do nothing. [2]


labelable elements that have default implict ARIA semantics [3]

input type=checkbox - role=checkbox
input type=radio -  role=radio
input type=text - role=textbox
input type=number - role=spinbox
textarea - role=textbox
progress - role=progressbar
select - role=listbox or combobox

So the suggested implementation would be that where a role is used that
matches one in the list above, the association of a label element would
result in the same behaviour as it does for the corresponding HTML element
both interaction behaviour and accessble name association [4].


[1] http://www.w3.org/TR/html51/semantics.html#category-label
[2] http://www.w3.org/TR/html51/semantics.html#labeled-control
[3]
http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#html-element-role-mappings
[4]
http://rawgit.com/w3c/aria/master/html-aam/html-aam.html#accessible-name-and-description-calculation
--

Regards

SteveF

Re: Making ARIA and native HTML play better together

[Steve Faulkner]

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 keyboard
behaviour mapping for role=button in a few AT's.

--

Regards

SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/

Re: Custom Elements: is=

[Steve Faulkner]

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 remains. I don't quite understand
how sub-classing does not help accessibility, when in the cases of simple
controls that have added custom features, re-using a button or a checkbox
etc rather than buidling it from scratch appears to be useful for
accessibility and other reasons.

note: this is not an argument for is= :-)
--

Regards

SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/

Fwd: Making ARIA and native HTML play better together

[Steve Faulkner]

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-h...@w3.org
Cc: Chaals from Yandex cha...@yandex-team.ru, Léonie Watson 
lwat...@paciellogroup.com, Richard Schwerdtfeger sch...@us.ibm.com,
Alice Boxhall aboxh...@google.com


On another thread recent thread, leonie and chaals [3] talked about adding
behaviours to ARIA. Here are a few ideas:

1. When a role is used that matches the default implicit semantics of
labelable HTML elements [1] use of the label element will result in the
same behaviour as the native element and a label.
Example:

span role=checkbox id=customcheck/span label for=customchecki
like this idea/label

User able to click on label to check/uncheck

2. roles that match the default implicit semantics of interactive elements
are focusable (without need to explicitly set tabindex)

Example:
div role=buttonpress me/div

will be included in the focus order.

3. roles that match the default implicit semantics of interactive elements
[2] inherit the interaction behaviour of the native elements
example:

div role=buttonpress me/div
can be activated the same way a html button element can be:.
via space, enter ,click , touch or whatever.

Why? reduce manual labour of web devs. provide more consistent cross
browser behaviours for custom UI. Make custom UI more robust out of the box.

Review at your leisure, respond at will.

[1] http://www.w3.org/TR/html51/semantics.html#category-label
[2] http://www.w3.org/TR/html51/dom.html#interactive-content-2
[3]
https://lists.w3.org/Archives/Public/public-html/2015May/thread.html#msg0
--

Regards

SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/

Re: Minimum viable custom elements

[Steve Faulkner]

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 http://www.w3.org/html/wg/drafts/html/master/

On 14 January 2015 at 14:45, Anne van Kesteren ann...@annevk.nl wrote:

 I've been trying to think of the smallest setup that adds value, can
 get broad agreement, and is therefore hopefully interoperable fast.

 * ES6-style class syntax to declare the imperative constructor.
 * No subclassing of normal elements for now.
 * registerElement() to enable declarative syntax and createElement().
 * Parsing of declarative syntax invokes the registered constructor
 synchronously.
 * Existing lifecycle callbacks plus those agreed (copying, adopting).

 Notably this does not address upgrading. I think we can defer
 upgrading as it can be implemented in script fairly easily. You await
 for the imperative constructors to load and DOMContentLoaded at which
 point you traverse the tree and invoke replace() on those elements you
 want to upgrade. Ideally at some point we find a declarative solution
 for this, perhaps something like HTML modules, but shipping a v1 of
 custom elements in multiple browsers should not have to wait for that.

 It also does not address subclassing normal elements. Again, while
 that seems desirable the current ideas are not attractive long term
 solutions. Punting on it in order to ship a v1 available everywhere
 seems preferable.


 --
 https://annevankesteren.nl/

Re: Minimum viable custom elements

[Steve Faulkner]

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
http://janmiksovsky.github.io/base-template/ it appears that in this
instance it does achieve that end.

I don't know whether this will extend to other UI controls or whether it is
a practical solution, which is why I brought it to the list for discussion.

--

Regards

SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/

Re: Minimum viable custom elements

[Steve Faulkner]

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 native controls being remade as custom
controls simply to be able to control style.

I made a simple example of using canvas to host a checkbox, as an
experiment:
http://codepen.io/stevef/pen/OPxvZX

note: am not saying canvas is a solution, like is= it provides the
ability to make use of built in features of native controls. which is the
outcome I would like to see baked into web components.
--

Regards

SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/

Re: Minimum viable custom elements

[Steve Faulkner]

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 interaction, and that the content inside
can be targeted for relationships such as

label
x-checkbox
input type=checkbox checked=true
/x-checkbox
sign up
/label

--

Regards

SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/

Re: Minimum viable custom elements

[Steve Faulkner]

Anne wrote:

 but do you see a viable way to get there?


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 is= is not acceptable

To recap

What is= provides:
A way for developers take advantage of the built in roles,states and
properties of existing HTML elements without having to add ARIA to reflect
the acc properties and scripting to emulate behaviours (see what ARIA does
not do http://www.paciellogroup.com/blog/2014/08/what-aria-does-not-do/)
For example. putting aria-disabled=true on a button does not make the
element disabled like the ‘disabled’ attribute does (removes from tab order
etc), it just sets the disabled state flag in accessibility APIs.

So being able to do:
button is=”my-super-button”
means that devs can take advantage of built-in focus and keyboard handling
and built in states and properties (all of which have acc built-in where
needed) -

for example button related attributes.

autofocus - Automatically focus the form control when the page is loaded
disabled - Whether the form control is disabled
form - Associates the control with a form element
formaction - URL to use for form submission
formenctype - Form data set encoding type to use for form submission
formmethod - HTTP method to use for form submission
formnovalidate - Bypass form control validation for form submission
formtarget - Browsing context for form submission
menu - Specifies the element's designated pop-up menu
name - Name of form control to use for form submission and in the
form.elements API
type - Type of button
value - Value to be used for form submission

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 am not married to the is= method, but am very concerned that custom
elements without some useful method to leverage existing HTML features will
make the accessibility support story for this new technology bleak and as
much as I love ARIA it is accessibility that must be bolted on by the
developer which is unfortunately prone to error and often left off.


--

Regards

SteveF


On 16 January 2015 at 16:52, Anne van Kesteren ann...@annevk.nl wrote:

 On Fri, Jan 16, 2015 at 5:45 PM, 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 view it means custom elements are nothing more than
  divs with fancy names.

 Sure, I hope everyone understands that,



 Again, I think that unless we solve the styling problem for
 native elements, we're not going to see them adopted, not even if you
 can subclass them (and proper subclassing without the is= hack is
 another hard problem, as explained).


 --
 https://annevankesteren.nl/

Re: Minimum viable custom elements

[Steve Faulkner]

  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 is= is not acceptable

 That seems rather disingenuous.


where am I being disingenuous?

I don't understand how the various pieces are pulled together to make an
element work in browsers to an extent to be able to offer possible
technical solutions. If I did I would.


--

Regards

SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/

On 29 January 2015 at 15:37, Anne van Kesteren ann...@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 is= is not acceptable

 That seems rather disingenuous. I have said these things:

 1) Compared to my-element the is= construct is a hack that is
 unlikely to be attractive to those building libraries. Existing
 libraries seem to support this.

 2) As long as the styling problem for form controls remains unsolved,
 making some form of automatic prototype mutation work for them is not
 going to get them adoption.

 Others have already explained how turning 1) around is hard as
 browsers, specifications, and stylesheets branch on local name rather
 than instance checks. 2) is even harder and has always been the real
 problem.


 --
 https://annevankesteren.nl/

Re: Minimum viable custom elements

[Steve Faulkner]

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 been a popular mantra in regards to web accessibility support and
the benefits of native HTML

built in is better than bolt on

See the First rule of ARIA [1]

With custom tags everything must be bolted on, with type extensions this is
not the case.

In order to make custom interactive elements accessible and usable by
people with disabilities, there are a lot of hoops developers must jump
through. [3] I think reducing this burden on the developer is a worthwhile
technical design consideration for Custom Element implementation in
browsers.

See the Custom Elements Semantics section of the Custom Elements spec [2]
and the recent article by Bruce Lawson
'On the accessibility of web components. Again'. [4] which includes a link
to an example of a input type radio type extension [7]. Another example is
a disclosure button type extension [8].

It may be that it is too hard to implement type extensions (i freely admit
much of the discussion on this thread is over my head), but I do not think
that it should be dismissed out of hand or that the consideration should
characterised as longdesc mark II ;-)


[1] http://w3c.github.io/aria-in-html/#first-rule-of-aria-use
[2] http://w3c.github.io/webcomponents/spec/custom/#semantics
[3]
http://w3c.github.io/aria-in-html/#custom-control-accessible-development-checklist
[4]
http://www.brucelawson.co.uk/2014/on-the-accessibility-of-web-components-again/
[5] https://github.com/ThePacielloGroup/w3c-footnote
[6] http://thepaciellogroup.github.io/html5-h/demo-fallback.html
[7] https://rawgit.com/alice/web-components-demos/master/index.html
[8] https://github.com/ThePacielloGroup/disclosure-button


--

Regards

SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/

On 15 January 2015 at 23:33, Edward O'Connor eocon...@apple.com wrote:

 Hi all,

 Steve wrote:

  [I]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 interaction
  support necessary for accessibility I would suggest it is undesirable
  to punt on it.

 Apologies in advance, Steve, if I'm missing something obvious. I
 probably am.

 I've been writing an article about turtles and I've gotten to the point
 that six levels of headings aren't enough. I want to use a seventh-level
 heading element in this article, but HTML only has h1–6. Currently,
 without custom elements, I can do this:

 div role=heading aria-level=7Cuora amboinensis, the southeast Asian box
 turtle/div

 Suppose instead that TedHaitchSeven is a subclass of HTMLElement and
 I've registered it as ted-h7. In its constructor or createdCallback or
 whatever, I add appropriate role and aria-level attributes. Now I can
 write this:

 ted-h7Cuora amboinensis, the southeast Asian box turtle/ted-h7

 This is just as accessible as the div was, but is considerably more
 straightforward to use. So yay custom elements!

 If I wanted to use is= to do this, I guess I could write:

 h1 is=ted-h7Cuora amboinensis, the southeast Asian box turtle/h1

 How is this easier? How is this more robust?

 I think maybe you could say this is more robust (if not easier) because,
 in a browser with JavaScript disabled, AT would see an h1. h1 is at
 least a heading, if not one of the right level. But in such a browser
 the div example above is even better, because AT would see both that
 the element is a heading and it would also see the correct level.

 OK, so let's work around the wrong-heading-level-when-JS-is-disabled
 problem by explicitly overriding h1's implicit heading level:

 h1 is=ted-h7 aria-level=7Cuora amboinensis, the southeast Asian box
 turtle/h1

 I guess this is OK, but seeing aria-level=7 on and h1 rubs me the
 wrong way even if it's not technically wrong, and I don't see how this
 is easier or more robust than the other options.


 Thanks,
 Ted

Re: Minimum viable custom elements

[Steve Faulkner]

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

[Steve Faulkner]

Hi Anne,

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 view it means custom elements are nothing more 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 be bolted on, with type extensions this
 is
  not the case.

 I don't disagree with this, but is= solves none of the problems of
 why developers moved away from native elements in the first place. As
 long as styling native form controls is a problem, is= is not going
 to help us. In other words, is= is not what is going to make Gmail
 stop its div abuse to mean button. is= solves none of the
 problems for which ARIA was invented as a workaround.

 Furthermore, is= has considerably worse developer ergonomics
 compared to custom elements making it unlikely to be used much.


  It may be that it is too hard to implement type extensions (i freely
 admit
  much of the discussion on this thread is over my head), but I do not
 think
  that it should be dismissed out of hand or that the consideration should
  characterised as longdesc mark II ;-)

 is= is not that hard. What is hard is making subclassing native
 elements work with good developer ergonomics. Making the markup of a
 subclass of HTMLButtonElement just as elegant as a subclass of
 HTMLElement is.


 --
 https://annevankesteren.nl/

Re: Minimum viable custom elements

[Steve Faulkner]

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 interaction
support necessary for accessibility I would suggest it is undesirable to
punt on it.

[1] http://w3c.github.io/webcomponents/spec/custom/#semantics

--

Regards

SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/

pull request on custom elements spec

[Steve Faulkner]

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

[Steve Faulkner]

 It's already mentioned in that Twitter thread. If somebody created
 dialog we could then never standardize an element using that name.


Sure, but that's not a possibility that has any immediate effect upon a
developer, as I said I suggest the consequences of doing so need to be
better 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 already mentioned in that Twitter thread. If somebody created
 dialog we could then never standardize an element using that name.


 --
 https://annevankesteren.nl/

Re: custom elements without the dash

[Steve Faulkner]

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 or
don't care, either they are given good reasons not to do it in language
they understand and is meaningful to them or they ignore requirement and it
becomes useless.

--

Regards

SteveF

Re: custom elements without the dash

[Steve Faulkner]

yeah, it was just explained to me by Mike Smith:
standard custom-elements APIs is that the API doesn’t allow them register
custom elements without a dash

which I did not know :-)

--

Regards

SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/

On 5 January 2015 at 14:10, Anne van 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 to them or they ignore requirement and it
  becomes useless.

 If they ignore the requirement they don't get custom elements...


 --
 https://annevankesteren.nl/

custom elements without the dash

[Steve Faulkner]

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 advocating this approach.

There is no apparent downside for a developer if they do
dropdown

instead of
x-dropdown

claimed issues with use of dash:

(1) causes bloat, (2) reduces readability  (3) reduces flexibility

As there is no perceived negative effect for the developer when using non
dash custom elements (other than opprobrium from the  standards overlords)

Suggest the reasons for not doing so need to be better articulated.
--

Regards

SteveF

Re: Custom Element Semantics

[Steve Faulkner]

Thanks Alex!
I have made some updates to the spec text in response to your feedback, I
have also added other content.

http://stevefaulkner.github.io/webcomponents/spec/custom/#semantics
please review, thanks!

--

Regards

SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/

On 9 December 2014 at 17:29, Alexander Surkov surkov.alexan...@gmail.com
wrote:

 Hi. Some feedback per Steve's request on WAI group.

 * but for the semantics to be formally expressed, developers must convey
 the role, states and properties of the element to browser APIs. It's not
 clear what role, states and properties is. It'd be good to develop this
 sentence by mentioning ARIA techniques. Also it might be not clear what
 browser APIs are. Perhaps I wouldn't even mention a11y APIs since this info
 is rather for browser developers and may sound confusing for web authors.

 * I don't think that any focusable element should get its name from its
 subtree. For example, tree control name is not a concatenation of subtrees
 of its item. I think role should define whether the element should grab its
 name from the subtree or not.

 taco-button tabindex=0Eat Me/taco-button

 * The addition of a tabindex
 http://www.w3.org/TR/html/editing.html#attr-tabindex attribute to the
 *taco-button* element

 I think taco-button should be left for examples, but all rules should be
 worded in generic terms. For example, the sentence above would be The
 addition of tabindex attribute to the custom element and then give a
 markup example for taco-button.

 * The addition of keyboard event handlers to the *taco-button* element
 provides the means for keyboard users to operate the control, but does not
 convey the presence of the functionality.

 I think I miss the idea of this sentence because the topic is about
 semantics of custom elements and thus it's not clear with me where
 functionality is supposed to be here.

 * The addition of an ARIA role=button
 http://rawgit.com/w3c/aria/master/aria/aria.html#button conveys the
 *taco-button* element's role semantics

 It'd be good to generalize 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 spec

 http://w3c.github.io/webcomponents/spec/custom/#semantics

 please provide feedback on bug
 https://www.w3.org/Bugs/Public/enter_bug.cgi?comment=blocked=14968short_desc=[Custom]%3A%20product=WebAppsWGcomponent=Component%20Model

 or to webapps list http://lists.w3.org/Archives/Public/public-webapps/
 --

 Regards

 SteveF
 HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/

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

[Steve Faulkner]

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 https://github.com/w3c/webcomponents/pull/29
to merge the additions. There is a merge conflict tried to work it out but
my git fu is lacking :-(



--

Regards

SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/

On 11 December 2014 at 01:10, Arthur Barstow art.bars...@gmail.com wrote:

 Dimitri prepared a new Working Draft of Custom Elements for publication on
 December 16:

 http://w3c.github.io/webcomponents/publish/custom/
 WD-custom-elements-20141218/

 If anyone has any major concerns about this proposal, please speak up.

 -Thanks, AB

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

[Steve Faulkner]

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 http://www.w3.org/html/wg/drafts/html/master/

web developer conformance requirements and advice in custom elements spec

[Steve Faulkner]

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 this, what's the best way to contribute?
pull requests?


--

Regards

SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/

Re: [Custom] Custom elements and ARIA

[Steve Faulkner]

Hi Domenic,

--

Regards

SteveF
HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/


On 28 August 2014 15:57, Domenic Denicola dome...@domenicdenicola.com
wrote:

 Hi Steve, thanks greatly for your help. It's clear now that I should have
 reached out to you for your expertise directly before 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 (in
 the W3C HTML spec [1] at least, can't speak for where the WHATWG spec has
 gone in defining ARIA in HTML), they  are author conformance requirements.

 Yes, I was misled about that pretty badly. That changes things, as it
 means there are no non-overridable roles or stoperties (as you show with
 hr role=menuitem).


For roles this is true, for states and properties native wins where
specified (as Simon pointed out)


 From my reading though, the default implicit ARIA semantics are still UA
 requirements, right?


yes, these are what i pulled out of the spec and tested for HTML CR:
http://stevefaulkner.github.io/html-mapping-tests/ This doc lists all the
(ARIA section) UA requirements from the HTML5 CR spec, testing results for
the 4 major browsers, and browser bugs filed where needed.





 To be clear, my concern is entirely about UA requirements, so anything
 authoring-related is irrelevant to me.

  The HTML spec (any brand) does not define how HTML features map to
 platform accessibility APIs. This is being normatively defined in the HTML
 Accessibility API Mappings specification [2].
 
  Would it be worth considering exposing the  platform accessibility APIs
 used in the browser, to JS so that custom elements can be implemented to
 fully reflect native element accessibility implementations?

 zcorpan pointed out this strategy in IRC as well. I think it is worth
 exploring. Although, I was hoping to use ARIA as a platform-independent
 interface into native platform accessibility APIs; that is, I was assuming
 that everything a native or custom element would want to do could be
 expressed with ARIA. But, you state earlier in your message that:

  I don't think it is currently possible to define the browser
 accessibility API mappings in terms of ARIA as it defines and incomplete
 set of roles,states and properties used in acc APIs.

 This seems unfortunate. Why is that? Could you give an example?


I guess because ARIA is not trying to be provide a general abstraction of
all roles,states and properties. The only cases (generally) where native
features express role/state/property values in terms of ARIA in the acc
APIs are where no platform acc API role/state/property exists.

IA2 has a caption role that FF maps to the figcaption element, ARIA does
not.




 Would it be more fruitful to augment ARIA in some way, instead of trying
 to bypass it and go directly to platform accessibility APIs? The latter
 seems like it would require a platform-agnostic intermediate layer to be
 defined, which feels redundant with ARIA...


Possibly, I would suggest pinging the PF mailing list with some ideas would
be a good place to start http://lists.w3.org/Archives/Public/public-pfwg/

HTH