Re: [whatwg] Foreign fallback appcache entries

[Michael Nordman]

Right you are!

That's pathological content, listing a page as a fallback but having
that page refer to a different manifest. What behavior results from
the currently spec'd algorithms, repeatedly trying to load the url,
finding the fallback, detecting foreign'ness and retrying? Or is the
foreign bit examined when loading fallbacks for top level pages?

Good, the latter. Looks like foreign fallbacks resources are weeded
out in 6.5.1 Navigating across documents, step 16.

So you're looking for  a note that says "by the way, fallbacks may get
marked as foreign too and be excluded from loads for script context
navigations as a result". That makes sense.

On Thu, Sep 30, 2010 at 7:29 PM, Alexey Proskuryakov  wrote:
>
> "Foreign" means that the main resource has a different manifest than the one 
> referencing it. E.g.
>
> foo.manifest:
> CACHE MANIFEST
> iframe.html
>
> iframe.html:
> 
> ...
>
> So, I don't think that the same origin requirement answers this. WebKit bug 
>  has a live demo (Firefox 
> 3.6.10 handles it correctly, according to my reading of the spec).
>
> - WBR, Alexey Proskuryakov
>
>
> 30.09.2010, в 18:21, Michael Nordman написал(а):
>
>> I don't think 'fallback' entries can be foreign because they must be
>> of the same-origin as the manifest.
>>
>> "Fallback namespaces and fallback entries must have the same origin as
>> the manifest itself."
>>
>> On Thu, Sep 30, 2010 at 4:38 PM, Alexey Proskuryakov  wrote:
>>>
>>> In definitions of application cache entry categories, it's mentioned that 
>>> an explicit entry can also be marked as foreign. This contrasts with 
>>> fallback entries, for which no such notice is made.
>>>
>>> It still appears that the intention was for fallback entries to sometimes 
>>> be foreign - in particular, section 6.5.1 says "Let candidate be the 
>>> fallback resource" and then "If candidate is not marked as foreign..."
>>>
>>> I found it confusing that there is a specific mention of foreign for 
>>> explicit entries, but not for fallback ones.
>>>
>>> - WBR, Alexey Proskuryakov
>>>
>>>
>
>
>

Re: [whatwg] Foreign fallback appcache entries

[Alexey Proskuryakov]

"Foreign" means that the main resource has a different manifest than the one 
referencing it. E.g.

foo.manifest:
CACHE MANIFEST
iframe.html

iframe.html:

...

So, I don't think that the same origin requirement answers this. WebKit bug 
 has a live demo (Firefox 3.6.10 
handles it correctly, according to my reading of the spec).

- WBR, Alexey Proskuryakov


30.09.2010, в 18:21, Michael Nordman написал(а):

> I don't think 'fallback' entries can be foreign because they must be
> of the same-origin as the manifest.
> 
> "Fallback namespaces and fallback entries must have the same origin as
> the manifest itself."
> 
> On Thu, Sep 30, 2010 at 4:38 PM, Alexey Proskuryakov  wrote:
>> 
>> In definitions of application cache entry categories, it's mentioned that an 
>> explicit entry can also be marked as foreign. This contrasts with fallback 
>> entries, for which no such notice is made.
>> 
>> It still appears that the intention was for fallback entries to sometimes be 
>> foreign - in particular, section 6.5.1 says "Let candidate be the fallback 
>> resource" and then "If candidate is not marked as foreign..."
>> 
>> I found it confusing that there is a specific mention of foreign for 
>> explicit entries, but not for fallback ones.
>> 
>> - WBR, Alexey Proskuryakov
>> 
>> 

Re: [whatwg] Foreign fallback appcache entries

[Michael Nordman]

I don't think 'fallback' entries can be foreign because they must be
of the same-origin as the manifest.

"Fallback namespaces and fallback entries must have the same origin as
the manifest itself."

On Thu, Sep 30, 2010 at 4:38 PM, Alexey Proskuryakov  wrote:
>
> In definitions of application cache entry categories, it's mentioned that an 
> explicit entry can also be marked as foreign. This contrasts with fallback 
> entries, for which no such notice is made.
>
> It still appears that the intention was for fallback entries to sometimes be 
> foreign - in particular, section 6.5.1 says "Let candidate be the fallback 
> resource" and then "If candidate is not marked as foreign..."
>
> I found it confusing that there is a specific mention of foreign for explicit 
> entries, but not for fallback ones.
>
> - WBR, Alexey Proskuryakov
>
>

[whatwg] Foreign fallback appcache entries

[Alexey Proskuryakov]

In definitions of application cache entry categories, it's mentioned that an 
explicit entry can also be marked as foreign. This contrasts with fallback 
entries, for which no such notice is made.

It still appears that the intention was for fallback entries to sometimes be 
foreign - in particular, section 6.5.1 says "Let candidate be the fallback 
resource" and then "If candidate is not marked as foreign..."

I found it confusing that there is a specific mention of foreign for explicit 
entries, but not for fallback ones.

- WBR, Alexey Proskuryakov

[whatwg] New Test Suite for Rich Text Editing (contentEditable & JS)

[Roland Steiner]

 [Apologies if you have seen this already!]

Hi all,

As you probably know, the current state of rich text editing
functionalities in user agents (contentEditable, and the JavaScript
functions execCommand and queryCommandValue, etc.) is not quite ideal. There
are different specs listing different commands (in addition to the relevant
parts of the HTML5 spec, there's also the Midas spec:
http://www.mozilla.org/editor/midas-spec.html), and different UAs implement
different parts of both. Even common parts are often implemented differently
and may yield different result HTML and/or result selections.

Now, in order to document the current state of all of this, we are currently
setting up a new rich text editing test suite as part of the larger
browserscope (http://www.browserscope.org) framework. It is largely an
extension and generalization of the already existing "RichText" suite
there. We hope such a suite helps in identifying the main problem areas and
in improving interoperability. In turn, this should help reaching a common
set of editing commands and, generally, editing functionalities with
well-defined behavior that are useful for web authors.

A beta version can be accessed at
http://www.browserscope.org/richtext2/test (note
that being beta, the suite is not yet accessible from the main page at
http://www.browserscope.org). Please understand that we are still adding and
cleaning up tests, and details of the presentation. But at even at the
current, early stage it should give a good idea of the direction of the
suite. Indeed, as achieving consensus on the tests contained in the suite is
meant to be a community effort, it is bound to change and being extended
over time, as it solidifies based on input from contributors.

Therefore, as this can only benefit from the participation of as many
parties as possible, we would like to solicit input from everyone interested
in the field - or anyone with past grievances about bugs and
incompatibilities in the area! ;). For suggestions, criticism, and general
discussion on the suite and tests, please post a mail (or many!) at the
browserscope mailing list at browsersc...@googlegroups.com.


Best regards,

- Roland Steiner