[whatwg] You can now subscribe to changes to the WHATWG spec on a per-topic basis

[Ian Hickson]

On Mon, 21 Nov 2011, Boris Zbarsky wrote:
> > 
> > Another option is for someone (possibly me) to create a system whereby 
> > people can subscribe to specific portions of the specification, and 
> > for a tool to detect when a diff affects that portion and e-mail them. 
> > I'm not exactly sure how to make that work, but if it's something 
> > people are interested in, we could figure something out.
> 
> This could be interesting if new sections are added rarely enough

Ok, I've added a system where you can subscribe to specific sections of 
the spec to be notified of changes.

The available topics currently are:
  Canvas
  HTML (everything not covered by another topic)
  HTML Syntax and Parsing
  Microdata
  Offline Web Applications
  Server-Sent Events
  Video Text Tracks (, WebVTT)
  Video and Audio
  Web Storage
  Web Workers
  WebSocket API

I'm happy to add new topics if there's enough demand. When I add a topic, 
the topic that previously covered that part of the spec will normally be 
notified as part of the checkin that changes the labeling.

To subscribe to a topic, click the "Edit Subscriptions" button at the top 
right of the spec, and follow the on-screen instructions.

I haven't fully tested this yet so if you run into any problems, e.g. I 
spam you every last edit fifteen times over, let me know.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Using requestFileSystem to setup mounts

[Glenn Maynard]

 On Tue, Nov 22, 2011 at 6:06 AM, Kinuko Yasuda  wrote:

> Putting aside the API discussion, actually I like the idea having one
> shared
> isolated filesystem that contains multiple directories/files being dropped
> in,
> as in that way both the UA and script can easily distinguish the set of
> dropped files/directories as a single group sharing the same filesystem
> object.  I don't think that must be enforced as a part of spec or
> recommendation, but I don't think it's strange having multiple
> files/directories being dropped in the same virtual root directory either.
> (I'm not saying we should weigh rFS approach more than .entries
> or getAsEntry)
>

This would lead to interop problems if it's not consistent, though.  For
example, if my application creates ZIP files, and the user drags two files
into the root directory of the ZIP, he wants to put those files at the top
of the ZIP:

/file1.txt
/file2.txt

If the UA creates a virtual directory for that drag, then it'd end up
putting the files in a subdirectory with the name of the virtual directory,
as if a directory was dragged:

/drag-and-drop/file1.txt
/drag-and-drop/file2.txt

> Each Entry would have a dummy FileSystem object attached to it, in order
> to
> > fill out the Entry.filesystem API, but all it would contain is the file
> > itself.
>
> Again I think this could be left to the UA's implementation decision.
>

The main point is just that a FileSystem object will always be available,
even if the UA is only exposing one file in a directory which contains
other (inaccessible) files.  Most of the time it wouldn't be used, it just
avoids exceptional cases in the API.  (In other words, Entry.filesystem
would not become nullable.)

-- 
Glenn Maynard

Re: [whatwg] WHATWG on Google+

[Philip Jägenstedt]

On Tue, 22 Nov 2011 01:40:10 +0100, Ian Hickson  wrote:


On Mon, 21 Nov 2011, Boris Zbarsky wrote:

>
> Another option is for someone (possibly me) to create a system whereby
> people can subscribe to specific portions of the specification, and
> for a tool to detect when a diff affects that portion and e-mail them.
> I'm not exactly sure how to make that work, but if it's something
> people are interested in, we could figure something out.

This could be interesting if new sections are added rarely enough


I'm poking around at this. I'm not sure sections are the best way to
organise this, because self-contained features are often in various parts
of the spec, or end up sprouting new sections unexpectedly. So I'm  
looking

at annotating the spec source with specific topics, e.g. "WebSockets" or
"Navigation" or whatnot.

If people could e-mail me the lists of topics they would be interested in
being e-mailed diffs for, it would give me a good idea of what coarseness
would be helpful here, and thus whether this is a realistic idea.


I'd be interested in following any changes to the , ,  
 and  elements, as well as the WebVTT rendering rules. If  
you want to do it manually, categories "" and "" would  
probably suffice, if we consider WebVTT part of .


As an aside, I once made an attempt at writing tools for tracking changes  
on a per-section basis in and have dumped that in  
. It used the outlining  
algorithm to split things into sections and write each section to a  
separate file. It's rather over-engineered in the use of a complicated git  
history and I never got to the part that would actually create a feed of  
relevant changes, but some of the ideas might be worth keeping.


--
Philip Jägenstedt
Core Developer
Opera Software

Re: [whatwg] Using requestFileSystem to setup mounts

[Kinuko Yasuda]

On Tue, Nov 22, 2011 at 7:30 AM, Glenn Maynard  wrote:
> On Mon, Nov 21, 2011 at 4:33 PM, Charles Pritchard  wrote:
>>
>> Multiple directories still have a shared file system root. Their relative
>> paths are exposed in webkitdirectory files already.
>> The benefit is neutered .files object while maintaining compatibility with
>> existing code bases.
>
> It would be strange to drag in multiple directories and to have it exposed
> as a virtual directory containing the dragged files.  It could be done, but
> it's inconsistent with the design of DataTransfer, and it feels unnatural.
>
> I don't know what you mean by "compatibility with existing code bases"; the
> compatibility is no different than a getAsEntry/getAsWritableEntry API would
> be.

Putting aside the API discussion, actually I like the idea having one shared
isolated filesystem that contains multiple directories/files being dropped in,
as in that way both the UA and script can easily distinguish the set of
dropped files/directories as a single group sharing the same filesystem
object.  I don't think that must be enforced as a part of spec or
recommendation, but I don't think it's strange having multiple
files/directories being dropped in the same virtual root directory either.
(I'm not saying we should weigh rFS approach more than .entries
or getAsEntry)

> Also, remember that DataTransfer objects can be filled in programmatically.
> You can do, for example:
>
> dt.items.add("hello world", "text/plain"); // already supported
> dt.items.add(myFile); // already supported
> dt.items.add(myFileEntry); // new DataTransferItemList.add(Entry data)
> method
> dt.items.add(myDirectoryEntry);
>
> The requestFileSystem approach doesn't fit with DataTransfer's design very
> naturally.
>
> (Adding a File would be equivalent to adding a FileEntry containing the
> File; both would just create a DataTransferItem with a kind of "file".)
>
>> What values will Entry.filesystem and Entry.fullpath have?
>
> Each Entry would have a dummy FileSystem object attached to it, in order to
> fill out the Entry.filesystem API, but all it would contain is the file
> itself.

Again I think this could be left to the UA's implementation decision.

> Entry.fullPath would be the same as Entry.name, prefixed with "/".
>
>> As synchronous methods, won't these block the user if they need to confirm
>> permission to mount a directory?
>> As async methods, these might add a lot of calls to the stack.
>
> Async methods (eg. theoretically getAsWritableEntry) is adding no more calls
> than would be added by a similar async requestFileSystem call, which is also
> async.
>
> getAsEntry gives read-only access; as with getAsFile, there's no additional
> permission prompt.  Both methods could be async if we really want to allow
> for separate permissions prompting even for read-only access (though that's
> awkward UI, especially *during* a drag).  Either way, it's no more code for
> users than a requestFileSystem call.
>
>> Recursing directories is the current behavior of webkitdirectory.
>
> Yes, this should go away if possible, or at least not be propagated to other
> browsers.  It's not a scalable approach, as we discussed earlier.
> --
> Glenn Maynard
>
>