Re: Last Call for "CSS Font Loading Module Level 3"

[Tab Atkins Jr.]

On Tue, May 27, 2014 at 3:47 PM, Jonas Sicking  wrote:
> On Tue, May 27, 2014 at 12:14 PM, Tab Atkins Jr.  wrote:
>> On Tue, May 27, 2014 at 11:44 AM, Jonas Sicking  wrote:
>>> On Tue, May 27, 2014 at 10:41 AM, Tab Atkins Jr.  
>>> wrote:
> Separately, FontFace.loaded seems to fulfill the same purpose as
> FontFaceSet.ready(). I.e. both indicate that the object is done
> loading/parsing/applying its data. It seems more consistent if they
> had the same name, and if both were either an attribute or both were a
> function.

 No, the two do completely different (but related) things.  Why do you
 think they're identical?  One fulfills when a *particular* FontFace
 object finishes loading, the other repeatedly fulfills whenever the
 set of loading fonts goes from non-zero to zero.
>>>
>>> Semantically they both indicate "the async processing that this object
>>> was doing is done". Yes, in one instance it just signals that a given
>>> FontFace instance is ready to be used, in the other that the full
>>> FontFaceSet is ready. Putting the properties on different objects is
>>> enough to indicate that, the difference in name doesn't seem
>>> important?
>>
>> The loaded/ready distinction exists elsewhere, too.  Using .loaded for
>> FontFaceSet is incorrect, since in many cases not all of the fonts in
>> the set will be loaded.
>
> Sure, but would using .ready() for FontFace be wrong?

Depends on how we end up designing the loaded/ready duo.

~TJ

Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review

[Marcos Caceres]

On Tuesday, May 27, 2014, Jonas Sicking  wrote:

> On Tue, May 27, 2014 at 12:39 PM, Marcos Caceres 
> >
> wrote:
> >
> >
> > On May 27, 2014 at 2:30:32 PM, Jonas Sicking (jo...@sicking.cc) wrote:
> >> On Tue, May 27, 2014 at 9:11 AM, Marcos Caceres wrote:
> >> > The only way that gmail would allow "my own app store" to use its
> manifest would be for
> >> Google to include the HTTP header:
> >> >
> >> > Access-Control-Allow-Origin: "http://myownappstore.com";
> >>
> >> This is a bit of an abuse of CORS.
> >
> > hmmm... I thought this was *exactly* the point of having the
> "*-Allow-Origin" header (restrict sharing to the domains the server chooses
> in browsers).
> >
> >> Adding an
> >> "Access-Control-Allow-Origin: *" header currently has the semantic
> >> meaning of "any website can read the contents of this file". I.e. it
> >> only means that the bits in the file are accessible from other
> >> websites.
> >
> > Yep. The point was that combined with the `start_url` member, you can
> make "install pages" away from the origin where the application resides.
> >
> >> That means that for a webserver on the public internet it is currently
> >> always safe to add the "Access-Control-Allow-Origin: *" header to any
> >> file since all files can be read anyway by simply using a different
> >> HTTP client than a browser, such as wget.
> >
> > Sure. But that's not the point here. The use of CORS here is to control
> who can do what within the context of the browser (as the policy
> enforcement point). Of course, anyone can just go and download  anything
> with wget or whatever - but that's not going to give that person a web app
> with the manifest applied.
>
> So let's start by asking this: What are you trying to protect against
> by using CORS at all? Rather than using the policy that  uses.
>
> If the *only* thing you are trying to protect is the actual bytes in
> the manifest itself, then CORS is indeed the right solution.


Yes. This was the only intent.


