On Mon, Sep 22, 2014 at 3:46 PM, Richard Schwerdtfeger
wrote:
>
> So, you want to modify contenteditable to "minimum". What will that do to
> existing apps. that are built on it?
>
>
As has been mentioned before, the current (and broken) contenteditable will
stay the way it is, to make sure that n
blic-webapps
> Date: 09/19/2014 03:56 PM
> Subject: RE: User Intentions Explainer (was: List of Intentions)
>
> I agree that we can divide this work, but so far I think we should
> do "2" first. Being able to remove browser functionality with a
> simple API is going to be fa
On Sat, Sep 6, 2014 at 1:54 AM, Johannes Wilm wrote:
> These both look quite good!
>
> On Example 3 on the commands explainer, I was wondering if it is the idea
> that custom actions only can be triggered by specific key presses, whereas
> for standard events are triggered by "intentions". So sa
I think what I'm hearing in this conversation about the shape of a new
contentEditable is really that a simple "minimal" is not going to work.
Instead, having something like a delimited list will satisfy more people. See
the bug on GitHub [1] for more details.
https://github.com/w3c/editing-exp
I agree that we can divide this work, but so far I think we should do "2"
first. Being able to remove browser functionality with a simple API is going to
be far quicker to implement (in browsers) and provides immediate benefit.
Solving Intentions will be a longer process, but is also important t
On Thursday, 11 September 2014 at 17:38, Ryosuke Niwa wrote:
>
> On Sep 9, 2014, at 6:31 AM, Johannes Wilm (mailto:johan...@fiduswriter.org)> wrote:
> > Absolutely. if this division means we can get into a saner place faster
> > (and with a higher likelihood that it will actually happen) the
On Sep 9, 2014, at 6:31 AM, Johannes Wilm wrote:
> Absolutely. if this division means we can get into a saner place faster (and
> with a higher likelihood that it will actually happen) then I am all for it.
>
> Of course the long-term future of the web should be taken into consideration
> as
Absolutely. if this division means we can get into a saner place faster
(and with a higher likelihood that it will actually happen) then I am all
for it.
Of course the long-term future of the web should be taken into
consideration as well, and as I understand it, this could be part of the
second p
I'm not sure if I remember correctly, but I believe that after long
discussions we left the question "what should contenteditable=minimal be?"
unanswered. First the intention events lists should be created, so we can
see what needs to be handled. And this is what Ben Peters is working on.
Still we
On Tuesday, 9 September 2014 at 11:13, Frederico Knabben wrote:
> I don’t think that browsers having time/will for it today is a good
> argumentation for not doing it. The specs have a critical and noble scope, of
> serving as reference for the future of the web. We’re talking about the
> future
On Monday, 8 September 2014 at 20:55, Johannes Wilm wrote:
> If we include deletion/backspace and input text, that will then also mean
> merging of paragraphs (and other nodes) when the caret is at the beginning of
> a second paragraph and the backspace key is being hit?
Definitely. It’s all a
On Mon, Sep 8, 2014 at 6:05 PM, Frederico Knabben
wrote:
> IMHO, the following are the "minimal" features that it should provide:
>
> - Selection: UI (e.g. caret), creation (e.g. mouse) and modifications
> (e.g. arrows)
> - Focus (probably part of Selection, but it's so hard to make it right
>
Pretty good docs, Ben.
I have comments mostly about Issue 2
(http://w3c.github.io/editing-explainer/#h_issue_2).
As long as actions are well documented, browsers can provide defaults that will
fit 90% of the *good quality* content creation requirements out there.
Additionally just selecti
These both look quite good!
On Example 3 on the commands explainer, I was wondering if it is the idea
that custom actions only can be triggered by specific key presses, whereas
for standard events are triggered by "intentions". So say that we listen
for CTRL+C to trigger our custom intention "chec
There is now an Editing Explainer [1] and a User Intentions Explainer [2],
which should help scope the problems and help us drive forward on both areas. I
haven't done much to fine tune them yet, but please let me know if you have
feedback on this split from the initial Commands Explainer docume
ginal Message-
> From: Jason White [mailto:ja...@jasonjgw.net]
> Sent: Saturday, August 9, 2014 4:56 PM
> To: public-indie...@w3.org
> Cc: public-editing...@w3.org; public-webapps@w3.org
> Subject: Re: User Intentions Explainer (was: List of Intentions)
>
> [Cross-posting the comm
[Cross-posting the comments below per Janina's thoughtful request.]
I concur with Janina's insightful remark [at the Indie-UI teleconference on
Thursday] that the "explainer" could evolve into a (potentially cross-group)
requirements document. This raises several issues.
1. Harmonization of termi
From: Julie Parent
>
>> This is a great list, and I agree it is the right starting point.
>>
>> On Mon, Jul 21, 2014 at 6:12 PM, Ben Peters wrote:
>>> * Activate / Invoke
>>>
>>> * Expand
>>> * Collapse
>>> * Dismiss
>>> * Media next/previous/start/stop/pause
>>> * Rotate
>>> * Zoom
>>
This is a really solid list. Thank you for pulling it together, so we can
start towards a harmonized set of user events.
From: Ben Peters [mailto:ben.pet...@microsoft.com]
Sent: Monday, August 4, 2014 7:28 PM
To: public-editing...@w3.org; Julie Parent; public-indie...@w3.org;
public-webapps
Sub
On Aug 4, 2014, at 7:28 PM, Ben Peters wrote:
> Cross-posted: Editing TF, IndieUI TF, WebApps WG
>
> In order to solve the broad issue of User Intentions, we have compiled below
> a list of User Intentions derived from all of the sources of intention-style
> events that I am aware of. I agree
20 matches
Mail list logo
