RE: Stability of Widget DigSig

[Andrew Twigger]

Art,

I expect that removing the statement from the namespace document
will resolve the concerns of ATSC and CEA members.

Thank-you for your quick response to this request.

Andrew Twigger

-Original Message-
From: Arthur Barstow [mailto:art.bars...@gmail.com] 
Sent: 08 May 2015 13:55
To: Andrew Twigger
Cc: Marcos Caceres; Frederick Hirsch; public-webapps@w3.org
Subject: Re: Stability of Widget DigSig

Andrew - seeing no objections from the group to removing the 
"Implementers ..." statement from [NS] document, if that statement is 
removed, does that address your concern?

-Thanks, ArtB

[NS] 

On 5/8/15 7:14 AM, Arthur Barstow wrote:
> [ + Marcos and Frederick ]
>
> Hi Andrew,
>
> The group stopped working on XML Digital Signature for Widgets several 
> years ago and there is no plan to resume work (except to process 
> errata as required).
>
> Marcos, Frederick - this spec's namespace document includes the 
> following statement:
>
> [[
> 
>
> Implementers should be aware that this document is not stable.
> ]]
>
> Any objections from you or anyone else to remove this statement?
>
> -Thanks, ArtB
>
> On 5/7/15 5:55 AM, Andrew Twigger wrote:
>>
>> ATSC and CEA are developing standards that include the ability to 
>> download digital signed applications. Their current specifications 
>> reference the W3C Recommendation for XML Digital Signature for 
>> Widgets (18 April 2013).  However, the associated Widgets Digital 
>> Signature Namespace (http://www.w3.org/ns/widgets-digsig/) contains a 
>> statement that "Implementers should be aware that this document is 
>> not stable." which has raised questions as to the stability and 
>> suitability of referencing Widget DigSig.  The alternative would be 
>> to reference XAdES with the C and T forms to allow for the inclusion 
>> of timestamp and certificate revocation information which are not 
>> included in Widget DigSig.
>>
>> I would be pleased to receive any information regarding the stability 
>> of Widget DigSig and whether referencing XAdES would provide a better 
>> alternative.
>>
>> Thank-you,
>>
>> Andrew Twigger
>>
>

Re: Making ARIA and native HTML play better together

[Steve Faulkner]

On 9 May 2015 at 22:22, Alice Boxhall  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 .
> Example:
>
>  i
> like this idea
>
>
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: Stability of Widget DigSig

[Arthur Barstow]

On 5/11/15 4:23 AM, Andrew Twigger wrote:

I expect that removing the statement from the namespace document
will resolve the concerns of ATSC and CEA members.


Andrew - the warning has been removed.

-ArtB




Thank-you for your quick response to this request.

Andrew Twigger

-Original Message-
From: Arthur Barstow [mailto:art.bars...@gmail.com]
Sent: 08 May 2015 13:55
To: Andrew Twigger
Cc: Marcos Caceres; Frederick Hirsch; public-webapps@w3.org
Subject: Re: Stability of Widget DigSig

Andrew - seeing no objections from the group to removing the
"Implementers ..." statement from [NS] document, if that statement is
removed, does that address your concern?

-Thanks, ArtB

[NS] 

[Bug 28564] [Shadow]: Event model

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28564
Bug 28564 depends on bug 20017, which changed state.

Bug 20017 Summary: [Shadow]: Retargeting relatedTarget algorithm prevents 
events from be fired if a user creates a MouseEvent manually with a 
relatedTarget which is same to the target.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20017

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 28552] [Shadow]: Shadow DOM v1

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28552
Bug 28552 depends on bug 20017, which changed state.

Bug 20017 Summary: [Shadow]: Retargeting relatedTarget algorithm prevents 
events from be fired if a user creates a MouseEvent manually with a 
relatedTarget which is same to the target.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20017

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: Making ARIA and native HTML play better together

[Maciej Stachowiak]

> On May 7, 2015, at 12:59 AM, Domenic Denicola  wrote:
> 
> From: Anne van Kesteren 
> 
>> On Thu, May 7, 2015 at 9:02 AM, Steve Faulkner  
>> wrote:
>>> Currently ARIA does not do this stuff AFAIK.
>> 
>> Correct. ARIA only exposes strings to AT. We could maybe make it do more, 
>> once we understand what more means, which is basically figuring out HTML as 
>> Custom Elements...
> 
> These are my thoughts as well. The proposal seems nice as a convenient way to 
> get a given bundle of behaviors. But we *really* need to stop considering 
> these "roles" as atomic, and instead break them down into what they really 
> mean.
> 
> In other words, I want to explain the "button" behavior as something like:
> 
> - Default-focusable

This point isn’t correct for built-in buttons on all browsers and platforms. 
For example,  is not keyboard-focusable on Safari for Mac 
but it is mouse-focusable. Likewise in Safari on iOS (both if you connect a 
physical keyboard, and if you use the onscreen focus-cycle arrows in navigation 
view).

This raises an interesting and subtle point. Built-in controls can add value by 
being consistent with the platform behavior when it varies between platforms. 
Giving very low-level primitives results in developers hardcoding the behavior 
of their biggest target platform - generally Windows, but for some 
mobile-targeted sites it can be iOS. It’s hard to make low-level primitives 
that can sensibly capture these details. Sure, I guess we could have a feature 
that’s "default-focusable but only on platforms where that is true for controls 
you don’t type into”. That is pretty specific to particular platform details 
though. Other platforms could make different choices. In fact, what controls 
fall in which focus bucket has changed over time in Safari.

Let’s say you really want to capture all the essences of buttonness in a custom 
control, but give it special appearance or behavior. I think two good ways the 
web platform could provide for that are:

(1) Provide standardized cross-browser support for styling of form controls.
(2) Allow custom elements to subclass  or  (the 
latter is hard to define cleanly due to the way many form controls are all 
overloaded onto a single element).

> - Activatable with certain key commands
> - Announced by AT as a button

Buttons also have further aspects to their specialness, such as the way they 
participate in forms.

I think adding clean primitives for these has value. Adding an easy way to get 
a package deal of standard button behaviors with greater customizability is 
also valuable, potentially more so in some circumstances.

(I don’t think ARIA is the best way to invoke a package deal of behaviors 
though, since it’s already pretty established as a way to expose behavior 
through AT without having many of these effects. It would risk breaking author 
intent to change it now.)

Regards,
Maciej

> 
> and then I want to be able to apply any of these abilities (or others like 
> them) to any given custom element. Once we have these lower-level primitives 
> we'll be in a much better place.
>