gmane.org.w3c.appformats

Re: [XHR] chunked

Jonas Sicking — 2012-05-24T00:54:56

No change came out of this thread. I think we established that there
is a need for "chunked-arraybuffer". This thread contained some
controversy about whether "chunked-text" is needed, but in the end the
controversy didn't actually seem relevant to the question at hand.

Is there a reason not to add "chunked-text" and "chunked-arraybuffer"
to the spec right now?

/ Jonas

Re: [File API] File behavior under modification

Jonas Sicking — 2012-05-23T23:27:30


In Gecko we currently lazily in some cases get the file size and the
lastModificationDate (which we just implemented the other day). However
getting that lazily means that we sometimes have to do synchronous IO which
is something we want to avoid. Hence we're working towards always getting
the file size and last modification date when the File object is
instantiated and would never change after that.

I would imagine other UAs would want to avoid such synchronous IO too?

We absolutely should not have an API which forces implementations to do
synchronous IO, hence I don't think we can require that
lastModificationDate should stay up-to-date, or that reading from it should
throw if the file has changed on disk. The only operations that we can make
fail are asynchronous ones, which means that we can only make file-reading
fail.

The wording in the spec is unfortunate since it says that reading should
"throw". Instead we should say that reading should fail, and then leave it
up to the various APIs to define w

Re: [File API] File behavior under modification

Charles Pritchard — 2012-05-23T23:00:14

OK, I agree with this method. It'll fix both the Mozilla and WebKit 
families in respect to their current behavior. It may already be 
Mozilla's behavior (I'm a bit behind on tracking it).

-Charles

Re: Shrinking existing libraries as a goal

Paul Bakaus — 2012-05-23T22:38:22

I wholeheartedly support this proposal. +1000.

From: Yehuda Katz <wycats< at >gmail.com<mailto:wycats< at >gmail.com>>
Date: Wed, 16 May 2012 00:32:51 -0400
To: <public-webapps< at >w3.org<mailto:public-webapps< at >w3.org>>
Subject: Shrinking existing libraries as a goal
Resent-From: <public-webapps< at >w3.org<mailto:public-webapps< at >w3.org>>
Resent-Date: Wed, 16 May 2012 04:33:57 +0000

In the past year or so, I've participated in a number of threads that were implicitly about adding features to browsers that would shrink the size of existing libraries.

Inevitably, those discussions end up litigating whether making it easier for jQuery (or some other library) to do the task is a good idea in the first place.

While those discussions are extremely useful, I feel it would be useful for a group to focus on proposals that would shrink the size of existing libraries with the implicit assumption that it was a good idea.

If there is a strong reason that people feel that a focused effort to identify ways to shrink existing popular libr

Re: [fullscreen] fullscreenEnabled and the fullscreen enabled flag

Chris Pearce — 2012-05-23T22:31:07

I'm happy to move the discussion to public-webapps, thanks for the heads up.


Cheers,
Chris P.

Re: [File API] File behavior under modification

Glenn Maynard — 2012-05-23T22:32:59


No, you can find out simply by requesting a read (even a 0-byte one should
work, I think) and seeing if it fails.  Also, there's no guarantee that the
mtime is what the browser uses to determine whether a file has changed,
where simply attempting a read doesn't have that problem.

file watcher hooks (which are available on engines like node.js).

(This would be far more complicated.  None of this precludes it, but it's
not needed for any of this.)

I think that's where the spec writing for this is challenging. I'd lean

It doesn't mandate snapshot capabilities.  If the file is changed, reading
the File doesn't give you the old data; it fails with an error.  That's
easy to for the browser to check: compare the mtime of the file (probably
both before and after the read, to avoid races).  Native applications could
fool this if they want to, but this isn't a problem in practice.  Also,
implementations are free to use other mechanisms to implement the "snapshot
state" concept (eg. file change notification APIs)

RE: DOMParser Errors Should Be Exceptions

Tony Ross — 2012-05-23T19:38:38


Has this been examined recently? In IE9+ DOMParser throws an exception when an XML parsing error is encountered. I've yet to hear of this causing a problem.

-Tony

Re: DOMParser Errors Should Be Exceptions

João Eiras — 2012-05-23T19:22:49


Opera thrown an exception long time ago and since version 9.5 it changed  
the behavior to return the bogus parsererror tree because it caused yahoo  
mail to fail back them (among other things).

While the current behavior of returning the parsererror document is  
inappropriate, I afraid it also unchangeable.

Re: DOMParser Errors Should Be Exceptions

Ms2ger — 2012-05-23T19:08:32

Opera has reported this is not web-compatible.

Ms2ger

DOMParser Errors Should Be Exceptions

Yehuda Katz — 2012-05-23T19:03:19

In the current DOM parsing spec[1], errors in XML (or SVG) are handled as
follows:

its
describe

In practice, browsers implement error handling in this way. The output for
the following code is given below.

(new XMLSerializer).serializeToString((new
DOMParser).parseFromString("<tr>hi", "text/xml"));

As a result, jQuery looks for a parserror tag and re-raises an error when
parsing XML[2].

In my view, the DOMParser should throw an exception, and not insert a
partially unspecified parserror tag.

Thoughts?

=== Output

Webkit:

