On 1/31/13 9:13 AM, "Arthur Barstow" wrote:
>As I said during one of the testing breakouts in Lyon, ultimately I
>suspect the saying "beggars can't be choosy" will trump. However, AFAIK,
>currently, only one of WebApps' thirty active specs actually has an
>"outside" contribution. As such, and wit
On Thu, Jan 31, 2013 at 7:38 PM, Dominic Cooney wrote:
> In reading [1] more closely, I see that @host rules are not matched starting
> at the host element, but *specifically* to the host element.
Yes.
> In that sense, it does not make sense for @host to establish a context
> scope, because @hos
In reading [1] more closely, I see that @host rules are not matched
starting at the host element, but *specifically* to the host element.
In that sense, it does not make sense for @host to establish a context
scope, because @host { :scope { … } } is redundant at best.
Regards,
Dominic
[1] <
htt
I wanted clarification on the meaning of @host rules [1] in combination
with the :scope pseudo selector [2].
Am I correct in assuming that if I wanted to style the host element, and
only the host element, I could apply these features in combination this way?
@host {
:scope {
border: 1px sol
I guess I should chime in.
Yes I submitted a batch of tests from TestTWF some time after the Paris
event. After having a pretty bad experience with Mercurial earlier in the
year at TestTWF San Francisco, we made a conscious choice to eliminate it
in Paris and use DropBox instead. It was marginally
On Thu, 31 Jan 2013 18:13:15 +0100, Arthur Barstow
wrote:
However, AFAIK, currently, only one of WebApps' thirty active specs
actually has an "outside" contribution.
I should've already left work, so I'll just reply to this sentence quickly
:-)
With that you mean Server Sent Events? The
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18427
Eliot Graff changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18328
Eliot Graff changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17645
Eliot Graff changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On 1/24/13 1:22 PM, ext Odin Hørthe Omdal wrote:
Arthur Barstow wrote:
Before we start a CfC to change WebApps' agreed testing process
[Testing], please make a clear proposal regarding the submission
process, approval process, roles, etc. as is defined in [Testing] and
its references. (My pref
Note that the www-dom WG has objected to querying the localized,
accessible, user-friendly, keyboard symbol on grounds that it adds more
bits (or tiny fractions of bits) to the user identifyable information.
Contrieved usecases and advanced handwaving where employed. This is most
likely ending with
There is a problem confronting applications desiring to use a variety of
APIs such as pointerlock, fullscreen, WebRTC, local storage and so on.
The problem is that each instance of attempting to use such an API leads to
a new "Allow ..." popup the user has to click away.
By some discussion on the
Sounds fine to me, any objections to add it to the Event Level 4 spec?
On Thu, Jan 31, 2013 at 11:46 AM, Hallvord Reiar Michaelsen Steen <
hallv...@opera.com> wrote:
> > What/where would be a good place to put the API for say
> queryKeyCap(code) ?
> Given that the implementation will have a Keyb
> What/where would be a good place to put the API for say queryKeyCap(code) ?
Given that the implementation will have a KeyboardEvent property specified on
the global object (i.e. window) I'd propose
window.KeyboardEvent.queryKeyCap(code)
which returns a string with the symbol shown on the
14 matches
Mail list logo
