> On Jan 9, 2016, at 4:11 PM, Chaals McCathie Nevile
> wrote:
>
> On Sat, 09 Jan 2016 23:20:27 +0300, Ryosuke Niwa wrote:
>
>>
>>> On Jan 8, 2016, at 7:12 PM, Johannes Wilm wrote:
>>>
>>> On Sat, Jan 9, 2016 at 3:49 AM, Grisha Lyukshin wrote:
Hello Johannes,
I was the one
On 01/10/2016 05:05 AM, Ryosuke Niwa wrote:
On Jan 9, 2016, at 6:33 PM, Olli Pettay wrote:
On 01/10/2016 01:14 AM, Ryosuke Niwa wrote:
Hi all,
This is another feedback from multiple browser vendors (Apple, Google,
Microsoft) that got together in Redmond last Thursday to discuss editing API
Hi,
It looks like browsers don't agree on where `onselectstart` and
`onselectionchange` IDL attributes should be defined:
https://github.com/w3c/selection-api/issues/54
https://github.com/w3c/selection-api/issues/60
In particular, Blink/WebKit/Trident all defines onselectstart/onselectionchange
> On Jan 9, 2016, at 6:33 PM, Olli Pettay wrote:
>
> On 01/10/2016 01:14 AM, Ryosuke Niwa wrote:
>> Hi all,
>>
>> This is another feedback from multiple browser vendors (Apple, Google,
>> Microsoft) that got together in Redmond last Thursday to discuss editing API
>> and related events.
>>
>
> On Jan 9, 2016, at 6:25 PM, Olli Pettay wrote:
>
> Hard to judge this proposal before seeing an API using StaticRange objects.
>
> One thing though, if apps were to create an undo stack of their own, they
> could easily have their own Range-like API implemented in JS. So if that is
> the on
On 01/10/2016 01:14 AM, Ryosuke Niwa wrote:
Hi all,
This is another feedback from multiple browser vendors (Apple, Google,
Microsoft) that got together in Redmond last Thursday to discuss editing API
and related events.
We found out that all major browsers (Chrome, Firefox, and Safari) fire
Hard to judge this proposal before seeing an API using StaticRange objects.
One thing though, if apps were to create an undo stack of their own, they could easily have their own Range-like API implemented in JS. So if that is
the only use case, probably not worth to add anything to make the plat
On 01/10/2016 01:16 AM, Ryosuke Niwa wrote:
Hi all,
This is another feedback from multiple browser vendors (Apple, Google,
Microsoft) that got together in Redmond last Thursday to discuss editing API
and related events.
We've been informed that Gecko/Firefox does not fire keydown/keyup event
On Sat, 09 Jan 2016 23:20:27 +0300, Ryosuke Niwa wrote:
On Jan 8, 2016, at 7:12 PM, Johannes Wilm
wrote:
On Sat, Jan 9, 2016 at 3:49 AM, Grisha Lyukshin
wrote:
Hello Johannes,
I was the one to organize the meeting. To make things clear, this was
an ad hoc meeting with the intent f
Hi,
This is yet another feedback from multiple browser vendors (Apple, Google,
Microsoft) that got together in Redmond last Thursday to discuss editing API
and related events.
For editing APIs, it's desirable to have a variant of Range that is immutable.
For example, if apps were to create an
Hi,
This is yet another feedback from multiple browser vendors (Apple, Google,
Microsoft) that got together in Redmond last Thursday to discuss editing API
and related events.
It came to our attention that `beforeinput` event fired for paste would need to
expose HTML (or images, etc...) inste
Hi all,
This is another feedback from multiple browser vendors (Apple, Google,
Microsoft) that got together in Redmond last Thursday to discuss editing API
and related events.
As we discussed various aspects of composition events and beforeinput/input
events, it became apparent that we want b
Hi all,
This is another feedback from multiple browser vendors (Apple, Google,
Microsoft) that got together in Redmond last Thursday to discuss editing API
and related events.
We've been informed that Gecko/Firefox does not fire keydown/keyup events
during input method composition for each ke
Hi all,
This is another feedback from multiple browser vendors (Apple, Google,
Microsoft) that got together in Redmond last Thursday to discuss editing API
and related events.
We found out that all major browsers (Chrome, Firefox, and Safari) fire
composition events for dead keys on Mac but t
Hi,
This is a feedback from multiple browser vendors (Apple, Google, Microsoft)
that got together in Redmond last Thursday to discuss editing API and related
events.
First off, we found out that there are behavior inconsistencies between
browsers with respect to composition events.
WebKit, Bl
> On Jan 9, 2016, at 6:18 AM, Florian Rivoal wrote:
>
>> On Jan 9, 2016, at 11:49, Grisha Lyukshin wrote:
>>
>> Hello Johannes,
>>
>> I was the one to organize the meeting. To make things clear, this was an ad
>> hoc meeting with the intent for the browsers to resolve any ambiguities and
>>
> On Jan 9, 2016, at 12:20 PM, Ryosuke Niwa wrote:
>
>
>> On Jan 8, 2016, at 7:12 PM, Johannes Wilm wrote:
>>
>> On Sat, Jan 9, 2016 at 3:49 AM, Grisha Lyukshin wrote:
>>> Hello Johannes,
>>>
>>> I was the one to organize the meeting. To make things clear, this was an ad
>>> hoc meeting wi
בע"ה
None of your mentioned techniques (WebID, FOAF+SSL, OAuth, navigator.id)
seems covering my proposal.
What I meant is simple JavaScript API to read browser/machine
logged/synchronized/identification user profile data.
For example return in Chrome
{
name: "Me",
surname: "Surname",
> On Jan 8, 2016, at 7:12 PM, Johannes Wilm wrote:
>
> On Sat, Jan 9, 2016 at 3:49 AM, Grisha Lyukshin wrote:
>> Hello Johannes,
>>
>> I was the one to organize the meeting. To make things clear, this was an ad
>> hoc meeting with the intent for the browsers to resolve any ambiguities and
>
> On Jan 9, 2016, at 11:49, Grisha Lyukshin wrote:
>
> Hello Johannes,
>
> I was the one to organize the meeting. To make things clear, this was an ad
> hoc meeting with the intent for the browsers to resolve any ambiguities and
> questions on beforeInput spec, which we did. This was the rea
20 matches
Mail list logo