"<tr><parsererror xmlns="http://www.w3.org/1999/xhtml" style="display:
block; white-space: pre; border: 2px solid #c77; padding: 0 1em 0 1em;
margin: 1em; background-color: #fdd; color: black"><h3>This page contains
the following errors:</h3><div
style="font-family:monospace;font-size:12px">error on line 1 at column 7:
Extra content at the end of the document
</div><h3>Below is a rendering of the page up to the first
error.</h3></parsererror>hi</tr>"

Firefox:

"<?xml-stylesheet href

Re: Howto spec

Anne van Kesteren — 2012-05-23T18:40:27

Added "the separation of method definition from arguments, exceptions,
and return value".



Most specifications (if not all) using ReSpec.js have this problem. I
believe that is because it is the default setup.

Re: Howto spec

Anne van Kesteren — 2012-05-23T18:30:25

It's a tradeoff:

ReSpec.js pro:

* No setup costs

ReSpec.js con:

* Loads slower because of script. You get a flash of unstyled content.
User experience suffers.
* Legacy DOM-style of defining methods/attributes appears to be the default.

Anolis pro:

* Cross-specification cross-references

Anolis con:

* Harder (requires Python)

In the end it comes down to what the editor wants; I think Anolis is
better because the end user experience is better.

Re: [File API] File behavior under modification

Charles Pritchard — 2012-05-23T17:57:23



I can't imagine that Mozilla's behavior here is intended. Only by returning a live mtime can authors be aware of whether or not the file has changed from a previous state.

We did go through this discussion quite awhile ago when I recommended file watcher hooks (which are available on engines like node.js).

It seems like there's a split between the ideal (take an immutable snapshot of the file) and the real world, where the File object represents an entry, such as FileEntry, not a static blob of data.

I think that's where the spec writing for this is challenging. I'd lean toward documenting what's really out there instead of mandating snapshot capabilities in the file system.

Re: Howto spec

Glenn Adams — 2012-05-23T17:48:52


relevant links

[1] https://github.com/darobin/webidl.js
[2] https://github.com/aredridel/html5

Re: Howto spec

Glenn Adams — 2012-05-23T17:29:15



editor tools are at the editors' prerogative, so we should not mandate
specific tools i think

in fact, i am not completely happy with either respec or anolis, and have
put together something of a hybrid i'm using on cssom*;  in particular,
what i'm doing is:

   - writing all IDL and related documentation in WebIDL format, with each
   top-level definition in a distinct file, while using 'Documentation'
   extended attributes in the WebIDL files that contains both substitution
   patterns and markup, rather akin to javadoc but with different substitution
   keywords that better pertain to the WebIDL usage context;
   - use a driver file with CPP includes, then running (gnu) CPP to create
   a single IDL resource for the subsequent processing
   - use robin's WebIDLParser.js [1] (via node.js) to validate and dump
   JSON representation of IDL
   - use Aria Stewart's (aredridel) HTML5.js parser [2] (via node.js) to
   parse then serialize with substitution replacement based on the JSON IDL,
   e.g., <!--wi

Re: Howto spec

Glenn Adams — 2012-05-23T17:09:22


I would like to see more explanation of some statements under the "Legacy
DOM-style" section, particularly:

   - what is the "particular style of defining methods and attributes" that
   is to be discouraged?
   - how does ReSpec.js use or promote the discouraged particulars?

Re: Howto spec

Dimitri Glazkov — 2012-05-23T15:55:09

This is neat! I especially appreciated the Method/Attribute patterns.
I will use this.

Should I be concerned about what seems to be a lively competition
between ReSpec and Anolis. Do we need this tussle? Can we not just
decide which tool to use?

:DG<

On Wed, May 23, 2012 at 5:45 AM, Anne van Kesteren <annevk< at >annevk.nl> wrote:

New list: System Applications

Robin Berjon — 2012-05-23T15:36:07

Hi all,

there has recently been a fair amount of work and discussion about building entire operating systems using Web technology. As discussed on the DAP list, the W3C is currently putting together a charter for a "System Applications" group that would handle the specs required to write such applications.

Before the group is started, a mailing list has been set up in order to discuss various aspects of the draft charter and try to organise the work. You'll find all the details at:

    http://lists.w3.org/Archives/Public/public-sysapps/

Join and enjoy!

Re: [File API] File behavior under modification

Glenn Maynard — 2012-05-23T13:58:52


Right.  For simple Blobs without a mutable backing store, all of this
essentially optimizes away.

We should also make it clear whether .size and .lastModifiedDate should

It would be the values at the time of the snapshot state.  (I doubt it was
ever actually intended that lastModifiedDate always return the file's
latest mtime.  We'll find out when one of the editors gets around to this
thread...)

Howto spec

Anne van Kesteren — 2012-05-23T12:45:05

Hi,

I have made some updates to the "howto spec" wiki page outlining how
you should go about writing a specification, with some emphasis on
specifications for APIs.

http://wiki.whatwg.org/wiki/Howto_spec

In particular the "Patterns" and "Legacy DOM-style" sections are
probably of interest. I would love to have feedback to see what else
people would like to see explained or how what is explained thus far
can be done better.

Thanks,

Re: Feedback on Quota Management API

Anne van Kesteren — 2012-05-23T12:32:03

I noticed something else. StorageInfo is marked as Supplemental and
NoInterfaceObject, but I do not think either is meant to be used here.
Supplemental has been replaced by "partial interface" (rather than
"[Supplemental] interface"), but is only supposed to be used if this
is not the original definition (and I do not think StorageInfo is
defined elsewhere). NoInterfaceObject is used prevent certain
interfaces from being prototyped, but I do not think we want that here
either.