Re: Should minimal contentEditable default text input (was: contentEditable=minimal)

2014-05-30 Thread Anne van Kesteren
On Fri, May 30, 2014 at 12:50 AM, Julie Parent jpar...@gmail.com wrote:
 Or, rather than tying this concept to contentEditable, with all the
 assumptions and complications that brings up, why not expose this building
 block as a completely separate attribute?

Just a DOM API perhaps as you're not going to get far without
scripting anyway? Interaction with contentEditable features will have
to be defined. This could maybe throw if the element was already
editable and if this is already active, maybe contentEditable stuff
should have no effect.


-- 
http://annevankesteren.nl/



[Bug 25908] Is element editable if it's hidden

2014-05-30 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25908

Aryeh Gregor a...@aryeh.name changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #5 from Aryeh Gregor a...@aryeh.name ---
(In reply to Anne from comment #4)
 Yes, HTML defers to HTML editing APIs for the definition of
 isContentEditable and there it is quite clear:
 https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#editable

Don't put much stock in this definition, I made it up on a whim and didn't
consider this issue.  That said, making it depend on CSS properties doesn't
seem desirable to me offhand.  The reason given on the Chromium bug is

 Since users can't edit elements not rendered, Blink considers
 such elements aren't editable. This is reason why
 isContentEditable returns false for elements which have
 contenteditable=true attribute but hidden.

I don't find this convincing.  You can't access the inside of the element
because you can't put the cursor there, but I wouldn't say that means it's not
editable, just that you don't have any way to tell the UA to do anything to it.
 It's perfectly editable if, say, script places the cursor there -- which is
very relevant, since we're talking about a script-accessible property here. 
Per spec, the editor doesn't treat hidden elements the same as non-editable
elements at all.

(In reply to Anne from comment #1)
 This should be true. We don't want isContentEditable to have to do
 synchronous style resolution.

Ryosuke once told me that contenteditability is implemented by a CSS property
in WebKit anyway, so they have to.  (In Gecko, it's implemented by a flag bit
that's set and unset recursively as needed with special code.  This has caused
bugs that the WebKit approach would probably have avoided.)

But I agree that this is another reason not to have it this way in the spec. 
So in the absence of anyone actively editing the editing spec, I'll call this
RESOLVED.

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



[Bug 25924] New: [Imports]: The spec. is not very specific about the edge cases of the load

2014-05-30 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25924

Bug ID: 25924
   Summary: [Imports]: The spec. is not very specific about the
edge cases of the load
   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

It can be that I'm overlooking something, but I don't see answers for these
questions in the spec:

- what about data urls? are they allowed? and blobs?
- what about HTTP error pages? (is redirection allowed?)
- what about response other than text/html?
- should we be able to stop external resource loading for only one import (and
it's subtree) or only for the whole master document?

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



Re: [Bug 25376] - Web Components won't integrate without much testing

2014-05-30 Thread Jarrod Overson
On Fri, May 23, 2014 at 8:10 AM, Brian Kardell bkard...@gmail.com wrote:


   Web Components install complex concepts (e.g. decorators) by
 introducing unique, complex, opaque behaviours, abandoning the pure nature
 of presentation.

 Decorators were dropped last i checked, but many of the new features
 create a lightweight alternative to iframes and, again, give us, new powers
 to create.


Does anyone have a reference for this?


[Bug 25924] [Imports]: The spec. is not very specific about the edge cases of the load

2014-05-30 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25924

Gabor Krizsanits gkrizsan...@mozilla.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Gabor Krizsanits gkrizsan...@mozilla.com ---
After talking to Anne, I think I got all my questions answered... so I'm
closing this for now.

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



[Bug 25915] Cross-origin requests

2014-05-30 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25915

Arun a...@mozilla.com changed:

   What|Removed |Added

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

--- Comment #1 from Arun a...@mozilla.com ---
(In reply to Anne from comment #0)
 I'm not sure why
 http://dev.w3.org/2006/webapi/FileAPI/#cross-origin-requests-on-blobs is
 included in this specification. That should follow from URL / Fetch, no?
 
 Duplicate requirements are bad.


You're right. I've fixed this now so that Fetch is normative.

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



[Bug 25914] No definition of parsing blob's scheme data

2014-05-30 Thread bugzilla
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25914

Arun a...@mozilla.com changed:

   What|Removed |Added

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

--- Comment #4 from Arun a...@mozilla.com ---
(In reply to Anne from comment #3)
 If we use scheme data as identifier, fine.
 
 Yes, I'd like a way to extract an origin out of the scheme data.

OK, I think 

http://dev.w3.org/2006/webapi/FileAPI/#extractionOfOriginFromBlobURL 

will work.

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



WebApp installation via the browser

2014-05-30 Thread Jeffrey Walton
I have a question about Use Cases for Installable WebApps located at
https://w3c-webmob.github.io/installable-webapps/.

Under section Add to Homescreen, the document states:

... giving developers the choice to tightly integrate their web
applications into the OS directly from the Web browser is
still somewhat new...

... [Installable WebApps] are different in that the
applications are installed directly from the browser itself
rather than from an app store...

It sounds like to me the idea is to allow any site on the internet to
become a app store. My observations are the various app stores provide
vendor lock-in and ensure a revenue stream. Its architected into the
platform. Companies like Apple, Microsoft and RIM likely *won't* give
up lock-in or the revenue stream (at least not without a fight).

Are there any platforms providing the feature? Has the feature gained
any traction among the platform vendors?

Thanks in advance.



Re: WebApp installation via the browser

2014-05-30 Thread Brendan Eich

Jeffrey Walton wrote:

Are there any platforms providing the feature? Has the feature gained
any traction among the platform vendors?


Firefox OS wants this.

/be



Re: WebApp installation via the browser

2014-05-30 Thread Jeffrey Walton
On Fri, May 30, 2014 at 9:04 PM, Brendan Eich bren...@mozilla.org wrote:
 Jeffrey Walton wrote:

 Are there any platforms providing the feature? Has the feature gained
 any traction among the platform vendors?

 Firefox OS wants this.
Thanks Brendan.

As a second related question, is an Installable WebApp considered a
side-loaded app?



Re: WebApp installation via the browser

2014-05-30 Thread Brendan Eich

Jeffrey Walton wrote:

On Fri, May 30, 2014 at 9:04 PM, Brendan Eichbren...@mozilla.org  wrote:

Jeffrey Walton wrote:

Are there any platforms providing the feature? Has the feature gained
any traction among the platform vendors?

Firefox OS wants this.

Thanks Brendan.

As a second related question, is an Installable WebApp considered a
side-loaded app?


Sicking can answer with more authority, but side-loaded or downloaded, 
so long as the user installs it, no difference.


/be



Re: WebApp installation via the browser

2014-05-30 Thread marc fawzi
Another question about the subject

https://developers.google.com/chrome/apps/docs/developers_guide

This says that they can also run in the background, which is huge.

I'm not sure if they support content scripts like extensions and packaged
apps do. I would love to find out if the spec says anything about that.

Thanks in advance,

Marc


On Fri, May 30, 2014 at 7:42 PM, Jeffrey Walton noloa...@gmail.com wrote:

 On Fri, May 30, 2014 at 9:04 PM, Brendan Eich bren...@mozilla.org wrote:
  Jeffrey Walton wrote:
 
  Are there any platforms providing the feature? Has the feature gained
  any traction among the platform vendors?
 
  Firefox OS wants this.
 Thanks Brendan.

 As a second related question, is an Installable WebApp considered a
 side-loaded app?