>
> But if we're trying to protect more things, then CORS strikes me as
> the wrong solution. And I do think that we will want to protect
> against other things in the future. In FirefoxOS the "origin" of an
> app is the origin of the app's manifest. This app-origin is then used
> in a bunch of situations.
>
> For example, we allow pages from the app's to store unlimited amount
> of data through various storage APIs (localStorage excluded for
> reasons I won't get into here). So if you hosted the manifest on a
> CDN, then would mean that only pages whose origin is that of the CDN
> would get access to unlimited storage. That is very unlikely what
> developers want.


Agree - the FX OS model is certainly not the intent or how we, the Eds,
envisioned it working. The manifest relates to the explicit  or implicit
"start URL" (and soon the URL scope), but not to the manifest's origin.


>
> In this case hosting the manifest on the CDN would be a footgun, but
> not a security problem.




> I can't off the top of my head think of any actual security problems
> with putting the manifest on a CDN, but I would be surprised if that
> wouldn't happen as we expand the manifest feature set.
>
> And the footgun is bad enough.
>
> So I would recommend sticking with having the manifest be same-origin
> with the HTML page.



 Thanks for the additional data point about how FxOS does things.

Re: [editing] CommandEvent and contentEditable=minimal Explainer

[Julie Parent]

The discussion of which minimal default handling to include with
contenteditable="minimal" makes me wonder if contentEditable="minimal" is
necessary at all.  It quickly becomes a can of worms of *which* default
handling should be included, and it seems likely to not satisfy every use
case no matter which decisions are made.  However, "minimal" is proposed as
a building block because currently, disabling all default functionality of
contentEditable="true" is difficult/impossible.  But with CommandEvents,
shouldn't contentEditable="minimal" be equivalent to:

// Let editRegion be 

var editRegion = document.getElementById("editRegion");
editRegion.addEventListener("command", handleCommand);
function handleCommand(evt){
  evt.preventDefault();
}

No default actions would be taken, but selection events would still fire
and be handled.  There would be no ambiguity.  If implementing
contentEditable="minimal" on top of CommandEvents could just be a few lines
of code, why complicate things by spec'ing another property?

Then, if someone wants a region that just does basic text input, then they
simply allow it:
function handleCommand(evt){
 switch (evt.commandType){
   case 'insertText':
 // Let the browser do text insertion
 break;
   default:
 // Prevent all other magic
 evt.preventDefault();
}

This hedges on the fact that CommandEvents would capture ALL the cases that
contentEditable currently handles, and that the event would fire BEFORE the
dom is modified, and that calling preventDefault would cancel the event,
but isn't that a goal of this design anyway?

Julie

-- Forwarded message --
From: Ben Peters 
Date: Thu, May 22, 2014 at 4:56 PM
Subject: [editing] CommandEvent and contentEditable=minimal Explainer
To: "public-webapps@w3.org" 


I have completed a first-draft explainer document [1], taking the generous
feedback of many of you into account. There are 6 open issues on the
document currently, and I'm sure there are others that I have missed. It
would be great to know if this is heading in in the right direction.

My vision is to use this a non-normative Explainer, and create 2 normative
specs to go with it. The specs for contentEditable=minimal and CommandEvent
should have first-drafts next week.

Thanks!
Ben

[1] http://benjamp.github.io/commands-explainer.htm

Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review

[Jonas Sicking]

On Tue, May 27, 2014 at 12:39 PM, Marcos Caceres  wrote:
>
>
> On May 27, 2014 at 2:30:32 PM, Jonas Sicking (jo...@sicking.cc) wrote:
>> On Tue, May 27, 2014 at 9:11 AM, Marcos Caceres wrote:
>> > The only way that gmail would allow "my own app store" to use its manifest 
>> > would be for
>> Google to include the HTTP header:
>> >
>> > Access-Control-Allow-Origin: "http://myownappstore.com";
>>
>> This is a bit of an abuse of CORS.
>
> hmmm... I thought this was *exactly* the point of having the "*-Allow-Origin" 
> header (restrict sharing to the domains the server chooses in browsers).
>
>> Adding an
>> "Access-Control-Allow-Origin: *" header currently has the semantic
>> meaning of "any website can read the contents of this file". I.e. it
>> only means that the bits in the file are accessible from other
>> websites.
>
> Yep. The point was that combined with the `start_url` member, you can make 
> "install pages" away from the origin where the application resides.
>
>> That means that for a webserver on the public internet it is currently
>> always safe to add the "Access-Control-Allow-Origin: *" header to any
>> file since all files can be read anyway by simply using a different
>> HTTP client than a browser, such as wget.
>
> Sure. But that's not the point here. The use of CORS here is to control who 
> can do what within the context of the browser (as the policy enforcement 
> point). Of course, anyone can just go and download  anything with wget or 
> whatever - but that's not going to give that person a web app with the 
> manifest applied.

So let's start by asking this: What are you trying to protect against
by using CORS at all? Rather than using the policy that  uses.

If the *only* thing you are trying to protect is the actual bytes in
the manifest itself, then CORS is indeed the right solution.

But if we're trying to protect more things, then CORS strikes me as
the wrong solution. And I do think that we will want to protect
against other things in the future. In FirefoxOS the "origin" of an
app is the origin of the app's manifest. This app-origin is then used
in a bunch of situations.

For example, we allow pages from the app's to store unlimited amount
of data through various storage APIs (localStorage excluded for
reasons I won't get into here). So if you hosted the manifest on a
CDN, then would mean that only pages whose origin is that of the CDN
would get access to unlimited storage. That is very unlikely what
developers want.

In this case hosting the manifest on the CDN would be a footgun, but
not a security problem.

I can't off the top of my head think of any actual security problems
with putting the manifest on a CDN, but I would be surprised if that
wouldn't happen as we expand the manifest feature set.

And the footgun is bad enough.

So I would recommend sticking with having the manifest be same-origin
with the HTML page.

/ Jonas

Re: Last Call for "CSS Font Loading Module Level 3"

[Jonas Sicking]

On Tue, May 27, 2014 at 12:14 PM, Tab Atkins Jr.  wrote:
> On Tue, May 27, 2014 at 11:44 AM, Jonas Sicking  wrote:
>> On Tue, May 27, 2014 at 10:41 AM, Tab Atkins Jr.  
>> wrote:
 Separately, FontFace.loaded seems to fulfill the same purpose as
 FontFaceSet.ready(). I.e. both indicate that the object is done
 loading/parsing/applying its data. It seems more consistent if they
 had the same name, and if both were either an attribute or both were a
 function.
>>>
>>> No, the two do completely different (but related) things.  Why do you
>>> think they're identical?  One fulfills when a *particular* FontFace
>>> object finishes loading, the other repeatedly fulfills whenever the
>>> set of loading fonts goes from non-zero to zero.
>>
>> Semantically they both indicate "the async processing that this object
>> was doing is done". Yes, in one instance it just signals that a given
>> FontFace instance is ready to be used, in the other that the full
>> FontFaceSet is ready. Putting the properties on different objects is
>> enough to indicate that, the difference in name doesn't seem
>> important?
>
> The loaded/ready distinction exists elsewhere, too.  Using .loaded for
> FontFaceSet is incorrect, since in many cases not all of the fonts in
> the set will be loaded.

Sure, but would using .ready() for FontFace be wrong?

>> In general it would be nice if we started establishing a pattern of a
>> .ready() method (or property) on various objects to indicate that they
>> are ready to be used. Rather than authors knowing that they need to
>> listen to "load" events on images, "success" events on
>> IDBOpenRequests, .loaded promise on FontFace objects and .ready()
>> promise on FontFaceSets.
>
> Yes, I'm actively working with Anne, Domenic, and others to help
> figure out the right patterns for this that we can extend to the rest
> of the platform.

Great!

/ Jonas

[Bug 25895] [imports]: LinkImport definition could use some cleaning up

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25895

Morrita Hajime  changed:

   What|Removed |Added

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

--- Comment #1 from Morrita Hajime  ---
Thank you for the suggestion!
https://github.com/w3c/webcomponents/commit/45b44644ade983aad3efee8a8429fa435aeda
77a

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

Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review

[Marcos Caceres]

On May 27, 2014 at 3:31:15 PM, Ben Francis (bfran...@mozilla.com) wrote:
> > To be clear, this is the case I was talking about. The benefit  
> is that it makes it much easier to build a large "app store" of "tailored  
> app experiences for sites that lack manifests" without the involvement  
> of app authors themselves. For example,everything.me(http://everything.me)  
> may have a larger catalogue of "web apps" than the Firefox Marketplace  
> because the latter requires same-origin manifests and for app  
> authors to submit their own apps, whereas the former doesn't  
> require any involvement from app authors themselves.
>  
> One risk of allowing cross-origin manifests might be that these  
> "tailored app experiences" are perceived by the actual app author  
> and/or end users as a "fake app" masquerading as the real thing.  
> In the longer term when additional features are added to the manifest  
> there could be additional risks.
>  
> That is why I'm interested in feedback on whether this is a desirable  
> feature or not.

That's a very good summary of both the use case and the problems. I'm also 
interested in hearing feedback. As Ben makes clear, "same-origin" basically 
kills installations from custom stores. 

It means one or two additional clicks for users to "install" an app - but we 
assure that apps are always being installed from "the source". 
 

-- 
Marcos Caceres

Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review

[Marcos Caceres]

On May 27, 2014 at 2:30:32 PM, Jonas Sicking (jo...@sicking.cc) wrote:
> On Tue, May 27, 2014 at 9:11 AM, Marcos Caceres wrote:
> > The only way that gmail would allow "my own app store" to use its manifest 
> > would be for  
> Google to include the HTTP header:
> >
> > Access-Control-Allow-Origin: "http://myownappstore.com";
>  
> This is a bit of an abuse of CORS.

hmmm... I thought this was *exactly* the point of having the "*-Allow-Origin" 
header (restrict sharing to the domains the server chooses in browsers). 

> Adding an
> "Access-Control-Allow-Origin: *" header currently has the semantic
> meaning of "any website can read the contents of this file". I.e. it
> only means that the bits in the file are accessible from other
> websites.

Yep. The point was that combined with the `start_url` member, you can make 
"install pages" away from the origin where the application resides.  

> That means that for a webserver on the public internet it is currently
> always safe to add the "Access-Control-Allow-Origin: *" header to any
> file since all files can be read anyway by simply using a different
> HTTP client than a browser, such as wget.

Sure. But that's not the point here. The use of CORS here is to control who can 
do what within the context of the browser (as the policy enforcement point). Of 
course, anyone can just go and download  anything with wget or whatever - but 
that's not going to give that person a web app with the manifest applied.   

> It does not currently mean, and I don't think it should mean, "I am ok
> with acting as a manifest for any website".

This is a different interpretation of the semantics of sharing a manifest - and 
certainly not the primary use case (though 
"http://generic-manifest.com/manifest.json"; could be useful for testing and 
other interesting things). The idea was to say which stores can create a 
product page with the manifest.  

> I think restricting manifests to same-origin is the way to go. I would
> not be surprised if manifests will eventually end up with similar
> security properties as hosting HTML files currently does.

Given the current stuff the manifest defines, I don't have a strong opinion - 
but it certainly does seem like a few less potential headaches down the line. 

I'm happy to make this change and restrict to same origin.


 

[manifest] URL Scope and priorities, was Re: [manifest] Update and call for review

[Marcos Caceres]

On May 27, 2014 at 9:19:45 AM, Ben Francis (bfran...@mozilla.com) wrote:
> > I think a particular problem with having no defined scope for  
> apps is when you want to hyperlink from one web app to another.  
> A hyperlink with no specified target window will always open  
> in the browsing context of the current app, regardless of whether  
> the URL belongs to another app or web site. That means that the  
> level of browser chrome you get when following a hyperlink (as  
> well as the orientation of the page and the title and icon shown  
> in the task switcher etc.) depends on where you navigated from  
> rather than where you navigated to.
>  
> I would like to see some way to define the scope to which an app manifest  
> applies, so that the user agent knows which URLs belong to which  
> apps and therefore what display properties to use for a given  
> URL.

I strongly agree that we need to prioritize: 
https://github.com/w3c/manifest/issues/114

The CSP stuff is also pretty important. Would like to see that also prioritized 
above other things.  

Re: Last Call for "CSS Font Loading Module Level 3"

[Tab Atkins Jr.]

On Tue, May 27, 2014 at 11:44 AM, Jonas Sicking  wrote:
> On Tue, May 27, 2014 at 10:41 AM, Tab Atkins Jr.  wrote:
>>> Separately, FontFace.loaded seems to fulfill the same purpose as
>>> FontFaceSet.ready(). I.e. both indicate that the object is done
>>> loading/parsing/applying its data. It seems more consistent if they
>>> had the same name, and if both were either an attribute or both were a
>>> function.
>>
>> No, the two do completely different (but related) things.  Why do you
>> think they're identical?  One fulfills when a *particular* FontFace
>> object finishes loading, the other repeatedly fulfills whenever the
>> set of loading fonts goes from non-zero to zero.
>
> Semantically they both indicate "the async processing that this object
> was doing is done". Yes, in one instance it just signals that a given
> FontFace instance is ready to be used, in the other that the full
> FontFaceSet is ready. Putting the properties on different objects is
> enough to indicate that, the difference in name doesn't seem
> important?

The loaded/ready distinction exists elsewhere, too.  Using .loaded for
FontFaceSet is incorrect, since in many cases not all of the fonts in
the set will be loaded.

> In general it would be nice if we started establishing a pattern of a
> .ready() method (or property) on various objects to indicate that they
> are ready to be used. Rather than authors knowing that they need to
> listen to "load" events on images, "success" events on
> IDBOpenRequests, .loaded promise on FontFace objects and .ready()
> promise on FontFaceSets.

Yes, I'm actively working with Anne, Domenic, and others to help
figure out the right patterns for this that we can extend to the rest
of the platform.

~TJ

Re: Last Call for "CSS Font Loading Module Level 3"

[Jonas Sicking]

On Tue, May 27, 2014 at 10:41 AM, Tab Atkins Jr.  wrote:
>> Separately, FontFace.loaded seems to fulfill the same purpose as
>> FontFaceSet.ready(). I.e. both indicate that the object is done
>> loading/parsing/applying its data. It seems more consistent if they
>> had the same name, and if both were either an attribute or both were a
>> function.
>
> No, the two do completely different (but related) things.  Why do you
> think they're identical?  One fulfills when a *particular* FontFace
> object finishes loading, the other repeatedly fulfills whenever the
> set of loading fonts goes from non-zero to zero.

Semantically they both indicate "the async processing that this object
was doing is done". Yes, in one instance it just signals that a given
FontFace instance is ready to be used, in the other that the full
FontFaceSet is ready. Putting the properties on different objects is
enough to indicate that, the difference in name doesn't seem
important?

In general it would be nice if we started establishing a pattern of a
.ready() method (or property) on various objects to indicate that they
are ready to be used. Rather than authors knowing that they need to
listen to "load" events on images, "success" events on
IDBOpenRequests, .loaded promise on FontFace objects and .ready()
promise on FontFaceSets.

/ Jonas

Re: CfC: to create a new developer's list for WebApps' specs; deadline May 28

[Boaz Sender]

On Wed, May 21, 2014, Brian Kardell  wrote:


> I've been in several discussions on this topic over the past months, a
> good example of which is:
>
>  https://twitter.com/tobie/status/457075677851037696
>

This is a great point.


> In reaction to that, I'm running an experiment to hold such discussions
> in a manner that may prove more usable: Discourse. It is being used by a
> growing number of open source projects and is under active development.
>
> You are more than welcome to discuss WebApps related topics there, and
> I'm happy to add relevant categories, make tweaks that may be needed, etc.
>
> See:
>
>  http://discourse.specifiction.org/
>
> Feedback welcome!
>

As I said on www-style, +1 Robin. I just signed up, this looks great!

-- 
Boaz Sender

Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review

[Jonas Sicking]

On Tue, May 27, 2014 at 9:11 AM, Marcos Caceres  wrote:
>
> On May 27, 2014 at 9:25:26 AM, Ben Francis (bfran...@mozilla.com) wrote:
>> > As per our conversation in IRC, something else I'd like to highlight
>> is the fact that in the current version of the spec any web site
>> can host an app manifest for any web app.
>
> I'm really sorry, seems I wasn't very coherent on IRC - it's not possible for 
> site A to use site B's manifest unless site B explicitly shares it (using 
> CORS).
>
> Unlike with stylesheets or other 'ed resources, the fetch mode for 
> manifests is always "CORS" - meaning that the following would not work:
>
> fakegmail.com
> http://mail.google.com/manifest.json";>
>
> Even if the above "manifest.json" existed, the above would result in a 
> network error when the user agent tries to fetch "manifest.json" from 
> google.com. The error is because the request is not same origin, and because 
> google doesn't include the CORS header allowing the cross-origin request.
>
> The only way that gmail would allow "my own app store" to use its manifest 
> would be for Google to include the HTTP header:
>
> Access-Control-Allow-Origin: "http://myownappstore.com";

This is a bit of an abuse of CORS. Adding an
"Access-Control-Allow-Origin: *" header currently has the semantic
meaning of "any website can read the contents of this file". I.e. it
only means that the bits in the file are accessible from other
websites.

That means that for a webserver on the public internet it is currently
always safe to add the "Access-Control-Allow-Origin: *" header to any
file since all files can be read anyway by simply using a different
HTTP client than a browser, such as wget.

It does not currently mean, and I don't think it should mean, "I am ok
with acting as a manifest for any website".

I think restricting manifests to same-origin is the way to go. I would
not be surprised if manifests will eventually end up with similar
security properties as hosting HTML files currently does.

/ Jonas

RE: Composition events (was: contentEditable=minimal)

[Travis Leithead]

+Gary/Masayuki who can help with deciphering DOM L3 Events :-)

-Original Message-
From: Robin Berjon [mailto:ro...@w3.org] 
Sent: Tuesday, May 27, 2014 2:15 AM
To: Ben Peters; Jonas Sicking
Cc: public-webapps@w3.org
Subject: Composition events (was: contentEditable=minimal)

On 27/05/2014 01:52 , Ben Peters wrote:
> Composition Events for IMEs, CommandEvents with type insertText for
> all text input (including after Composition Events for IMEs)

I think we should be careful not to mix up composition events and IMEs. 
They may happen together, but IMEs have their own specific issues (e.g. 
popping up a window) that inline composition does not necessarily have. 
Also, IMEs can happen without composition: you could arguably popup a 
handwriting IME that would just insert text on commit without any 
composition taking place.

To stick to what I think is the simplest case, diacritic composition, 
here is what I believe the current D3E specification says (not that it's 
really clear on the matter, but I'm assuming best case scenario). For ñ 
you basically get:

   compositionstart "~"
   compositionend "ñ"

 From what you're saying above you'd like to replace that with:

   compositionstart "~"
   input "ñ"

I think we can make that work, it drops on event and moves the code 
around. If you look at the "Twitter Box" code:

 
https://gist.github.com/darobin/8a128f05106d0e02717b#file-twitter-html-L102

It basically would need to move what's in the compositionend handler 
inside the beforeinput handler, with a check to see if compoRange exists 
(or the event has isComposing=true).

(I'm assuming that compositionupdate stays as is since we need to update 
the rendering with it.)

Is that the sort of flow you had in mind?

PS: note I just noticed that the code in the Gist was not the latest I 
had and had a lot of "TODO" bits - I've udpated it to the latest.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Re: Last Call for "CSS Font Loading Module Level 3"

[Tab Atkins Jr.]

On Tue, May 27, 2014 at 1:22 AM, Jonas Sicking  wrote:
> I've provided this input through a few channels already, but I don't
> think the user of [SetClass] here is good (and in fact I've been
> arguing that SetClass should be removed from WebIDL).

Yes, there's an issue in the spec already saying that I need to move
off of [SetClass] and do Set-fakery instead, until JS stops being a
jerk and allows actual subclassing.  I wanted to get the LC
publication in before I had the time to make the change, but my intent
is pretty clear. ^_^

> First off you likely don't want to key the list of fonts on the
> FontFace object instance like the spec currently does. What it looks
> like you want here is a simple enumerable list of FontFace objects
> which are currently available to the document.
>
> Second, subclassing the ES6 Set class should mean that the following
> two calls are equivalent:
>
> Set.prototype.add.call(myFontFaceSet, someFontFace);
> myFontFaceSet.add(someFontFace);
>
> However I don't think the former would cause the rendering of the
> document to change in, whereas the latter would.
>
> Hence I would strongly recommend coming up with a different solution
> than using SetClass.

Yes, all of these issues are related to the fact that Set and Map are
currently broken in ES, and cannot be subclassed in any meaningful
way.

> Separately, FontFace.loaded seems to fulfill the same purpose as
> FontFaceSet.ready(). I.e. both indicate that the object is done
> loading/parsing/applying its data. It seems more consistent if they
> had the same name, and if both were either an attribute or both were a
> function.

No, the two do completely different (but related) things.  Why do you
think they're identical?  One fulfills when a *particular* FontFace
object finishes loading, the other repeatedly fulfills whenever the
set of loading fonts goes from non-zero to zero.

~TJ

RE: contentEditable=minimal

[Travis Leithead]

+Gary and Masayuki

--This seems very related to the discussion we are having regarding when to 
fire "beforeinput". "beforeinput" might be duplicating some of the use-cases 
that the insertText command event might be supporting.

-Original Message-
From: Robin Berjon [mailto:ro...@w3.org] 
Sent: Tuesday, May 27, 2014 2:39 AM
To: Ben Peters; Julie Parent
Cc: Johannes Wilm; public-webapps@w3.org
Subject: Re: contentEditable=minimal

On 27/05/2014 01:52 , Ben Peters wrote:
>> From: Robin Berjon [mailto:ro...@w3.org] On 23/05/2014 01:23 , Ben
>> Peters wrote:
 As I said I am unsure that the way in which composition events
 are described in DOM 3 Events is perfect, but that's only
 because I haven't used them in anger and they aren't supported
 much.
>>>
>>> My thought is that we can use CommandEvent with
>>> type="insertText". This would be the corollary to
>>> execComamnd("insertText"), and the data would be the ñ that is
>>> about to be inserted.
>>
>> But if you only get one event you can't render the composition as
>> it is carrying out.
>
> I believe Composition Events are very important for IME input, but we
> should fire CommandEvent with Insert text for all text input,
> including IME. Are you saying we should use Composition Events even
> for non-IME input?

I am not using an IME, and yet I could not type in French on my keyboard 
without composition.

Obviously, if I switch to Kotoeri input, I'll get composition *and* an 
IME popup. But for regular French input (in a US keyboard) I need:

   é -> Alt-E, E
   è -> Alt-`, E
   à -> Alt-`, A
   ô -> Alt-I, O
   ü -> Alt-U, U
   ñ -> Alt-˜, N (for the occasional Spanish)
   (and a bunch more)

Some older apps (you pretty much can't find them anymore) used to not 
display the composition as it was ongoing and only show the text after 
composition had terminated. That was survivable but annoying, and it 
only worked because composition in Latin-script languages is pretty 
trivial (except perhaps for all you Livonian speakers out there!), but I 
don't think it would be viable for more complex compositions. And even 
in simple cases it would confuse users to be typing characters with no 
rendering feedback.

Without composition events you can't render the ongoing composition. See 
what's going on at:

 
https://gist.github.com/darobin/8a128f05106d0e02717b#file-twitter-html-L81

That is basically inserting text in a range that's decorated to be 
underlined to show composition in progress. Composition updates 
*replace* the text in the range. And at the end the range is removed and 
text is inserted.

The above is for Mac, but I have distant memories of using something 
similar on Windows called the "US International Keyboard" where you 
could have apostrophes compose as accents, etc.. I don't recall how it 
was rendered though.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

RE: Last Call for "CSS Font Loading Module Level 3"

[Domenic Denicola]

I strongly agree on the SetClass matter. A conventional set of method names is 
fine, but that should not necessitate a misleading subclass relationship.

From: Jonas Sicking
Sent: ‎2014-‎05-‎27 04:22
To: Daniel Glazman; Domenic 
Denicola
Cc: cha...@w3.org; 
public-webapps; 
public-webfonts...@w3.org
Subject: Re: Last Call for "CSS Font Loading Module Level 3"

I've provided this input through a few channels already, but I don't
think the user of [SetClass] here is good (and in fact I've been
arguing that SetClass should be removed from WebIDL).

First off you likely don't want to key the list of fonts on the
FontFace object instance like the spec currently does. What it looks
like you want here is a simple enumerable list of FontFace objects
which are currently available to the document.

Second, subclassing the ES6 Set class should mean that the following
two calls are equivalent:

Set.prototype.add.call(myFontFaceSet, someFontFace);
myFontFaceSet.add(someFontFace);

However I don't think the former would cause the rendering of the
document to change in, whereas the latter would.

Hence I would strongly recommend coming up with a different solution
than using SetClass.

Separately, FontFace.loaded seems to fulfill the same purpose as
FontFaceSet.ready(). I.e. both indicate that the object is done
loading/parsing/applying its data. It seems more consistent if they
had the same name, and if both were either an attribute or both were a
function.

/ Jonas

Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review

[Anne van Kesteren]

On Tue, May 27, 2014 at 6:11 PM, Marcos Caceres  wrote:
> Where this could become a problem in the future is if manifests start 
> granting elevated privileges (e.g., access to specific APIs or unlimited 
> storage). However, the security model could then be refined so that, for 
> instance, only same origin manifests that are served over HTTPS get special 
> powers. In such a case, non-same-origin manifests could be "tainted" and only 
> the basic metadata from the manifest would be used by the user agent.

So long term are we expecting deployment on CDNs on sites that do not
want these features too? Sticking to same-origin seems simpler.


-- 
http://annevankesteren.nl/

Re: IndexedDB >> Proposed API Change: cursor.advance BACKWARD when direction is "prev"

[Joshua Bell]

On Fri, May 23, 2014 at 6:24 PM, marc fawzi  wrote:

> Here is a jsfiddle showing how .advance behaves when the range is
> restricted by .only
>
> Create new e.g. 7 items with names like "marc" and tags like "w1 w3 w5 w2"
> (random selection of tags with some tags appearing across multiple records
> (per the attached image)
>
> Enter "w2" or "w5" in the box next to 'get by tag' and click 'get by tag'
>
> You'll see the first 2 matching items, with primary keys 7 and 6
>
> Click 'get by tag' again and you'll see the next 2 matching items, with
> primary keys 4 and 2
>
> Click 'get by tag' again and you'll see the next and last matching item,
> with primary key 1
>
> Notice the way I advance the cursor each time in order to re-continue the
> search from where I left off in the previous invocation is by using the
> number of items already found
>
> http://jsfiddle.net/marcfawzi/y5ELj/
>
>
Thanks for sharing this example.


> It's the correct behavior but it would be easier imo if we have .find()
> for what .continue() and .continue(key) does and use .continue() to mean
> .advance(1) and .continue(n) to mean .advance(n)
>
> But I could be totally wrong. Just a harmless feedback at this point.
>
>
It's a reasonable suggestion. Unfortunately, we already have multiple
shipping implementations and code in the wild depending on the API as
specified, and this would be a breaking change. It's useful feedback if we
add new cursor/iteration APIs in the future, though - the current choice of
"continue" and "advance" vs. e.g. "find" or "seek" is pretty arbitrary and
can be a source of confusion.

Thanks again for following up with examples to ensure we understood your
feedback!


> :)
>
>
> On Fri, May 23, 2014 at 1:07 PM, marc fawzi  wrote:
>
>> <<
>> Thanks for following up! At least two IDB implementers were worried that
>> you'd found some browser bugs we couldn't reproduce.
>> >>
>> Yup. I had to figure this stuff out as the API is very low level (which
>> is why it can also be used in very powerful ways and also potentially very
>> confusing for the uninitiated)
>>
>> <> not restricted, if the cursor's key=7 and direction='prev' then I would
>> expect after advance(2) that key=5. If you're seeing key=2 can you post a
>> sample somewhere (e.g. jsfiddle.com?)>>
>>
>> In the case I have say 7 items [1,2,3,4,5,6,7] and the cursor's range is
>> restricted by IDBKeyRange.only(val, "prev") ... so if the matching (or in
>> range) items are at 7, 6, 4, 2, 1 then I can obtain them individually or in
>> contiguous ranges by advancing the cursor on each consecutive invocation of
>> my search routine, like so: on first invocation advance(1) from 7 to 6, on
>> second invocation advance(2) from 7 to 4, on third invocation advance(3)
>> from 7 to 2 and on fourth invocation advance(4) from 7 to 1. I could also
>> use advance to advance by 1 within each invocation until no matching items
>> are found but only up to 2 times an invocation (for a store with 700 or
>> 7 items we can advance by 1 about 200 times per invocation, but that's
>> arbitrary)
>>
>>  I can definitely post a jsfiddle if you believe the above is not in
>> accordance with the spec.
>>
>> As to continue(n) or continue(any string), i would make that
>> .find(something)
>>
>>
>>
>> On Fri, May 23, 2014 at 10:41 AM, Joshua Bell  wrote:
>>
>>> On Fri, May 23, 2014 at 9:40 AM, marc fawzi wrote:
>>>
 I thought .continue/advance was similar to the 'continue' statement in
 a for loop in that everything below the statement will be ignored and the
 loop would start again from the next index. So my console logging was
 giving confusing results. I figured it out and it works fine now.

>>>
>>> Thanks for following up! At least two IDB implementers were worried that
>>> you'd found some browser bugs we couldn't reproduce.
>>>
>>>
  For sanity's sake, I've resorted to adding a 'return'  in my code in
 the .success callback after every .advance and .continue so the execution
 flow is easier to follow. It's very confusing, from execution flow
 perspective, for execution to continue past .continue/.advance while at
 once looping asynchronously. I understand it's two different instances of
 the .success callback but it was entirely not clear to me from reading the
 docs on MDN (for example) that .advance / .continue are async.

>>>
>>> Long term, we expect JS to evolve better ways of expressing async calls
>>> and using async results. Promises are a first step, and hopefully the
>>> language also grows some syntax for them. IDB should jump on that train
>>> somehow.
>>>
>>>
 Also, the description of .advance in browser vendor's documentation,
 e.g. on MDN, says "Advance the cursor position forward by two places" for
 cursor.advance(2) but what they should really say is "advance the cursor
 position forward by two results." For example, let's say cursor first
 landed on an item with primary key = 7, and you is

[manifest] Fetching restriction, Re: [manifest] Update and call for review

[Marcos Caceres]

On May 27, 2014 at 9:25:26 AM, Ben Francis (bfran...@mozilla.com) wrote:
> > As per our conversation in IRC, something else I'd like to highlight  
> is the fact that in the current version of the spec any web site  
> can host an app manifest for any web app.

I'm really sorry, seems I wasn't very coherent on IRC - it's not possible for 
site A to use site B's manifest unless site B explicitly shares it (using 
CORS). 

Unlike with stylesheets or other 'ed resources, the fetch mode for 
manifests is always "CORS" - meaning that the following would not work:

fakegmail.com
http://mail.google.com/manifest.json";>

Even if the above "manifest.json" existed, the above would result in a network 
error when the user agent tries to fetch "manifest.json" from google.com. The 
error is because the request is not same origin, and because google doesn't 
include the CORS header allowing the cross-origin request. 

The only way that gmail would allow "my own app store" to use its manifest 
would be for Google to include the HTTP header:

Access-Control-Allow-Origin: "http://myownappstore.com";

Or from "*". 

You can see this in the spec in the "obtaining a manifest" algorithm [1].

Sorry again about the confusion. Hope that is more clear now!

> That means for example  
> that I could create my own app store for web apps and provide a listing  
> for a GMail app which users can add to their homescreen, without  
> any involvement from Google.

The only way one could do what you describe would be for "my own app store" to 
host its own manifests. So:
http://myownappstore.com/gmail/index.html

Would contain: 
http://myownappstore.com/gmail/manifest.json";>

Which would have:

{
   "name": "Gmail"
   "start_url": "http://gmail.com";
}

This would allow custom stores that provide tailored "app experiences" for 
sites that lack manifests. 

Where this could become a problem in the future is if manifests start granting 
elevated privileges (e.g., access to specific APIs or unlimited storage). 
However, the security model could then be refined so that, for instance, only 
same origin manifests that are served over HTTPS get special powers. In such a 
case, non-same-origin manifests could be "tainted" and only the basic metadata 
from the manifest would be used by the user agent.  

> It would be good to hear some opinions on whether it is a good thing  
> or a bad thing that manifests don't have to be served from the same  
> origin as the web app itself.

It would indeed be great to get some more opinions about this. 

[1] http://w3c.github.io/manifest/#obtaining-a-manifest

-- 
Marcos Caceres

[Bug 25895] New: [imports]: LinkImport definition could use some cleaning up

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25895

Bug ID: 25895
   Summary: [imports]: LinkImport definition could use some
cleaning up
   Product: WebAppsWG
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: gkrizsan...@mozilla.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

I guess what the spec is trying to say is:

partial interface HTMLLinkElement {
readonly attribute Document? import;
};

and without the "HTMLLinkElement implements LinkImport;" part

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

[Bug 25423] [Shadow]: event.path should return every nodes in the event path, instead of erasing nodes on descendant trees.

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25423

Hayato Ito  changed:

   What|Removed |Added

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

--- Comment #16 from Hayato Ito  ---
Done at
https://github.com/w3c/webcomponents/commit/2a44fb1a32a3a6aaa7bd82d37f6bd17eb2d67535

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

contentEditable and forms (was: contentEditable=minimal)

[Robin Berjon]

On 27/05/2014 09:19 , Piotr Koszuliński wrote:

Yes, it should be possible to disable whichever feature you don't need.
In some cases you don't need lists (because e.g. you're editing a text
that will become a content of a paragraph). And in some cases you don't
want bold/italic because your use case requires only structured HTML. So
being able to handle such commands is a one thing. But first of all
there should be no assumption that a user needs these buttons, because a
browser just don't know about that. If I think that users need toolbar,
I can render a custom one.


Much agreed. The browser should not show any markup/styling affordance 
for cE=minimal.



There's one more assumption that makes editing on mobile devices
(especially low-res devices) very hard. It's that if user focuses
editable, then he/she wants to type, so native keyboard should pop out.
Very often it's true, but in some cases user may want to select some
text and using toolbar apply styles or lists, etc. And when the keyboard
is visible there's very little space to do that. If there was any API to
control whether keyboard is visible, then we could achieve much better UX.


There are quite a few things from forms that I think could usefully 
become available in an editing context. We could benefit from having the 
inputmode attribute be allowed on any editable piece of text. For the 
specific use case you cite, an additional keyword of "none" might make 
sense too.


It possibly wouldn't hurt to have the placeholder attribute be available 
on all editable content, too. I'm less sure about the validation 
attributes (except perhaps required) but why not.


Obviously validation attributes only make sense if the editable content 
can contribute to forms. But it would make a lot of sense that it could. 
Today you have to resort to ugly hacks in which you somehow copy over 
the edited content into a textarea. That's pretty daft: in most use 
cases you're going to be submitting the content.


There are several ways in which we could handle this. One is to have any 
element with cE=minimal contribute to the form data set (when inside a 
form, or possibly when using the form attribute if someone remembers 
what the use case for that thing was). That's interesting, but I get a 
sense that it conflates two features. Another approach is to add a 
"submittable" attribute that can make the innerHTML of any element 
contribute to the form data set.


Thoughts?

--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: contentEditable=minimal

[Robin Berjon]

On 27/05/2014 01:52 , Ben Peters wrote:

From: Robin Berjon [mailto:ro...@w3.org] On 23/05/2014 01:23 , Ben
Peters wrote:

As I said I am unsure that the way in which composition events
are described in DOM 3 Events is perfect, but that's only
because I haven't used them in anger and they aren't supported
much.


My thought is that we can use CommandEvent with
type="insertText". This would be the corollary to
execComamnd("insertText"), and the data would be the ñ that is
about to be inserted.


But if you only get one event you can't render the composition as
it is carrying out.


I believe Composition Events are very important for IME input, but we
should fire CommandEvent with Insert text for all text input,
including IME. Are you saying we should use Composition Events even
for non-IME input?


I am not using an IME, and yet I could not type in French on my keyboard 
without composition.


Obviously, if I switch to Kotoeri input, I'll get composition *and* an 
IME popup. But for regular French input (in a US keyboard) I need:


  é -> Alt-E, E
  è -> Alt-`, E
  à -> Alt-`, A
  ô -> Alt-I, O
  ü -> Alt-U, U
  ñ -> Alt-˜, N (for the occasional Spanish)
  (and a bunch more)

Some older apps (you pretty much can't find them anymore) used to not 
display the composition as it was ongoing and only show the text after 
composition had terminated. That was survivable but annoying, and it 
only worked because composition in Latin-script languages is pretty 
trivial (except perhaps for all you Livonian speakers out there!), but I 
don't think it would be viable for more complex compositions. And even 
in simple cases it would confuse users to be typing characters with no 
rendering feedback.


Without composition events you can't render the ongoing composition. See 
what's going on at:



https://gist.github.com/darobin/8a128f05106d0e02717b#file-twitter-html-L81

That is basically inserting text in a range that's decorated to be 
underlined to show composition in progress. Composition updates 
*replace* the text in the range. And at the end the range is removed and 
text is inserted.


The above is for Mac, but I have distant memories of using something 
similar on Windows called the "US International Keyboard" where you 
could have apostrophes compose as accents, etc.. I don't recall how it 
was rendered though.


--
Robin Berjon - http://berjon.com/ - @robinberjon

Composition events (was: contentEditable=minimal)

[Robin Berjon]

On 27/05/2014 01:52 , Ben Peters wrote:

Composition Events for IMEs, CommandEvents with type insertText for
all text input (including after Composition Events for IMEs)


I think we should be careful not to mix up composition events and IMEs. 
They may happen together, but IMEs have their own specific issues (e.g. 
popping up a window) that inline composition does not necessarily have. 
Also, IMEs can happen without composition: you could arguably popup a 
handwriting IME that would just insert text on commit without any 
composition taking place.


To stick to what I think is the simplest case, diacritic composition, 
here is what I believe the current D3E specification says (not that it's 
really clear on the matter, but I'm assuming best case scenario). For ñ 
you basically get:


  compositionstart "˜"
  compositionend "ñ"

From what you're saying above you'd like to replace that with:

  compositionstart "˜"
  input "ñ"

I think we can make that work, it drops on event and moves the code 
around. If you look at the "Twitter Box" code:



https://gist.github.com/darobin/8a128f05106d0e02717b#file-twitter-html-L102

It basically would need to move what's in the compositionend handler 
inside the beforeinput handler, with a check to see if compoRange exists 
(or the event has isComposing=true).


(I'm assuming that compositionupdate stays as is since we need to update 
the rendering with it.)


Is that the sort of flow you had in mind?

PS: note I just noticed that the code in the Gist was not the latest I 
had and had a lot of "TODO" bits — I've udpated it to the latest.


--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: contentEditable=minimal

[Robin Berjon]

On 25/05/2014 20:40 , Piotr Koszuliński wrote:

Making some things unselectable might also be useful. IE has
unselectable, there's also -moz-user-select and friends. But this is
small fries for later I'd reckon.

There are also nested non-editable islands. We built very important
feature based on them - http://ckeditor.com/demo#widgets. Currently we
block their selection by preventing mousedown and we handle left/right
arrows. But cancelling selectionchange would allow us to control more
cases in a cleaner way.


I'd be curious to know what your take is on the best way to expose this. 
IE has an unselectable attribute, whereas Gecko and WebKit have a CSS 
property. In this thread we've been talking about using cancellable 
events for this (or if not cancellable, ones in which the selection can 
be modified on the fly).


On instinct I would tend to think that this not a great usage of CSS, 
it's much more tied to behaviour at a lower level. But it sort of is one 
of those borderline things (as many of the properties that initially 
came from the CSS UI module).


The scriptable option that we're consider is good in that it enables 
arbitrary cases, but it could be interesting to support a number of 
cases out of the box with a simpler (for developers) approach.


Let's imagine the following DOM:


  blah blah blah
  ...
  blah blah blah


If the cursor is at the beginning of the first p, you hold Shift, and 
click at the end of the second p, we could imagine that you'd get a 
Selection with two Ranges (one for each p) and not containing the 
unselectable widget. I *think* that's the most desirable default 
behaviour, and it's also one that can be pretty painful to control 
through script. In that sense an unselectable attribute would make 
sense. (I reckon that setting the widget to be cE=false would have the 
same effect, but it is nevertheless an orthogonal property.)


WDYT?

--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: contentEditable=minimal

[Robin Berjon]

Hi Ben,

On 27/05/2014 02:07 , Ben Peters wrote:

From: Robin Berjon [mailto:ro...@w3.org] Even without accounting
for touch screens, you really want the platform to be the thing
that knows what Ctrl-Shift-Left means so you don't have to support
it yourself (and get it wrong often).


Agree. One way to do this would be BeforeSelectionChange having a
commandType indicating select forward and select by word.


I think we agree at the high level but might disagree over smaller
details. You seem to want something that would roughly resemble the
following:

BeforeSelectionChange
{
  direction:  "forward"
, step:   "word"
}

whereas I would see something capturing information more along those lines:

BeforeSelectionChange
{
  oldRange:  [startNode, startOffset, endNode, endOffset]
, newRange:  [startNode, startOffset, endNode, endOffset]
}

I think that the latter is better because it gives the library the
computed range that matches the operation, which as far as I can imagine
is what you actually want to check (e.g. check that the newRange does
not contain something unselectable, isn't outside a given boundary, etc.).

The former requires getting a lot of details right in the spec, and
those would become hard to handle at the script level. On some platforms
a triple click (or some key binding) can select the whole line. This not
only means that you need direction: "both" but also that the script
needs a notion of line that it has no access to (unless the Selection
API grants it). What makes up a "word" as a step also varies a lot (e.g.
I tend to get confused by what Office apps think a word is as it doesn't
match the platform's idea) and there can be interesting interactions
with language (e.g. is "passive-aggressive" one word or two? What about
"co-operation"?).

But maybe you have a use case for providing the information in that way
that I am not thinking of?


Not all of those are separate, though. Voice input is just an input
(or beforeinput) that's more than one character long. There's
nothing wrong with that. So is pasting (though you need cleaning
up). Composition you need to handle, but I would really, really
hope that the platform gives you a delete event with a range that
matches what it is expected to delete rather than have you support
all the modifiers (which you'll get wrong for the user as they are
platform specific). As seen in the code gist I posted, given such a
delete event the scripting is pretty simple.


I agree, except that I don't know why we want paste to fire two
'intention' events (paste and input). Seems like we should make it
clear that the intention is insert text (type, voice, whatever),
remove text (delete, including what text to remove), or paste (so you
can clean it up).


I don't think we want to fire both paste and input, but if my reading is 
correct that is the case today (or expected to be — this isn't exactly 
an area of high interop).


--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: contentEditable=minimal

[Robin Berjon]

On 27/05/2014 01:47 , Ben Peters wrote:

-Original Message- From: Robin Berjon
On 26/05/2014 05:43 , Norbert Lindenberg wrote:

Were any speakers of bidirectional languages in the room when
this was discussed?


I don't know what languages the others speak. That said, my
recollection was that this was presented along the lines of "we've
had regular requests to support selecting text in geometric rather
than logical orders".


I have also heard these requests from the bi-directional experts here
at Microsoft. A single, unbroken selection is what we're told users
want, and multi-selection makes this possible.


Thinking about this a little bit more: I don't imagine that the 
Selection API should prescribe the UI that browsers choose to support in 
order to select bidi text, on the contrary they should be allowed to 
innovate, experiment, follow various platform conventions, etc. But if 
we don't support multi-range selection, then only one model is possible 
which precludes unbroken selections.


I think that this strongly pushes in the direction of supporting 
multiple ranges.


--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: Last Call for "CSS Font Loading Module Level 3"

[Jonas Sicking]

I've provided this input through a few channels already, but I don't
think the user of [SetClass] here is good (and in fact I've been
arguing that SetClass should be removed from WebIDL).

First off you likely don't want to key the list of fonts on the
FontFace object instance like the spec currently does. What it looks
like you want here is a simple enumerable list of FontFace objects
which are currently available to the document.

Second, subclassing the ES6 Set class should mean that the following
two calls are equivalent:

Set.prototype.add.call(myFontFaceSet, someFontFace);
myFontFaceSet.add(someFontFace);

However I don't think the former would cause the rendering of the
document to change in, whereas the latter would.

Hence I would strongly recommend coming up with a different solution
than using SetClass.

Separately, FontFace.loaded seems to fulfill the same purpose as
FontFaceSet.ready(). I.e. both indicate that the object is done
loading/parsing/applying its data. It seems more consistent if they
had the same name, and if both were either an attribute or both were a
function.

/ Jonas

Re: contentEditable=minimal

[Piotr Koszuliński]

On Tue, May 27, 2014 at 1:48 AM, Ben Peters wrote:

> >>> 5. There should be no native toolbars in cE=minimal (and other native
> UI
> >>> interfering) like the one Safari opens on iOS if you have non-empty
> >>> selection.
> >>I haven't yet checked exactly what's in the iOS toolbar, but generally
> >>I don't think we should dictate UI. Clearly on mobile we don't want to
> >>forbid browsers to bring up the virutal keyboard, which is a form of
> >>"native UI". And the spellcheck UI that safari displays also doesn't
> >>seem bad if spellchecking is enabled.
> >>
> >>And UI for cut/copy/past that android renders seems good to render
> >>*somewhere* when there's selection.
> >
> >On iOS the contextual toolbar not only contains copy/cut options which
> are of course ok, but it also contains bold, italic and lists buttons.
> That's unacceptable and I assume this kind of native UI will not be
> implemented for cE=minimal.
>
> The goal of Command Event is to make this a non-issue. If sites respond to
> bold/italic/list commands they can handle this UI just fine. Are you
> concerned that a site may not use bold so the button would have no effect?
>

Yes, it should be possible to disable whichever feature you don't need. In
some cases you don't need lists (because e.g. you're editing a text that
will become a content of a paragraph). And in some cases you don't want
bold/italic because your use case requires only structured HTML. So being
able to handle such commands is a one thing. But first of all there should
be no assumption that a user needs these buttons, because a browser just
don't know about that. If I think that users need toolbar, I can render a
custom one.

There's one more assumption that makes editing on mobile devices
(especially low-res devices) very hard. It's that if user focuses editable,
then he/she wants to type, so native keyboard should pop out. Very often
it's true, but in some cases user may want to select some text and using
toolbar apply styles or lists, etc. And when the keyboard is visible
there's very little space to do that. If there was any API to control
whether keyboard is visible, then we could achieve much better UX.


-- 
Piotrek Koszuliński
CKEditor JavaScript Lead Developer